Next.js Middleware Authorization Bypass (CVE-2025-29927)

What to do

1. Check the installed version with npm ls next and upgrade to 15.2.3+, 14.2.25+, 13.5.9+ or 12.3.5+ (or any current release).
2. Strip or reject the x-middleware-subrequest header at your reverse proxy, load balancer, CDN or WAF before traffic reaches the Next.js server.
3. Move critical authorization checks into route handlers, server actions or the backend so middleware is not the only gate.
4. Treat Next.js 11.x as unsupported: it has no patch, so rely on header stripping and plan a migration.
5. Search access logs for inbound requests carrying x-middleware-subrequest that reached protected routes.

How to check if you are affected or compromised

• Run npm ls next (or check package-lock.json) in every self-hosted Next.js service and compare against the fixed versions.
• Grep proxy or WAF logs for the x-middleware-subrequest header on external requests, especially values like middleware, src/middleware or the name repeated with colons.
• Look for successful (2xx) responses on admin or authenticated paths with no corresponding login or session.

What happened#

On March 21, 2025, the Next.js maintainers published GHSA-f82v-jwr5-mffw (CVE-2025-29927), a critical authorization bypass in Next.js middleware. The CVSS 3.1 score is 9.1. Next.js uses an internal header, x-middleware-subrequest, to keep middleware from running again on its own internal subrequests. The server did not check whether that header came from outside. If a client sent it with the right value, the server skipped middleware entirely and passed the request straight to the route.

The researchers, Allam Rachid (zhero;) and Allam Yasser (inzo_), explained the mechanics. Before 12.2 the header value had to match the middleware file path, for example pages/_middleware. From 12.2 on it was simply middleware or src/middleware. Newer releases added a recursion-depth limit of 5, so the bypass value is the middleware name repeated five times with colons between them. Either way an attacker only had to try a couple of guesses. The impact depends on what your middleware does: skipped auth redirects, missing CSP and security headers, or a cache-poisoning denial of service when skipped locale rewrites produce error pages that a CDN then caches.

Vercel's postmortem says the bug was reported on February 27, 2025, triage was delayed, and fixes shipped March 17–23.

Who is affected#

Affected ranges are 11.1.4 to before 12.3.5, 13.0.0 to before 13.5.9, 14.0 to before 14.2.25, and 15.0 to before 15.2.3. Version 11.x was never patched. Only self-hosted apps are in scope, meaning those run with next start or output: 'standalone'. Vercel says its own platform, Netlify and Cloudflare Workers were never affected because routing runs in a separate layer there. Static exports were not affected either, since middleware does not run without a server.

Do you really need to act?#

The fix is 19 months old, so for most teams this is a hygiene check, not an emergency. The flaw is serious only when two things are both true: you self-host, and your middleware is the thing that decides who sees protected pages. If middleware only does logging or i18n, the worst realistic outcome is the cache-poisoning DoS.

Exploitation is trivial and public. Datadog published a proof of concept and reported a relatively low volume of scans that it called "small in volume, ineffective, and poorly targeted." Wiz notes a very high EPSS score. As of the October 21, 2026 KEV snapshot, the CVE is not in CISA's Known Exploited Vulnerabilities catalog. Watch out for Docker images and side projects pinned to old Next.js versions. They are the likeliest place for this bug to still be live.

What to do now#

1. Inventory versions with npm ls next (or check lockfiles and container images). Upgrade to 15.2.3+, 14.2.25+, 13.5.9+ or 12.3.5+. Any current release is fine.
2. Add a rule at your proxy, CDN or WAF that strips or rejects inbound x-middleware-subrequest. This is the advisory's official workaround, and it also protects 11.x.
3. Don't use middleware as your only authorization layer. Re-check the session in route handlers, server actions or APIs as well.
4. If you still run 11.x, header stripping is the only mitigation. Plan the upgrade.

How to tell if you were hit#

Search edge and application logs for external requests that carry x-middleware-subrequest, especially values like middleware, src/middleware or colon-repeated names. Datadog cautions that some of this header traffic from platforms like Vercel is legitimate, so look at the source before drawing conclusions. Then correlate those requests with 2xx responses on admin or authenticated routes from clients that never logged in. If you find such hits on a vulnerable version, treat whatever those routes expose as accessed, and rotate any credentials or tokens they could reveal.

Timeline#

• Feb 27, 2025 — Vulnerability reported privately via GitHub.
• Mar 17, 2025 — Patch merged; Next.js 14.2.25 released.
• Mar 18, 2025 — Next.js 15.2.3 released; CVE-2025-29927 assigned.
• Mar 21, 2025 — Advisory made public.
• Mar 22, 2025 — Backport 13.5.9 released.
• Mar 23, 2025 — Backport 12.3.5 released.
• Mar 25, 2025 — Vercel publishes its postmortem.

Vulnerability records

• CVE-2025-29927 · Next.js is a React framework for building full-stack web applications.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. GitHub Advisory — Authorization Bypass in Next.js Middleware (GHSA-f82v-jwr5-mffw) github.com
2. Vercel — Postmortem on Next.js Middleware bypass vercel.com
3. zhero; and inzo_ — Next.js and the corrupt middleware zhero-web-sec.github.io
4. Datadog Security Labs — Next.js middleware auth bypass (CVE-2025-29927) securitylabs.datadoghq.com
5. Wiz — CVE-2025-29927 vulnerability database entry wiz.io