jeymo092/cve-2025-29927Proof-of-concept exploit for CVE-2025-29927, a Next.js middleware bypass vulnerability. Includes version-specific payloads and a Docker-based lab for testing unauthorized access to protected routes.
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 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.
Clone the repository:
git clone <repository_url>
Navigate to the project directory:
cd nextjs-docker-app
Build the Docker image:
docker build -t nextjs-app .
Run the Docker container:
docker run -p 3000:3000 nextjs-app
Access the application in your browser at http://localhost:3000.
The exploitation method varies slightly depending on the Next.js version:
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:
x-middleware-subrequest: pages/_middleware
For nested routes, there could be multiple middleware files at different levels, resulting in multiple possible values for the header:
x-middleware-subrequest: pages/dashboard/_middleware
or
x-middleware-subrequest: pages/dashboard/panel/_middleware
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:
x-middleware-subrequest: middleware
Additionally, Next.js allows for an alternative project structure with a /src directory. In such cases, the payload would be:
x-middleware-subrequest: src/middleware
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.
x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
Alternatively, for projects using a /src directory structure:
x-middleware-subrequest: src/middleware:src/middleware:src/middleware:sr
=======
# cve-2025-29927
>>>>>>> 56c7b2dcd548caf771750519107bf7c57749a864