Mitigating CVE-2025-29927: Next.js Middleware Authorization Bypass

CVE-2025-29927 is a critical vulnerability (CVSS 9.1) in Next.js that allows attackers to bypass middleware execution entirely by sending a single crafted HTTP header. Since Next.js middleware is commonly used to enforce authentication, authorization, and rate limiting, a successful exploit can expose protected routes, sensitive data, and internal APIs without any credentials.

This guide explains how the vulnerability works and how to mitigate it using Azion Applications with a Rules Engine rule that strips the malicious header before it reaches your Next.js origin.


Affected versions

Next.js versionVulnerable rangePatched version
15.x>= 15.0.0, < 15.2.315.2.3
14.x>= 14.0.0, < 14.2.2514.2.25
13.x>= 13.0.0, < 13.5.913.5.9
12.x>= 12.0.0, < 12.3.512.3.5
11.xAll versionsNo patch — use workaround only

How the attack works

Next.js uses an internal header, x-middleware-subrequest, to track recursive middleware calls and prevent infinite loops. This header was never intended to be sent by external clients.

When an attacker sends a request with this header set to a specific value, Next.js interprets it as an internal subrequest and skips middleware execution entirely. This means all security checks implemented in middleware — authentication, authorization, rate limiting — are bypassed.

Exploit examples:

For Next.js 14.x and 15.x:

x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

For Next.js 11.1.4 through 12.1.x:

x-middleware-subrequest: pages/_middleware
x-middleware-subrequest: pages/dashboard/_middleware

The attack requires no credentials, no special privileges, and works from any network — making it trivially exploitable at scale.

Potential impact:

  • Unauthorized access to protected routes and admin panels
  • Bypass of authentication and authorization checks
  • Exposure of sensitive data and internal APIs
  • Circumvention of rate limiting and other protective measures
  • Cache poisoning leading to Denial of Service

Detecting vulnerable applications

Before applying the mitigation, identify whether your applications are running a vulnerable Next.js version. Look for these indicators in HTTP responses:

  1. The x-powered-by: Next.js response header (can be disabled, so absence doesn’t guarantee safety)
  2. Headers such as x-middleware-rewrite or x-nextjs-cache
  3. References to /_next/static/ in response bodies
  4. A different response when sending the exploit header versus a normal request

You can use the Nuclei template for CVE-2025-29927 to scan your applications:

Terminal window
# Scan a single target
nuclei -u https://your-app.example.com -t ./CVE-2025-29927-6mile.yaml -fr
# Scan a list of targets
nuclei -l websites.list -t ./CVE-2025-29927-6mile.yaml -fr -silent

Mitigation strategy

The official Next.js recommendation is to block any external request containing the x-middleware-subrequest header before it reaches your application.

Azion Applications enforces this at the network edge — before the request reaches your origin — using a Rules Engine rule with the Filter Request Header behavior. This strips the x-middleware-subrequest header from every incoming request, so Next.js never sees it and middleware execution proceeds normally.

This approach:

  • Protects all routes of the application simultaneously with a single rule
  • Requires no changes to your application code
  • Can be deployed and reverted independently of your release cycle
  • Takes effect within minutes of saving

Requirements


Creating the mitigation rule

  1. Access Azion Console > Applications.

  2. Select the application serving your Next.js workload.

  3. Click the Rules Engine tab.

  4. Click + Rule.

  5. Give the rule a descriptive name, such as Strip x-middleware-subrequest - CVE-2025-29927.

  6. Optionally, add a description: Strips the x-middleware-subrequest header from all incoming requests to mitigate CVE-2025-29927 in Next.js.

  7. Make sure Request Phase is selected.

  8. In the Criteria section, configure:

    • Variable: ${uri}
    • Operator: starts with
    • Argument: /

    This matches all incoming requests to the application.

  9. In the Behaviors section, select Filter Request Header.

  10. In the header name field, enter: x-middleware-subrequest

  11. Click Save.

The rule will propagate across Azion’s global infrastructure within a few minutes.


Validating the mitigation

After the rule propagates, test that the header is being stripped before reaching your origin:

Terminal window
# Send the exploit header — your application should respond normally (not bypass auth)
curl -i -H 'x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware' \
https://your-app.example.com/protected-route
# Send a normal request — should also respond normally
curl -i https://your-app.example.com/protected-route

Both requests should return the same response. If the exploit header was previously granting unauthorized access to protected routes, it should no longer do so after the rule is active.


Upgrading Next.js (definitive fix)

The header-stripping rule is a temporary measure. Apply the permanent fix by upgrading Next.js to a patched version as soon as possible:

Current versionUpgrade target
15.x>= 15.2.3
14.x>= 14.2.25
13.x>= 13.5.9
12.x>= 12.3.5
11.xUpgrade to 12.x or later

After upgrading and validating your application, you can disable or remove the Rules Engine rule.


References