Next.js Middleware Authentication Bypass (CVE-2025–29927): Exploitation, Impact, and Mitigation

Next.js is a web framework created by Vercel that is open-source and supports React applications with functionalities such as server-side rendering and static generation. A critical vulnerability that allowed an unauthenticated attacker to bypass middleware-based authorization handling. This blog will encorporate what the vulnerability is, how it occurs, and how the exploitation process works.

The vulnerability is associated with the “middleware” functionality in Next JS. Middleware is used in Next JS for tasks such as authorization implementation, dynamic redirection or URL changing based on request contents (example, redirecting the user to login page if request doesn’t contain required cookie values), and addition of custom headers for CORS, CSP, and so on.

Middleware exploitation allows an attacker to completely dodge the middleware controls with the addition of a specially crafted header known as x-middleware-subrequest to the HTTP request.

Vulnerable Versions:

Next.js 15.x: Versions before 15.2.3Next.js 14.x: Versions before14.2.25Next.js 13.x: Versions before13.5.9Next.js 12.x: Versions before 12.3.5.

The impact of this vulnerability is specially notable for web application that leverages middleware for access control implementations. This is becase poorly configured middleware means attackers accessing confidential informations without proper authentication.

Middleware in Next JS is a feature that allows the execution of code before completion of a request. According to Next JS, middleware allows us to run a code before the request is completed allowing us to modify the response by rewriting, redirecting, modifying the request or response headers based on the incoming request.

The primary use case of middleware in Next JS are:

Rewriting Path: Modifying the request URL before it reaches the application logic. For example, if a user requests /blog/latest, the middleware can rewrite it to /blog/2025-update without changing the URL in the browser.Serverside Redirects: Automatically sending users to a different page based on HTTP request information. For example, if an unauthenticated user tries to access /dashboard, the middleware can redirect them to /login. Similarly, if a logged-in user visits /login, they can be redirected to /dashboard.Modifying Response Headers: Enhancing security by adding headers like Content Security Policy (CSP) or Strict-Transport-Security (HSTS) to protect against XSS and other attacks.Authentication / Authorization: Verifying user identity by checking session cookies before allowing access. If a user’s session does not contain a valid authentication token, they may be redirected to the login page. If they have admin privileges, they can be directed to an admin panel instead of a regular user dashboard.

CVE-2025–29927 arises from a poor design flow while Next JS middleware processes the x-middleware-subrequest. This header’s intended function was to prevent the infinite execution of middleware.

The runMiddleware function is called to process the inbound requests if middleware is being used in a Next JS application. This function checks for the availability of x-middleware-subrequest header. If this header is present and consists of a particular value, the middleware execution is entirely skipped and NextResponce.next() forwards the request is forwarded to it’s original destination.

But what if an unauthenticated used included the header x-middleware-subrequest with the correct value to a request? That way an attacker can entirely bypass authorization provided by middleware.

The vulnerability occurs due to the following practice of the following middleware authorization:

const subreq = params.request.headers["x-middleware-subrequest"];
2const subrequests = typeof subreq === "string" ? subreq.split(":") : [];
3
4if (subrequests.includes(middlewareInfo.name)) {
5 result = {
6 response: NextResponse.next(),
7 waitUntil: Promise.resolve(),
8 }
9 continue;
10}

Here, the code’s logic is to find the x-middleware-subrequest header, split it’s contents by “:”, taking the subrequests value into an array if subreq is a string. The code then checks if the middlewareInfo.name (the name of the current middleware) is included in the subrequest array. If middleware name is found in the subrequests, the code’s logic is to forward the request to the next middleware using NextResponse.next(), skipping the processing of the current middleware. It ensures that the middlware completes asynchronously by resolving an empty promise using Promise.resolve().

The exploitation process differs based on different versions of Next JS.

For versions < 12.2:

In these versions, middleware files were names as _middleware.ts and was placed inside the pages folder. That value of middleware.Info that is required to hold a valid value, consists of the directory name and the file name.

The header would look something like:

x-middleware-subrequest: pages/_middleware

If the routes are nested then:

x-middleware-subrequest: pages/users/panel/_middleware

For versions ≥ 12.2:

In this version, the middleware’s naming convention was simply, middleware.ts and was located in the root directory and not under pages directory like before.

The payload would look like:

x-middleware-subrequest: middleware

As Next JS allows the use of /src directory while project creation, payload could also be:

x-middleware-subrequest: src/middleware

For versions ≤ 13.2.0

In these versions, middleware recursion depth limit was introduced to prevent a middleware from processing a request infinitely. This, however doesn’t affect the vulnerability because header checks occurs before recursion dept checks.

So the payload for these versions would be:

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

If the project uses /src directory:

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

CVE-2025–29927 is an important vulnerability in Next.js middleware to overcome authentication processes by using the x-middleware-subrequest header. As middleware is commonly employed for the purpose of securing access to a system, this can allow an unauthorized individual to access confidential data, other personnel’s control panels, or certain APIs.

However, Next.js introduced recursion depth limitation from its 13.2.0 versions, but this vulnerability is still dangerous because the flawed header check happens before the depth check. This demonstrates why the header validation should be safe and authentications check should not be restricted to middleware.

In order to deal with this vulnerability, developers should:

Not rely entirely of middleware for authentication and authorizations.Reject unexpected x-middleware-subrequest by manual validation of headers.And obviously, updating to the patched version of Next JS.