March 25, 2025
Next.js, the popular React-based framework developed by Vercel, has long been a cornerstone for developers building modern, scalable web applications. Known for its robust feature set—including server-side rendering, static site generation, and a powerful middleware system—it’s trusted by enterprises like Twitch, Spotify, and OpenAI. However, a recently disclosed security vulnerability, tracked as CVE-2025-29927, has sent shockwaves through the developer community. With a CVSS score of 9.1, this critical flaw exposes self-hosted Next.js applications to an authorization bypass that could allow attackers to access sensitive resources with alarming ease. In this blog, we’ll take a deep dive into what CVE-2025-29927 is, how it works, its impact, and the steps you can take to protect your applications.
What is CVE-2025-29927?
CVE-2025-29927 is an authorization bypass vulnerability affecting the middleware component of Next.js, a framework that enhances React with full-stack capabilities. Middleware in Next.js acts as a gatekeeper, intercepting HTTP requests before they reach application routes. Developers commonly use it to enforce authentication, manage access control, rewrite paths, redirect users, or apply security headers like Content Security Policy (CSP). The vulnerability, disclosed on March 21, 2025, by the Next.js team, stems from a design flaw in how Next.js processes an internal HTTP header: x-middleware-subrequest.
This header was originally intended to prevent infinite loops during middleware execution by tracking recursive subrequests. However, the flaw allows attackers to manipulate this header externally, tricking the framework into skipping middleware entirely. With a single, crafted HTTP request, attackers can bypass critical security checks—such as authentication or authorization—potentially gaining access to protected routes like admin panels or user dashboards.
Assigned a CVSS (Common Vulnerability Scoring System) score of 9.1 out of 10, this vulnerability is classified as critical due to its high impact, ease of exploitation, and the absence of required privileges or user interaction. The affected versions span a wide range, from 11.1.4 to 15.2.2, meaning years’ worth of Next.js deployments could be at risk if not patched.
How Does the Vulnerability Work?
To understand the mechanics of CVE-2025-29927, let’s first explore the role of middleware in Next.js. Middleware runs server-side before a request reaches its final destination (e.g., a page or API endpoint). It’s a powerful tool for implementing logic like:
- Verifying user authentication via cookies or tokens.
- Restricting access to specific routes based on user roles.
- Adding security headers to mitigate client-side attacks.
- Redirecting requests based on geolocation or other conditions.
The Next.js framework uses the x-middleware-subrequest header internally to manage subrequests and avoid infinite recursion—a safeguard to ensure middleware doesn’t repeatedly process the same request. The header’s value typically includes a colon-separated list (e.g., middleware:middleware:middleware), and the framework checks this against a recursion depth limit (defaulting to 5). If the limit is exceeded, middleware execution stops, and the request proceeds via NextResponse.next().
Here’s where the vulnerability emerges: Next.js does not sufficiently validate the source of this header. Attackers can craft an HTTP request with a manipulated x-middleware-subrequest header, such as:
x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
When this header is present with a value that exceeds the recursion threshold—or mimics an internal subrequest—the middleware logic is bypassed entirely. The request skips authentication, authorization, or any other checks implemented in middleware, proceeding directly to the target route. For example, an attacker could access an /admin dashboard without logging in, simply by adding this header to their request.
The exploit’s simplicity is what makes it so dangerous. It requires no authentication, no special privileges, and no complex attack chain—just a single HTTP header modification that can be performed with tools like curl or a web browser’s developer tools.
Proof-of-Concept Example
Imagine a Next.js application with middleware that restricts access to an admin dashboard:
// middleware.js
export function middleware(request) {
const isAuthenticated = request.cookies.get("auth_token");
if (!isAuthenticated) {
return Response.redirect("/login");
}
return NextResponse.next();
}
Normally, unauthenticated users would be redirected to /login. However, an attacker could send:
curl -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" http://example.com/admin
This request bypasses the middleware check, granting direct access to /admin without an auth_token. The implications are severe, especially for applications relying solely on middleware for security.
Impact and Scope
The impact of CVE-2025-29927 is magnified by Next.js’s widespread adoption. With nearly 10 million weekly downloads and over 330,000 internet-facing instances (according to Shodan), the framework powers applications across industries, including finance, healthcare, and Web3. The vulnerability’s reach is further compounded by its broad version coverage—any self-hosted Next.js application running versions 11.1.4 through 15.2.2 with middleware-based security controls is potentially vulnerable.
Key risks include:
- Authentication Bypass: Attackers can access protected routes (e.g., admin panels, user dashboards) without credentials, exposing sensitive data or functionality.
- Content Security Policy (CSP) Bypass: If middleware sets CSP headers to prevent cross-site scripting (XSS), bypassing it could enable client-side attacks.
- Geographic or Session-Based Restriction Evasion: Middleware enforcing location-based or session-based rules can be circumvented, allowing unauthorized access.
- Cache Poisoning: Bypassing cache-control middleware could let attackers poison caches with malicious content.
Notably, the vulnerability only affects self-hosted Next.js applications using next start with output: "standalone". Applications hosted on Vercel or Netlify, or those deployed as static exports, are not impacted, as these platforms either automatically patched the issue or don’t rely on middleware in the same way.
Who Discovered It?
The vulnerability was discovered by security researcher Rachid Allam (zhero), with additional analysis from Yasser Allam. Reported privately to the Next.js team via GitHub’s vulnerability reporting system on February 27, 2025, the issue was triaged by March 14, with patches released shortly after. Rachid’s technical write-up, published post-disclosure, provided a detailed breakdown of the exploit, accelerating awareness—and unfortunately, the need for immediate action as exploit details became public.
Mitigation and Fixes
The Next.js team responded swiftly, releasing patched versions to address CVE-2025-29927. The fixed versions include:
- 15.2.3
- 14.2.25
- 13.5.9
- 12.3.5
For users on older versions (11.1.4 through 13.5.6), upgrading to a patched version is strongly recommended, though backported fixes may not cover all cases. The patch modifies how Next.js handles the x-middleware-subrequest header, ensuring it cannot be externally manipulated to bypass middleware.
Immediate Workaround
If upgrading isn’t immediately feasible, a temporary mitigation is to block or strip the x-middleware-subrequest header at the edge or proxy level (e.g., via a load balancer, reverse proxy, or WAF). This must be done outside the Next.js application, as middleware itself can’t reliably filter the header due to the bypass mechanism. Examples:
- NGINX Configuration:
location / {
proxy_set_header x-middleware-subrequest "";
proxy_pass http://nextjs_app;
}
- Apache Configuration:
RequestHeader unset x-middleware-subrequest
- Cloudflare WAF: Add a managed rule to block requests containing the header (available as an opt-in rule since March 22, 2025).
While effective, this workaround may disrupt legitimate subrequest functionality in some setups, so testing is critical.
Long-Term Best Practices
Beyond patching, this vulnerability underscores broader security lessons:
- Defense in Depth: Don’t rely solely on middleware for security. Implement additional checks at the route or API level.
- Input Validation: Treat all user-controlled inputs, including HTTP headers, as untrusted and validate them rigorously.
- Monitoring: Use tools like Shodan or SOCRadar’s Attack Surface Management to identify exposed Next.js instances in your environment.
Why CVSS 9.1?
The CVSS score of 9.1 reflects the vulnerability’s severity:
- Attack Vector: Network – Exploitable remotely over the internet.
- Attack Complexity: Low – Requires minimal effort (just a header modification).
- Privileges Required: None – No authentication needed.
- User Interaction: None – No victim action required.
- Confidentiality/Integrity Impact: High – Potential for significant data exposure or modification.
- Availability Impact: None – No direct denial-of-service effect.
This combination makes CVE-2025-29927 a high-priority issue demanding immediate attention.
Conclusion
CVE-2025-29927 serves as a stark reminder that even widely trusted frameworks can harbor critical flaws. Its ease of exploitation—requiring only a single HTTP header—and its potential to compromise authentication, authorization, and security controls make it a pressing concern for Next.js users. If you’re running a self-hosted Next.js application, check your version and upgrade to a patched release (15.2.3, 14.2.25, 13.5.9, or 12.3.5) immediately. For those unable to patch, implement the header-blocking workaround and plan a swift update.
As the Next.js team continues to refine its security processes—acknowledging communication missteps with partners during this disclosure—developers must stay vigilant. Regularly audit your dependencies, simulate attacks with tools like the Picus Security Validation Platform, and adopt a multi-layered security approach to safeguard your applications. In an era of escalating cyber threats, proactive defense is no longer optional—it’s essential.
Stay secure, and happy coding!
Top comments (2)
Thanks for the information
Very useful