How to Exploit CVE-2025-29927: Bypass Middleware Authorization in Next.js

Introduction

On March 21st, 2025, the Next.js maintainers announced a critical authorization bypass vulnerability – CVE-2025-29927. This vulnerability is easily exploitable, allowing attackers to bypass authorization mechanisms. In some instances, it can also lead to cache poisoning and denial of service attacks.

Which versions of Next.js are affected?

Next.js 15.x – from version 15.0.0 up to and including 15.2.2.

Next.js 14.x – from version 14.0.0 up to and including 14.2.24.

Earlier Next.js versions – from version 11.1.4 up to and including 13.5.6.

Attack scenarios for CVE-2025-29927

For the vulnerability to be exploited, the victim's Next.js server must use Next.js Middleware. This involves including a middleware.js or middleware.ts file (_middleware.js or _middleware.ts for older Next.js versions). This file defines and exports the middleware function, which contains the logic that runs when each HTTP request is received.

How Next.js CVE-2025-29927 Exploit Works?

CVE-2025-29927 vulnerability occurs due to the misuse of a special internal HTTP header called x-middleware-subrequest. This header was originally intended for internal framework operations to prevent middleware from processing the same request repeatedly, thus avoiding infinite loops. However, a design flaw allowed external attackers to manipulate this header and control how the middleware worked. By crafting a request with a specific x-middleware-subrequest value, attackers could trick the application into skipping middleware execution entirely. As a result, any security controls, such as access restrictions or session validation implemented in the middleware, could be completely bypassed.

Authorization bypass

This scenario applies when the victim's Next.js server uses the Middleware feature for authorization, and the underlying application does not have any other authorization layers.

Authorization middleware scenario without CVE-2025-29927 exploitation

Authorization middleware scenario with CVE-2025-29927 exploitation

Example Application

Github - https://github.com/ARVINDTRONICS/nextjs-cv202529927-vulnerable-app

The example application has two pages

1. Default Login Page

2. Admin Page

The Admin Page and its data should only be accessible after the user is authenticated (username :" admin@gmail.com & password : admin) and a token is included in the incoming request. The middleware validates the token before allowing data to be fetched from the admin-data route. If there is no token or if the token is invalid, the request is rejected with an error in the middleware layer.

However, due to the vulnerability mentioned above, we can send a malicious header in the request to the /admin-data API to access sensitive data and completely bypass the validation performed by the middleware.

x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Without this header, the validation proceeds as usual.

Real-World Security Impacts

This vulnerability creates several serious attack opportunities:

1. Complete Authentication Bypass: Attackers can access admin panels, private dashboards, or user data without needing to log in.

2. Content Security Policy Bypass: Middleware often sets CSP headers to prevent cross-site scripting. With this bypass, those protections are removed: curl -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" \ -H "Content-Type: text/html" --data "<script>alert('hacked')</script>" \ http://example-site.com

3. Geographic Restrictions Bypass: Many sites use middleware to restrict content based on location. This header bypasses those checks: curl -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" \ -H "CF-IPCountry: RU" http://example-site.com/eu-only-content

Protecting Your Next.js Applications

There are three main ways to fix this vulnerability:

1. Update Next.js Immediately

   • Upgrade to version 15.2.3+ or 14.2.25+

   • These versions have fixed the security issue

2. Block the Dangerous Header If updating isn’t possible right away, block the header at the web server level: For NGINX: location / { proxy_set_header x-middleware-subrequest ""; } For Apache: RequestHeader unset x-middleware-subrequest

3. Implement Defense-in-Depth

   • Don’t rely only on middleware for security

   • Add server-side authentication checks (like with NextAuth.js)

   • For critical paths, add extra security layers