Next.js version 15.2.3 has been released to address a security vulnerability (CVE-2025-29927). Additionally, backported patches are available.
We recommend that all self-hosted Next.js deployments using next start and output: 'standalone' should update immediately.
Continue reading for more details on the CVE.
Timeline
2025-02-27T06:03Z: Disclosure to Next.js team via GitHub private vulnerability reporting2025-03-14T17:13Z: Next.js team started triaging the report2025-03-14T19:08Z: Patch pushed for Next.js 15.x2025-03-14T19:26Z: Patch pushed for Next.js 14.x2025-03-17T22:44Z: Next.js 14.2.25 released2025-03-18T00:23Z: Next.js 15.2.3 released2025-03-18T18:03Z: CVE-2025-29927 issued by GitHub2025-03-21T10:17Z: Security Advisory published2025-03-22T21:21Z: Next.js 13.5.9 released
We are also publishing a backport for v12. We will update this post as they are released.
Vulnerability details
Next.js uses an internal header x-middleware-subrequest to prevent recursive requests from triggering infinite loops. The security report showed it was possible to skip running Middleware, which could allow requests to skip critical checks—such as authorization cookie validation—before reaching routes.
Impact scope
Affected
- Self-hosted Next.js applications using Middleware (
next startwith output:standalone) - This affects you if you rely on Middleware for auth or security checks, which are not then validated later in your application.
- Applications using Cloudflare can turn on a Managed WAF rule
Not affected
- Applications hosted on Vercel
- Applications hosted on Netlify
- Applications deployed as static exports (Middleware not executed)
Patched versions
- For Next.js 15.x, this issue is fixed in
15.2.3 - For Next.js 14.x, this issue is fixed in
14.2.25 - For Next.js 13.x, this issue is fixed in
13.5.9
If patching to a safe version is infeasible, it is recommended that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application.
We are also publishing a backport for v12. We will update this post as they are released.
Our security responsibility
Next.js has published 16 security advisories since 2016. Over time, we’ve continued to improve how we gather, patch, and disclose vulnerabilities.
GitHub Security Advisories and CVEs are industry-standard approaches to notifying users, vendors, and companies of vulnerabilities in software. While we have pub
22 Comments
makepanic
> Next.js uses an internal header x-middleware-subrequest to prevent recursive requests from triggering infinite loops. The security report showed it was possible to skip running Middleware, which could allow requests to skip critical checks—such as authorization cookie validation—before reaching routes.
ldjkfkdsjnv
This is one of the worst security vulnerabilities I have seen in a while. It's so blatant, so easy to exploit. So many nextjs applications written by beginners that are completely exposed.
urbandw311er
We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype.
The more comments I read about it in HN, the less comfortable I feel about this decision.
butterlettuce
Vercel’s reputation is so cooked. Jeez.
czk
it only took 16 days to triage a global next.js auth bypass
Lucasoato
Is NextJS considered safe? Would you build something for the government or a big Corp with it?
ratorx
I found a different article that goes into more detail:
https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-a…
This looks trivially easy to bypass.
More generally, the entire concept of using middleware which communicates using the same mechanism that is also used for untrusted user input seems pretty wild to me. It divorces the place you need to write code for user request validation (as soon as the user request arrives) from the middleware itself.
Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen. I think the mindset of ignoring unknown/invalid parts of a request as long as some of it is valid also plays a role.
The framework providing crutches for bad server design is also a consequence of this mindset – are there any concrete use cases where the flow for processing a request should not be a DAG? Allowing recursive requests across authentication boundaries seems like a problem waiting to happen as well.
tdhz77
I hate how productive with this framework I am. I try to move on and can’t. I’ll take a security hit to use it lover leptos.
ronbenton
I am concerned it took over 2 weeks to start triaging a security bug along the lines of "auth can be bypassed"
ronbenton
Oh my word:
The exploit involves crafting HTTP requests containing the malicious header:
GET /protected-route HTTP/1.1
Host: vulnerable-app.com
x-middleware-subrequest: true
So… just adding a "x-middleware-subrequest: true" header bypasses auth? Am I understanding this correctly?
ramoz
VC influence in the web space has been a fascinating thing.
I hope Next's downfall sends a signal to the quality lib maintainers and changes direction (e.g. Remix and a f'd up router, TanStack w/ Start).
SSR frameworks make me vomit.
ashishb
Next.js is based on a fundamentally flawed premise that one can write code that runs in the browser as well as the backend.
The security posture for the code running in the browser is very different from the code running on a trusted backend.
A separation of concerns allows one to have two codebases, one frontend (untrustworthy but limited access) and one backend (trustworthy but a lot of access).
prdonahue
Vibe security.
mikeocool
Looking at next I have to think that something went horribly wrong with front end development. It adds so much complexity for things that provide such minimal value to most apps.
React added a lot of complexity to the front end, but, for an app with a lot of front end state, brought a ton of value.
Next brings us file based routing, which seems cool, until you get into any sort of mildly complex use case, and — if your careful and don’t fuck it up, server side rendering, which I guess is cool, if you’re building an e-commerce product and is maybe cool for maybe a few other verticals?
dvektor
Ouch, 13 days to triage that is crazy. I definitely wasn't in need of any more reasons not to use something like nextJS, but I'll add this to my list.
ronbenton
This is a wild vuln in how trivial it is to execute. But maybe even wilder is the timeframe to event _start_ triaging the bug after it was reported. How? Was it incorrectly named? Was the severity not correctly stated? Someone help me understand how this sits for 2+ weeks.
2025-02-27T06:03Z: Disclosure to Next.js team via GitHub private vulnerability reporting
2025-03-14T17:13Z: Next.js team started triaging the report
rvz
1) What.
Add a single header 'x-middleware-subrequest' and it allows you to completely bypass any self-hosted Next.js middleware, including authorization.
This is beyond damning.
It's also exactly the reason why the whole Javascript ecosystem is really showing how immature it is and the hype and euphoria of Vercel is contributing to its clumsiness.
They are now also pushing "Vibe Coding", which is a hot air hype parade, about to be brutally hit with reality when others are deploying production code that is riddled with hundreds of security vulnerabilities.
A delightful golden age for professional security researchers.
smlx
next.js has a history of similar vulnerabilities.
I was made aware recently of a vulnerability that was fixed by this patch: https://github.com/vercel/next.js/pull/73482/files
In this vulnerability, adding a 'x-middleware-rewrite: https://www.example.com' header would cause the server to respond with the contents of example.com. i.e. the worlds dumbest SSRF.
Note that there is no CVE for this vulnerability, nor is there any clear information about which versions are affected.
Also note that according to the published support policy for nextjs only "stable" (15.2.x) and "canary" (15.3.x) receive patches. But for the vulnerability reported here they are releasing patches for 14.x and 13.x apparently?
https://github.com/vercel/next.js/blob/canary/contributing/r…
IMO you are playing with fire using nextjs for anything where you care about security and maintenance. Which seems insane for a project with 130k+ Github stars and supported by a major company like vercel.
banana_dick_12
[flagged]
banana_dick_13
[dead]
greysteil
Can we take a moment to appreciate how good the disclosure and coordination process on this were?
* Reported to the maintainers privately
* Patch published and CVE issued before wider disclosure
* Automated fix PRs created within minutes of public disclosure (and for folks doing proactive updates, before)
The above is _really_ excellent. Compare that to Log4j, which no CVE and no patch at the time it became public knowledge, and it's clear we've come a long way.
Supply chain security isn't a solved problem – there's lots we can still improve, and not everything here was perfect. But hats off to @leerob and everyone else involved in handling a tough situation really well.
blahbblah25
[dead]