CVE-2025-29927: Next.js middleware authorization bypass

In March 2025, security researchers disclosed CVE-2025-29927, a critical authorization bypass in Next.js that let an attacker skip middleware execution entirely by sending a single spoofed HTTP header. Because a large share of Next.js applications use middleware as their primary gate for authentication, session validation, and route-level access control, the bug meant that protected admin panels, internal APIs, and gated pages could be reached by anyone who knew how to set one header value. Proof-of-concept exploits appeared within days of disclosure, mass internet scanning followed almost immediately, and CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog shortly after. If your organization ships a Next.js application and leans on middleware for authorization, this is a "patch now" advisory, not a "patch eventually" one.

What Is CVE-2025-29927?

Next.js middleware runs before a request reaches a page or API route, and it's commonly used to redirect unauthenticated users, enforce RBAC checks, rewrite paths, or apply feature flags. To prevent middleware from triggering itself in an infinite loop when it issues an internal rewrite or redirect, the Next.js internals set and check for an x-middleware-subrequest header. If that header is present with an expected value, the framework treats the request as an internal subrequest that has already passed through middleware, and it skips running middleware again.

The vulnerability is that this header was never stripped from, or validated against, external client input. An attacker could simply add x-middleware-subrequest to an outbound HTTP request with the value the framework expected (matching the middleware file's identifier in the chain), and Next.js would conclude the request had already been processed — skipping the middleware, and with it, whatever authorization or redirect logic the middleware was supposed to enforce. In practice, this meant an unauthenticated request could walk straight past a login gate implemented in middleware and land directly on a protected route or API handler, as long as the underlying page or handler didn't perform its own independent authorization check.

This is a textbook "confused deputy" bug: an internal signaling mechanism meant only for the framework's own subrequests was trivially forgeable by any external caller, and the framework trusted it unconditionally.

Affected Versions and Components

The bypass affects self-hosted Next.js deployments that use the middleware feature for authorization, spanning a wide range of release lines:

• Next.js 11.1.4 up to 12.3.4 — fixed in 12.3.5
• Next.js 13.0.0 up to 13.5.8 — fixed in 13.5.9
• Next.js 14.0.0 up to 14.2.24 — fixed in 14.2.25
• Next.js 15.0.0 up to 15.2.2 — fixed in 15.2.3

That range covers roughly three and a half years of releases, which is precisely why this advisory generated so much noise: it's not a narrow edge case in a rarely used feature, it's a core routing primitive that has been part of Next.js since middleware was introduced. Applications deployed on Vercel's managed platform were reported to have additional mitigations in front of them, but self-hosted deployments — on your own Node server, in Docker, behind your own reverse proxy or CDN — were squarely exposed if they hadn't upgraded or applied a compensating control.

It's worth stressing what is and isn't affected: the vulnerability is in how Next.js decides whether to run middleware at all, not in any specific auth library. If your middleware only handles cosmetic redirects or A/B test routing, the practical blast radius is smaller. If your middleware is the sole authorization boundary protecting sensitive routes, the blast radius includes everything behind it.

Severity: CVSS, EPSS, and KEV Status

The GitHub Security Advisory (GHSA-f82v-jwr5-mffw) assigned this issue a CVSS v3.1 base score of 9.1 (Critical), reflecting a network-exploitable, no-privilege, no-user-interaction bypass with a high confidentiality and integrity impact. That said, real-world severity is context-dependent: applications that layer authorization checks in a WAF, CDN, or at the individual route/handler level in addition to middleware see a materially lower practical impact than applications that treat middleware as their only gate. Several analysts and NVD's own scoring later noted this nuance, which is a useful reminder that CVSS reflects worst-case exploitability, not your specific architecture.

EPSS (Exploit Prediction Scoring System) climbed quickly into a high percentile in the days following disclosure, consistent with the rapid appearance of public PoCs and automated scanning traffic hitting exposed Next.js instances across the internet. CISA added CVE-2025-29927 to its Known Exploited Vulnerabilities catalog in the weeks after disclosure, which for federal agencies and their contractors triggers mandatory remediation timelines under Binding Operational Directive 22-01, and for everyone else is a strong signal that this vulnerability moved from "theoretical" to "actively exploited" very fast.

Disclosure Timeline

• Prior to disclosure — Security researchers identified the middleware bypass and reported it responsibly. Vercel began shipping fixes into upstream release branches ahead of the public advisory.
• March 21, 2025 — GHSA-f82v-jwr5-mffw is published publicly, along with patched releases (12.3.5, 13.5.9, 14.2.25, 15.2.3) and an accompanying CVE assignment.
• Within 24–48 hours of disclosure — Independent researchers and red teams publish working proof-of-concept exploits demonstrating the header-spoofing bypass against unpatched instances.
• Following days — Internet-wide scanning activity targeting the x-middleware-subrequest header spikes, and security vendors report opportunistic exploitation attempts against unpatched, internet-facing Next.js deployments.
• Weeks after disclosure — CISA adds the CVE to the KEV catalog, citing confirmed exploitation in the wild.

The compressed gap between disclosure and mass exploitation is the headline lesson here: teams that treated this as a routine dependency bump got ahead of it; teams that queued it behind a normal patch-review cycle were exposed to active scanning and exploitation for a meaningful window.

Remediation Steps

1. Upgrade Next.js immediately to a patched release for your major version line: 12.3.5, 13.5.9, 14.2.25, or 15.2.3 (or later). This is the only fix that closes the root cause.
2. If you cannot upgrade right away, add a compensating control at your edge: strip or reject any inbound request that sets the x-middleware-subrequest header before it reaches your Next.js origin. This is straightforward to implement at a CDN, load balancer, reverse proxy, or WAF layer and neutralizes the specific bypass vector until you can ship the upgrade.
3. Audit where authorization actually lives in your application. If middleware is your only enforcement point for sensitive routes, add redundant checks inside the route handlers, page components, or API layer themselves. Defense in depth here means this class of framework-level bypass can't fully compromise your access control on its own.
4. Review logs for exploitation attempts. Look for inbound requests carrying an x-middleware-subrequest header from external clients — that header should never legitimately originate outside your own infrastructure, so its presence in access logs is a strong indicator of probing or active exploitation.
5. Re-test protected routes post-patch. Confirm that unauthenticated requests to previously gated paths are correctly redirected or rejected after upgrading, rather than assuming the version bump alone resolved your specific configuration.
6. Track downstream dependents. If you maintain internal frameworks, templates, or starter kits built on Next.js, push the version bump through those artifacts too — vulnerable middleware patterns tend to get copy-pasted across projects.

How Safeguard Helps

Vulnerabilities like CVE-2025-29927 expose the gap between "a CVE exists in a dependency" and "this CVE is actually reachable and exploitable in my running application" — and that gap is exactly where Safeguard's reachability analysis operates, tracing whether your specific middleware configuration and route structure put you in the exposed path rather than flagging every Next.js instance as equally urgent. Griffin, Safeguard's AI security analyst, correlates the vulnerable version, your middleware usage patterns, and any compensating controls already in place to tell you in plain language whether this is a drop-everything incident or a routine patch cycle for your codebase. Safeguard's SBOM generation and ingestion continuously tracks every Next.js instance across your services and repos, so when a KEV-listed CVE like this one drops, you get an inventory-backed answer to "where are we exposed" in minutes instead of a manual grep across dozens of package.json files. For the fix itself, Safeguard can open an auto-fix pull request that bumps Next.js to the patched release and flags any middleware-only authorization patterns worth hardening, cutting the time between advisory and remediated production code from days to hours.