What you need to know

• 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 25, 2025, all Invicti products can identify and report the CVE.
• 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. Middleware can best be thought of 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 cross-cutting concerns like authentication—a very common pattern is having a middleware implement that logic that expresses “redirect to /login if there is not a valid authentication cookie”.

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 which can be trivially bypassed by an attacker.

To get an idea of how bad this can be, imagine an airport security checkpoint where security agents (the middleware) carefully check everyone’s ID and boarding pass before letting them proceed to the gate. Now, suppose there’s a secret phrase that, when whispered to any security agent, causes them to immediately wave you through without checking anything. That’s essentially what the Next.js middleware authorization bypass vulnerability allows: using a special HTTP header to completely bypass security checks that would normally protect sensitive routes and resources.

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

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. 

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.

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.

Final thought

There is an urban legend that used to circulate around schoolyards about summoning ghosts by chanting their names repeatedly in the dark in front of a mirror. Apparently, the name was wrong—instead of Bloody Mary, those kids just had to say “Middleware-y” five times in an HTTP header to summon a far scarier security bypass…