On March 21, 2025, Vercel disclosed CVE-2025-29927, a critical authorization bypass vulnerability in Next.js, the widely-used React framework. The vulnerability allowed an attacker to completely bypass middleware-based security checks by including a specific HTTP header in their request. Given that many Next.js applications rely on middleware for authentication and authorization, the impact was severe.
The vulnerability received a CVSS score of 9.1 and affected Next.js versions from 11.1.4 through 15.2.2.
The Root Cause
Next.js middleware runs before route handlers, making it a natural place to implement authentication checks, rate limiting, geolocation-based routing, and other cross-cutting concerns. When a request arrives, the middleware processes it and can redirect, rewrite, or block the request before it reaches the page or API route.
Internally, Next.js uses a header called x-middleware-subrequest to track middleware execution and prevent infinite loops when middleware triggers internal subrequests. The vulnerability was that Next.js did not prevent external requests from setting this header.
By including x-middleware-subrequest with the appropriate value in an HTTP request, an attacker could trick Next.js into believing the request was an internal subrequest that had already been processed by middleware. The framework would then skip middleware execution entirely, forwarding the request directly to the route handler.
The exploit was trivially simple:
GET /admin/dashboard HTTP/1.1
Host: target-app.example.com
x-middleware-subrequest: middleware
That single header was enough to bypass all middleware-based security checks. No authentication, no role verification, no rate limiting -- nothing that was implemented in middleware would run.
Why This Was So Dangerous
The severity of CVE-2025-29927 stemmed from how the Next.js ecosystem uses middleware. Vercel's own documentation and tutorials promoted middleware as the recommended location for authentication checks. Popular authentication libraries for Next.js, including NextAuth.js (now Auth.js), Clerk, and Supabase Auth, provided middleware-based integration patterns.
A typical pattern looked like this: middleware checks for a valid session cookie or JWT on protected routes, redirecting unauthenticated users to a login page. The route handler itself does not perform authentication checks because that is "middleware's job."
With CVE-2025-29927, this pattern was completely broken. An attacker could access any route that relied on middleware for protection by simply adding the bypass header. This included:
- Admin dashboards protected by role-based middleware checks.
- API endpoints that checked for authenticated sessions in middleware.
- Premium content gated behind subscription verification middleware.
- Internal tools deployed on public infrastructure with middleware-based access control.
The vulnerability was especially dangerous because it was invisible to the application code. The route handlers would receive requests and process them normally, with no indication that the middleware security checks had been skipped.
Affected Versions and Fix
The vulnerability affected a wide range of Next.js versions:
- Next.js 15.x: Fixed in 15.2.3
- Next.js 14.x: Fixed in 14.2.25
- Next.js 13.x: Fixed in 13.5.9
- Next.js 12.x: Fixed in 12.3.5
- Next.js 11.x: Affected from 11.1.4, no fix planned (EOL)
The fix was straightforward: Next.js was updated to strip the x-middleware-subrequest header from incoming external requests, preventing external actors from influencing middleware execution flow.
For organizations that could not immediately upgrade, Vercel recommended blocking requests containing the x-middleware-subrequest header at the reverse proxy or CDN level (Nginx, Cloudflare, etc.).
The Middleware Security Anti-Pattern
CVE-2025-29927 raised important questions about the security model of middleware-based authorization in web frameworks, not just Next.js.
The fundamental issue is that middleware is a framework-level abstraction. It sits between the HTTP server and the application code, and its execution depends on the framework's internal request processing logic. If the framework has a bug -- like accepting an internal header from external sources -- the middleware's security guarantees evaporate.
Defense-in-depth principles suggest that security checks should not rely on a single enforcement point. For authentication and authorization, this means:
Implement authorization checks at the data access layer, not just at the routing layer. Even if middleware provides a convenient first line of defense, the actual data fetching and mutation logic should independently verify that the requesting user has appropriate permissions.
Treat middleware as a UX optimization, not a security boundary. Middleware is great for redirecting unauthenticated users to a login page. It should not be the only thing preventing unauthenticated users from accessing protected data.
Use framework-independent security mechanisms where possible. Token validation, for example, can be performed by the route handler itself, independent of framework middleware.
Community Response
The disclosure generated significant discussion in the Next.js and broader JavaScript communities. Some developers argued that relying on middleware for security was always fragile and that the vulnerability was a consequence of poor security architecture. Others pointed out that Vercel's own documentation and tutorials promoted exactly this pattern.
The incident prompted several popular auth libraries to update their documentation, adding warnings about the importance of server-side validation in addition to middleware checks. Some libraries released updates that added secondary validation at the route handler level as a defense-in-depth measure.
How Safeguard.sh Helps
Safeguard.sh monitors your application dependencies for known vulnerabilities, including framework-level issues like CVE-2025-29927. When you maintain SBOMs for your applications, Safeguard can immediately identify which applications in your portfolio use vulnerable versions of Next.js and prioritize them for remediation.
Beyond reactive vulnerability matching, Safeguard's policy gates can enforce minimum framework versions across your organization, preventing deployment of applications using known-vulnerable Next.js releases. This is especially valuable in organizations with multiple development teams, where ensuring consistent patching across dozens of Next.js applications can be challenging.
Safeguard helps you close the gap between vulnerability disclosure and remediation, so that critical flaws like CVE-2025-29927 are addressed before attackers can exploit them in your environment.