CVE-2025-29927

What it actually does

CVE-2025-29927 is an authorization bypass in Next.js applications that rely on middleware to enforce authentication, authorization, tenant isolation, redirects, or other access controls. By supplying a crafted internal Next.js request header, an external client can cause middleware execution to be skipped or treated as an internal subrequest, allowing protected routes to be reached without the intended middleware checks. The issue is especially severe where middleware is the only enforcement layer for access control and downstream route handlers, API endpoints, or server-side rendering logic assume the middleware has already validated the user.

Why it matters to the business

Successful exploitation can let unauthenticated or low-privileged users access restricted pages, APIs, administrative functions, or sensitive data. Because the issue is weaponized and has a very high EPSS score, internet-facing Next.js applications using middleware-based authorization should be treated as high-priority exposure even though the CVE is not listed in CISA KEV. Organizations may face data disclosure, account compromise, unauthorized transactions, compliance impact, and emergency remediation work if affected applications are publicly reachable. The supplied affected-product data references Debian 13 linux fixed in 6.12.5-1, which does not align with the Next.js middleware vulnerability description; engineering teams should validate package applicability against their SBOM and application dependency inventory.

How an attack unfolds

An attacker first identifies a public Next.js application and probes for routes that normally redirect unauthenticated users, return 401/403 responses, or require a session. They then resend requests to those protected routes with a crafted `x-middleware-subrequest` header value that mimics internal middleware recursion metadata. In vulnerable versions, Next.js may skip the middleware chain, so authentication and authorization logic implemented there does not run. If the protected route or API handler does not independently re-check permissions, the attacker receives content or performs actions as though the middleware had approved the request. Attackers typically automate this across common protected paths such as dashboards, admin areas, account pages, API routes, and tenant-specific resources, then enumerate accessible data or chain the bypass with application-specific weaknesses.

How to fix it

Upgrade all affected Next.js applications to fixed Next.js releases: 12.3.5 or later for the 12.x line, 13.5.9 or later for the 13.x line, 14.2.25 or later for the 14.x line, and 15.2.3 or later for the 15.x line. Rebuild and redeploy applications after upgrading; dependency updates alone are insufficient if old build artifacts or containers remain in service. If immediate upgrade is not possible, block or strip externally supplied `x-middleware-subrequest` headers at the CDN, reverse proxy, load balancer, WAF, or application gateway before requests reach Next.js. Do not rely solely on middleware for critical authorization: enforce authorization again in route handlers, API handlers, server actions, and backend services. Review supplied package advisories carefully: the provided fixed version `linux (Debian:13): 6.12.5-1` appears unrelated to this Next.js flaw unless a distribution-specific advisory explicitly maps it to deployed application packaging.

How to confirm the fix worked

Confirm the deployed application is running a fixed Next.js version by checking `package.json`, lockfiles, container image contents, SBOMs, and runtime build metadata. Verify all running containers, serverless functions, and edge deployments were rebuilt from the patched dependency. Test representative protected routes by sending requests with and without an externally supplied `x-middleware-subrequest` header; patched or mitigated systems should not allow the header to change authorization outcomes. Confirm the CDN, proxy, or WAF removes or rejects this header from client-originated traffic. Review code to ensure high-risk authorization decisions are enforced in backend route handlers and not only in middleware.

Typical attack path

1. Fingerprint the target as a Next.js application using response headers, static asset paths, build artifacts, or route behavior.
2. Identify routes protected by middleware by observing redirects to login pages, 401/403 responses, or locale/authentication middleware behavior.
3. Send requests to the same protected routes with a crafted `x-middleware-subrequest` header designed to cause middleware bypass.
4. Compare responses with and without the header to confirm a change from denied or redirected access to successful content delivery.
5. Enumerate sensitive pages, API endpoints, administrative functions, or tenant-scoped resources that rely solely on middleware checks.
6. Exfiltrate accessible data, perform unauthorized actions, or use exposed application functionality to pivot deeper into the application.

How to detect it

Investigate whether externally originated requests included the `x-middleware-subrequest` header, especially against routes that usually require authentication or produce redirects. Useful sources include CDN logs, WAF logs, reverse proxy access logs, application gateway logs, load balancer logs, Next.js application logs, API gateway logs, and full HTTP request captures if available. Many default access logs do not record request headers, so enable retrospective header search where supported by CDN/WAF telemetry. Look for response-code changes where the same source requested a protected path first receiving 302, 401, or 403 and then receiving 200 after adding the suspicious header. Also review authentication logs for missing or invalid session cookies paired with successful access to protected URLs. If exploitation is suspected, examine accessed routes, downloaded content, administrative actions, account changes, and API calls following the bypass attempt.

• x-middleware-subrequest
• X-Middleware-Subrequest
• x-middleware-subrequest: middleware
• x-middleware-subrequest: middleware:middleware
• x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
• x-middleware-subrequest: src/middleware
• x-middleware-subrequest: src/middleware:src/middleware
• x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware
• x-middleware-subrequest: pages/_middleware
• x-middleware-subrequest: pages/_middleware:pages/_middleware
• x-middleware-subrequest: pages/_middleware:pages/_middleware:pages/_middleware:pages/_middleware:pages/_middleware
• x-middleware-subrequest: _middleware
• x-middleware-subrequest: _middleware:_middleware:_middleware:_middleware:_middleware

What your security team should do

• Immediately inventory internet-facing Next.js applications and identify any using middleware for authentication, authorization, redirects, tenant isolation, or access control.
• Prioritize patching or compensating controls for public applications because exploitation is weaponized and the EPSS score indicates high likelihood of exploitation activity.
• Upgrade to fixed Next.js versions and redeploy all affected builds, containers, serverless functions, and edge runtimes.
• Add a temporary edge control to drop or block any inbound request containing `x-middleware-subrequest` unless it is known to originate from trusted internal infrastructure.
• Hunt historical access logs for client-supplied `x-middleware-subrequest` headers and for protected routes returning success responses without normal authentication signals.
• Review application code for routes that assume middleware has already authorized the request, and add server-side authorization checks to sensitive handlers.
• Validate whether the supplied Debian linux package advisory is relevant to any systems, but do not consider a kernel update a substitute for patching affected Next.js applications.