Next.js Middleware Auth Bypass: What CVE-2025-29927 Means for Your Site

In March 2025, the Next.js team disclosed CVE-2025-29927, a critical severity (CVSS 9.1) authorization bypass affecting every Next.js version from 11.1.4 through 15.2.2. The vulnerability lets an attacker skip the entire middleware layer, including authentication, authorization, rate limiting, and geo restrictions, by sending a single HTTP header.

If you are using Next.js middleware for any kind of access control, you should patch before finishing this article.

What happened

Next.js middleware runs before every request and is the default recommended way to enforce authentication across pages and API routes. The bug: internal recursion protection used a header called x-middleware-subrequest to prevent infinite loops. In vulnerable versions, setting this header with a specific value caused Next.js to skip middleware entirely and forward the request directly to the target route.

An unauthenticated attacker could call any protected page or API by adding one HTTP header. No exploitation chain, no authentication required, no complex setup, just a header. Trivial to exploit, trivial to automate, and for months it was sitting in production sites belonging to startups, SaaS companies, and enterprises using Next.js for their web layer.

Fixed versions: 12.3.5, 13.5.9, 14.2.25, and 15.2.3. Older patch trains (11.x, 12.0.x through 12.3.4) received no backport, if you are running those, you must upgrade.

Why this matters to small teams

Most indie developers and small startups rely heavily on middleware precisely because it is the simplest way to protect routes. Patterns like checking a session cookie in middleware.ts and redirecting unauthenticated users to /login are in every Next.js tutorial. That pattern was silently broken for years.

The blast radius is larger than it looks. If your admin dashboard, billing endpoints, or internal APIs rely on middleware for auth, this bug let anyone on the internet reach them. Even sites that also check auth at the route level are affected if they use middleware for rate limiting or geo blocking, those protections were trivially bypassable.

What makes this category of bug especially dangerous for small teams: it is not your code that is broken. The vulnerability lives inside a framework dependency, invisible during code review, invisible in unit tests. The only way to catch it is to keep dependencies patched and to run security scans that verify behavior, not just static code.

How to stay protected

1. Upgrade Next.js immediately to the patched minor of your train: 15.2.3 for 15.x, 14.2.25 for 14.x, 13.5.9 for 13.x, 12.3.5 for 12.x. Run npm audit and npm outdated after upgrading to confirm no other transitive issues.

2. Defense in depth for auth-critical routes. Never rely on middleware alone for authorization on sensitive endpoints. Re-check the user session inside the route handler itself. This is the pattern that saved sites that happened to double-check inside their API routes.

3. Block x-middleware-subrequest at the edge. Add a rule at your CDN or WAF to drop any inbound request carrying this header. Cloudflare, Vercel Edge Config, and AWS WAF all support header-based rules. This provides a backstop even if a future regression reintroduces the bug.

4. Scan your dependency tree for known CVEs continuously. A one-time npm audit is not enough, new CVEs are published daily. Tools that compare your installed versions against NVD on every deploy catch these issues before production users do.

5. Review your GitHub Security Advisories. Enable Dependabot or an equivalent service that notifies you within hours of a CVE being published for a package you use. For critical severities, treat the notification like a pager alert.

How UNPWNED helps

UNPWNED scans your production site for known framework versions, checks running dependencies against the NVD CVE database, and flags severity-ranked issues with AI-generated fix instructions you can paste directly into Cursor, Claude, or your editor. The CVE Fingerprinting scanner in our stack detects exposed framework fingerprints from HTTP responses and tests whether declared versions match known vulnerable releases, including the exact pattern exploited by CVE-2025-29927. If you want to know what your production site looks like to an attacker right now, run a scan.

---

This post was drafted with AI assistance based on authoritative security sources, then published under editorial review.