Next.js middleware authorization bypass vulnerability: Are you vulnerable?

A critical vulnerability in the Next.js framework, officially disclosed on March 21, 2025, allows attackers to bypass middleware security controls through a simple header manipulation. This post summarizes what we know about CVE-2025-29927, how you can mitigate the vulnerability, and how Acunetix can help you detect and confirm your organization’s risk.

What you need to know about CVE-2025-29927

• A remote authorization bypass vulnerability identified as CVE-2025-29927 was confirmed in Next.js, one of the most popular React frameworks used to build web applications.
• The vulnerability allows attackers to completely bypass Next.js functionality in an application, including commonly used critical security functions such as authentication and authorization.
• As of March 24, 2025, Acunetix has an active security check to detect and report exploitable Next.js versions.
• The vulnerability affects the following Next.js versions:
  • Next.js 11.1.4 through 13.5.6 (unpatched)
  • Next.js 14.x before 14.2.25
  • Next.js 15.x before 15.2.3
• Upgrading to a non-vulnerable version is the only guaranteed fix. Proxy-level WAF blocking may work temporarily but is not recommended in the long run.

Understand your Next.js middleware bypass risk

The vulnerability allows attackers to completely bypass the middleware functionality by including a specially crafted x-middleware-subrequest header in their requests. You can think of middleware as a processing chain that lets software modules inspect, modify, or reroute an HTTP request before it reaches its final code handler. It is a natural place to implement things like authentication, and one very common pattern is to have middleware redirect to a login page if no valid authentication cookie is found.

This vulnerability is particularly concerning because Next.js middleware is commonly used for critical security functions such as authentication, authorization, path rewriting, and implementing security headers. All of these can be trivially bypassed by an attacker simply by using a special HTTP header.

Are you vulnerable to the Next.js middleware bypass?

If your answer to BOTH of the following questions is “yes”, your application is vulnerable unless patched:

• Do you rely on Next.js middleware for security controls?
• Are you running a self-hosted Next.js application using next start with output: 'standalone'?

Applications are particularly at risk if:

• You use middleware for authentication or authorization checks
• You rely on middleware for implementing security headers like Content Security Policy (CSP), used to define limitations on where resources are permitted to be loaded
• You use middleware for path rewriting to restrict access to certain routes

Applications hosted on Vercel or Netlify are not affected, as these platforms have implemented mitigations at their edge layers. Applications deployed as static exports (where middleware is not executed) are also not affected.

If you don’t know the details of your Next.js usage or want the ability to assess it independently, running an automated DAST tool to confirm your vulnerability is a great place to start.

How the Next.js middleware vulnerability works

Next.js middleware uses an internal header called x-middleware-subrequest to prevent recursive requests from triggering infinite loops. The security vulnerability allows an attacker to manipulate this header to trick the Next.js application into skipping middleware execution entirely.

For different versions of Next.js, the exploit works slightly differently:

• For older versions (pre-12.2):
  x-middleware-subrequest: pages/_middleware
• For modern versions:
  x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
  (or src/middleware:src/middleware:src/middleware:src/middleware:src/middleware if using the src directory)

When this header is present with the appropriate value, the middleware is completely bypassed, allowing the request to reach its original destination without any security checks or modifications that would have been applied by the middleware.

How Invicti DAST products detect CVE-2025-29927

Active detection logic (Acunetix)

Invicti’s security research team has developed a check for the Acunetix engine to detect if your applications are vulnerable to CVE-2025-29927. As of Monday, March 24, 2025, this check is live for all Acunetix Premium customers.

Here’s how the active check works step by step:

1. Identify Next.js middleware usage: The check first looks for the telltale signs of Next.js middleware, specifically a 307 redirect where the response body equals the location header value. This pattern is unique to Next.js middleware redirects.
2. Verify Next.js framework presence: Confirm the application is using Next.js by checking for the x-powered-by: Next.js header in responses.
3. Test with bypass payloads: The detection mechanism tries different bypass payloads based on the potential Next.js version:
   • For newer versions (13.2.0+): middleware:middleware:middleware:middleware:middleware (and the src variant)
   • For older versions (pre-12.2): pages/_middleware
   • For intermediate versions (12.2 to 13.2.0): middleware
4. Validation through contrast: To avoid false positives, the test performs multiple validation checks:
   • Send a request with the potential bypass header and check if it returns a 200 OK.
   • Send a control request with a slightly modified header, such as Y-Middleware-Subrequest, to confirm it still redirects (307).
   • Send another request with an invalid value to confirm proper behavior.
   • Repeat the successful bypass to ensure consistency.
5. Confirm vulnerability: Only after all validation steps pass is the vulnerability confirmed, reducing the risk of false positives.

Passive detection through traffic analysis with dynamic SCA (Invicti)

The vulnerability is detected through passive monitoring of web traffic during a security scan without making active requests. Invicti Enterprise uses this technique with its vulnerability database to detect the flaw. This technique looks for the x-powered-by: Next.js header in responses, which confirms the application is using Next.js. The presence of the vulnerable version is further confirmed by evaluating the next.version function in the browser’s JavaScript context to extract the precise version

We then compare this value to our continuously updated database of known CVEs and network detection signatures to determine if an insecure version of Next.js has been encountered.

As of Tuesday, March 25, 2025, this check is live for all Invicti Enterprise, Invicti Standard, and Acunetix 360 customers. 

Mitigation steps for CVE-2025-29927

1. Update immediately:
   • For Next.js 15.x: Update to ≥ 15.2.3
   • For Next.js 14.x: Update to ≥ 14.2.25
   • For Next.js 13.x: Update to ≥ 13.5.9
   • For Next.js 12.x: Update to ≥ 12.3.5
2. If updating isn’t possible immediately:
   • Block the x-middleware-subrequest header at your edge/proxy level (not in middleware itself).
   • Cloudflare users can enable a Managed WAF rule that blocks this attack. Be aware that Cloudflare has changed this WAF rule to be opt-in after reports of 3rd party authentication frameworks being impacted. We suggest you focus on upgrading Next.js.

Invicti Security would like to acknowledge Rachid Allam and Yasser Allam for their original research and writeup of their findings, as well as our internal teams that worked to turn out a check to customers within a single business day.

Our security team is continuously monitoring this situation and will update as more information becomes available.

THE AUTHOR

Bogdan Calin

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.