Next.js is an open-source web framework built by Vercel that powers React-based apps with features like server-side and static rendering. Recently, a critical vulnerability (CVE) was disclosed that lets attackers bypass middleware-based authorization checks. The issue was originally discovered and analyzed by Rachid Allam (zhero). In this blog, we’ll break down the vulnerability and walk through their research and will create a Nuclei template to help you detect it across your assets.

The vulnerability specifically affects the middleware functionality in Next.js, which is commonly used for implementing authorization, path rewriting, server-side redirects, and adding response headers such as Content Security Policy (CSP).

When exploited, an attacker can completely circumvent these middleware controls by adding a specially crafted x-middleware-subrequest header to their HTTP requests.

All versions of Next.js from 11.1.4 through 13.5.6, 14.x before 14.2.25, and 15.x before 15.2.3 are affected by this vulnerability. The impact is particularly significant for applications that rely on middleware for implementing access controls, as attackers can gain unauthorized access to protected resources without authentication.

The Next.js Middleware

Next.js middleware is a powerful feature that allows developers to run code before a request is completed. As the official Next.js documentation states: "Middleware allows you to run code before a request is completed. Then, based on the incoming request, you can modify the response by rewriting, redirecting, modifying the request or response headers, or responding directly."The middleware functionality in Next.js has numerous use cases, but the most critical ones include:

A common implementation pattern is using middleware for authorization, which involves protecting certain paths based on specific conditions. For example, when a user attempts to access a protected route like /dashboard/admin, the middleware intercepts the request, checks if the user's session cookies are valid and if they have the necessary permissions. If the conditions are met, the middleware forwards the request; otherwise, it redirects the user to a login page.

The vulnerability mechanism

The vulnerability in CVE-2025-29927 stems from a design flaw in how Next.js processes the x-middleware-subrequest header. This header was originally intended for internal use within the Next.js framework to prevent infinite middleware execution loops.When a Next.js application uses middleware, the runMiddleware function is called to process incoming requests. As part of its functionality, this function checks for the presence of the x-middleware-subrequest header. If this header exists and contains a specific value, the middleware execution is skipped entirely, and the request is forwarded directly to its original destination via NextResponse.next().

The vulnerability lies in the fact that this header check can be exploited by external users. By adding the x-middleware-subrequest header with the correct value to a request, an attacker can completely bypass any middleware-based protection mechanisms.Here's how the vulnerability works at the code level:javascript

This code snippet shows that if the x-middleware-subrequest header value, when split by the colon character (:), includes the middlewareInfo.name value, the middleware is bypassed entirely.

Exploitation Across Different Next.js Versions

The exploitation method varies slightly depending on the Next.js version:

For versions prior to 12.2:

In these versions, middleware files had to be named _middleware.ts and placed inside the pages folder. The value of middlewareInfo.name was composed of the directory name and the file name:

For nested routes, there could be multiple middleware files at different levels, resulting in multiple possible values for the header:

or

For versions 12.2 and later:

Starting with version 12.2, Next.js changed the middleware conventions. The file should be named middleware.ts (without the underscore) and should no longer be located in the pages folder. For these versions, the payload is simpler:

Additionally, Next.js allows for an alternative project structure with a /src directory. In such cases, the payload would be:

For versions 13.2.0 and later:

For versions 13.2.0 and above, Next.js introduced a maximum recursion depth for middleware execution. This was implemented to prevent infinite loops but doesn't affect the vulnerability. The exploitation remains the same, as the header check occurs before any recursion depth checks.

Alternatively, for projects using a /src directory structure:

Template

The ProjectDiscovery research team wrote a template so that users can detect CVE-2025-29927 for the latest version in their attack surface. This was developed within 2 days of the CVE notification, and just within 24 hours after the public disclosure of the details of the vulnerability.

Template Breakdown:

Nuclei Template to detect CVE-2025-29927 - CVE Scan URL

With this header, the request completely bypasses the middleware's authorization checks and is forwarded directly to the /dashboard/admin route, granting the attacker unauthorized access to protected resources.

Adem Kouki from the community also contributed a version-based headless template for those who want to check if a vulnerable version is in use. However, finding a vulnerable version doesn’t necessarily mean the host is actually exploitable.

Nuclei Templates Lab - CVE-2025-29927

​We have recently launched our Nuclei Templates Lab, a dedicated environment designed for hands-on practice with the latest CVEs. We've included a lab specifically for CVE-2025-29927, allowing you to explore and understand this vulnerability in a controlled setting.​ You can access the lab for this CVE here

Impact Scenarios

The vulnerability can be exploited in several ways:

The simplicity of exploitation and the widespread use of Next.js for building modern web applications make this vulnerability particularly concerning. No special tools or complex techniques are required - just adding a single HTTP header with the correct value is sufficient to bypass security controls.

Official Patches

Vercel, the company behind Next.js, has released patches for the vulnerability:

Workaround for Unpatched Versions

If updating to a patched version is not immediately feasible, the recommended workaround is to prevent external user requests containing the x-middleware-subrequest header from reaching your Next.js application.This can be implemented at various levels:

Custom Middleware: As a last resort, you could implement a simple Express middleware (if using a custom server) that runs before Next.js to strip the header:javascript

Web Server Configuration: If you're using Nginx, Apache, or another web server in front of your Next.js application, configure it to strip or block requests with the x-middleware-subrequest header.For Nginx, you could add a configuration like:

For Apache, you could use mod_headers:

The discovery of CVE-2025-29927 serves as a critical reminder of how seemingly minor implementation details in web frameworks can lead to significant security vulnerabilities. It affects multiple versions across 11.x to 15.x, with serious implications for authorization. While Vercel-hosted deployments are automatically protected, self-hosted apps must patch or implement mitigation strategies.

The vulnerability’s ease of exploitation and impact make it a high-priority issue for Next.js users. Fortunately, official patches are available, and detection templates like the one from ProjectDiscovery can help organizations quickly identify affected systems.

To help security teams identify and mitigate this issue in their NextJS deployment, we have created a Nuclei template for detection automation. This template is also integrated into the ProjectDiscovery Cloud platform, enabling our customers to proactively scan for this vulnerability as part of their continuous security assessments.

References