11 ms·
Next.js version 15.2.3 has been released to address a security vulnerability
- dvektor 2y agoOuch, 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.
- makepanic 2y ago> 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.
- magicalhippo 2y agoNot a web dev, so struggling a bit to understand this. Are they saying they had a special flag that allowed requests to bypass auth, intended to be used by calls generated internally? And someone figured out you could just send that on the first request and skip auth entirely?
- acdha 2y agoIf I’m reading the code right, it support their hybrid model where your code can run in three places: the user’s browser, Vercel’s edge, and an actual server. It looks like the idea was for when code in the edge context to be able to call the server faster but it was not protected to keep anyone else from calling it directly. If I he for that right, this is a security review failure since people perennially try that optimization and have it end poorly for reasons like this. It’s safer, and almost always less work, to treat all calls equally and optimize if needed rather than having to support an “internal” call type over the same interface.
- czk 2y agoAs I understand it, the middleware runs before a request hits a page or API route.. so to avoid infinite loops from internal subrequests (URL rewrites, etc), Next.js tags them with the x-middleware-subrequest header. This tells the runtime to skip middleware for those requests and proceed directly to the target. Unfortunately this also works externally.
- deleted 2y ago[deleted]
- banana_dick_12 2y ago[dead]
- banana_dick_12 2y ago[dead]
- ldjkfkdsjnv 2y agoThis 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.
- teaearlgraycold 2y agoWritten by anybody
- nextts 2y agoVibe coding framework of choice
- deleted 2y ago[deleted]
- mrits 2y agoIt's going to take awhile for the LLMs to catch up so we can un-vibe our way out of this
- colonelspace 2y agoUnvibe AI (YC S25) is hiring.
- fHr 2y agowhat a timeline to witness, absolute glorious
- slowtrek 2y agoWhat is debugging in vibe coding? If the vibe changes, that's gotta be a blocker. If the vibe changes, then I guess you are stuck and need to white board or go for a walk? I talk a lot of shit about Gen-Z, but they come up with the best terms. Interviewer: How do you handle vibe changes in vibe coding? Candidate: I can handle any type of vibe change. Interviewer: This is exactly what we are looking for.
- urbandw311er 2y agoWe 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.
- mrits 2y agoI spent about a week coding in it trying to to figure out what the hype was about. I decided to go with django/htmx. A year later I have absolutely no regrets.
- whoknowsidont 2y agoHN has a very weird mind-set when it comes to JS frameworks. Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.
- bdangubic 2y agoexpect you know, when you can bypass auth by adding an http header :)
- whoknowsidont 2y agoNot that this isn't a serious attack vector (a possible one), but most implementations are not simply using middleware as a standalone check for authorization then blindly serving paths/content up. That'd be pretty bad architecture in any stack.
- butterlettuce 2y agoVercel’s reputation is so cooked. Jeez.
- ilrwbwrkhv 2y agoI mean their whole product is geared towards bad developers. And I don't say that loosely. I literally mean bad developers. Developers who do not understand what a product is and how learning something slightly more difficult such as servers and things of that nature that actually can make for a better product.
- ronbenton 2y agoMy biggest concern about these so-called “isomorphic frameworks” is they’re trying to abstract away the server/client distinction. I don’t see how that doesn’t result in tons of security bugs. Or maybe I’m just an old fart.
- FirmwareBurner 2y agoWhat product alternative to Nextjs would you say is targeted towards "good developers"?
- apsurd 2y agoseems pretty reasonable to me. it's not that it's 100% accurate. it's that anything that has higher barrier to entry automatically acts as a filter. complied languages, esoteric languages, i mean it's pretty reasonable. you have to go out of your way to learn more stuff and there's more pain. ergo: you're probably "better" than a script kiddie that "vibe coded" a boilerplate saas to launch their influencer passive income side hustle
- slowtrek 2y agoThere's no marketable benefit to using Mootools to build web apps at the moment.
- _m_p 2y agohttps://www.phoenixframework.org/ https://www.phoenixframework.org/
- czk 2y agoit only took 16 days to triage a global next.js auth bypass
- Lucasoato 2y agoIs NextJS considered safe? Would you build something for the government or a big Corp with it?
- nextts 2y agoNo. I wasn't concerned about security but just churn. They keep changing things. They also don't fix stuff people care about alot. I'd just use Koa and keep it simple.
- zxor 2y agoYes, as much hate as it tends to get on here it's really fine. This vulnerability is unfortunate but every library/framework will have security issues over its lifespan.
- notnullorvoid 2y agoThe trivial nature of the initial exploit does not instil confidence, nor does it that no one noticed it during the refactor that lead to the second variation of the exploit.
- acdha 2y agoI think you have to ask what it’s compared to. Certainly this is no worse than things we’ve seen in the PHP or Java space and people still use those. However, there is one argument you could make regarding the massive amount of complexity which Next takes on trying to blur client and server execution. That’s prone to creating confusion around validation and control flow, which is a notorious source of security vulnerabilities and it looks like this might be another one as it appears to be related to how they try to transition from edge execution to server-side. So less a Next-specific point than recognizing that poor architecture is an ongoing risk. This kind approach has been tried and generally failed to deliver in it’s promised repeatedly over the decades because it only saves time building out a quick demo. Once you have a real app, with multiple people working on it, you really want a clear definition of what runs where because it’s much easier to reasonable about security, performance, and reliability if you don’t have layers of abstraction trying to pretend unlike things are alike.
- ratorx 2y agoI found a different article that goes into more detail: https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-auth-bypass 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.
- jsheard 2y ago> 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. That's basically the same way phone phreaking worked back in the day. Time is a flat circle.
- dontlaugh 2y agoSomehow people never learn to avoid in-band signalling.
- wmil 2y agoLLMs have the same problem a la "ignore previous requests". The fundamental problem is that you always either need two signalling paths or you have to specially encode all user content so that it can never conflict with the signalling. Those are both a pain in the ass, so people always try to figure out how to make in band signalling work.
- FINDarkside 2y agoThat "article" looks like AI generated slop. It suggests `if (request.headers.has('x-middleware-subrequest'))` in your middleware as a fix for the problem, while the whole vulnerability is that your middleware won't be executed when that header is present.
- tdhz77 2y agoI 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.
- koolba 2y agoWhat does this get you over vanilla express servicing a react front end? Is it the rest of the deploy infra? The vanilla app you can push to Heroku or any of its clones.
- crab_galaxy 2y agoThey’re different tools. If I were building a JS server for a backend, I’d use Express. Next gives you things like server side rendering and static site generation out of the box, and abstracts/blurs the line between server and client code through its paradigms. For better or for worse. The deploy infrastructure is quite nice. Nextjs is surprisingly low config, even if you forego the Vercel deployment route it’s not difficult to generate a static site or docker container
- shepherdjerred 2y agoIs Astro a good alternative? https://astro.build/ https://astro.build/
- CharlieDigital 2y agoWhat other ones have you tried recently?
- ronbenton 2y agoI am concerned it took over 2 weeks to start triaging a security bug along the lines of "auth can be bypassed"
- ronbenton 2y agoOh 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?
- rvz 2y ago> So... just adding a "x-middleware-subrequest: true" header bypasses auth? Am I understanding this correctly? correct. That is how serious this bypass is and why it is a severity 9.1 (I think it should be a 9.8, as it is so trivial by adding a single header.)
- tshaddox 2y ago“Bypasses auth” is a weird way to put it, although everyone seems to describe it in those terms. It bypasses middleware, which is bad (and embarrassing for Vercel), but middleware shouldn’t be responsible for access control. The middleware shouldn’t be doing much more than redirecting to the sign-in page if you don’t have a session.
- ibash 2y agoWhy shouldn’t middleware be responsible for access control?
- jonny_eh 2y agoThat should be the server. Your Nextjs app should have zero access to business data without at least an auth token. And if you're relying on middleware for auth, it'll be responsible for providing that auth token to the rest of the app. And if you bypass middleware, then there's no auth token, and no vulnerability. This is only a vulnerability if you have pages you don't want to render for some people, regardless of upstream data it would need to fetch.
- quonn 2y ago
- ramoz 2y agoVC 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.
- ryoshu 2y agoSSR is fine. We used to call it "PHP" or "Ruby" or "Java." People need to stop reinventing things, but feature development outweighs maturity when you have funding.
- someothherguyy 2y ago> People need to stop reinventing things Why?
- slowtrek 2y agoBecause it denies people a chance to live in peace. If the ego constantly needs to justify itself, then we can't live in peace. If you need to learn, please do so on your own and bring what you can from your private learnings. It's not obvious to the rest of us why their framework needs such a security apparatus. The reason it's not obvious is because most of us don't see it as obvious (by definition, its not an obvious thing they are doing). Security, of all things, should be obvious to us all. As in, most of us should go "well this could have happened to any of us", but I don't think we are all thinking that. We are kind of thinking, "why would you confuse security to this degree across these layers?".
- ramoz 2y agoOf course, nothing wrong with Request comes in → server processes it → HTML
- tacker2000 2y agoThere is a big difference here. The stuff you mention was “born” at the backend and was then used to render frontend html at the very beginning then css, then JS etc…, but going from a frontend framework like React to the backend is an entirely different beast.
- ashishb 2y agoNext.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).
- mgraczyk 2y agoI don't think this is true in principle. It should be pretty easy to statically verify that the separation is safe using something similar to trusted types and the Typescript type checker. It's not possible in Next.js, but that doesn't mean the premise is wrong.
- ashishb 2y agoHow many startups/small companies that uses next.js do any static verification?
- mgraczyk 2y agoI don't know, but I am just pointing out that the problems here are really about execution, not vision. There's no reason we can't properly enforce security boundaries in the browser, we already do it between the website's code and the local machine. These ideas have been around a long time and predate the internet. See for example Liskov's work on Thor: https://dl.acm.org/doi/pdf/10.1145/233269.233346 https://dl.acm.org/doi/pdf/10.1145/233269.233346
- prdonahue 2y agoVibe security.
- mikeocool 2y agoLooking 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?
- dimgl 2y ago> React added a lot of complexity to the front end, I keep hearing this but I disagree completely. Does no one remember Angular.js? Backbone? Ember.js? Even my favorite framework, Knockout, had lots of complexity. SSR has been misused widely for years and we’re now starting to see the effects of that. But there ARE great use cases for SSR. And frontend dev is the easiest it’s ever been. Run Vite Create and you have a fully working React SPA that can deployed in minutes on Render.com. No more messing with Webpack, or Bower, or Brocolli, or Gulp or Grunt or whatever madness came before. Frontend dev is in the best place it’s been in years.
- whoknowsidont 2y agoNope. Commenters here love to just state "X is over complicated!!!" when React is about the least complicated UI system across any medium there is.
- BoorishBears 2y agoNext has made React pretty complicated with RSC. And Next itself is abandoning all reason, like implementing redirects that break if you catch exceptions (because they're exceptions) and server actions that silently fail if a network issue occurs.
- braebo 2y agoYou clearly haven’t used Svelte. React is the most convoluted pile of bad abstractions of all of the big frameworks.
- ronbenton 2y agoThis 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
- no_wizard 2y agoSeems indicative of the companies priorities especially as of late. This has always been an issue with Vercel. I highly recommend people stay way from their stuff.
- cromka 2y agoWhat's the next best alternative? Astro?
- braebo 2y agoSvelteKit hands down.
- shepherdjerred 2y agoWhat do you get out of Next.js over vanilla React? I've never understood why that ecosystem is so popular. Anyway though, Astro is lovely, especially for static site generation.
- l0gicpath 2y agoThere’s a great deal of value in the “fullstack meta-frameworks” model of things. For one, using the same language on the backend and frontend is underrated feature. But Next.js is not the only option on the market, so I partially echo your sentiment, not around React SPA vs React fullstack, but around Next.js vs a half dozen better alternatives for the React ecosystem.
- rvz 2y ago1) 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.
- notnullorvoid 2y ago> This is beyond damning. Absolutely agree. > 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. I would hardly say the whole JS ecosystem is immature. There's tons of mature projects that take security very seriously and are written by highly skilled programmers. > 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 There are certainly many fresh programmers entering the ecosystem and "vibe coding" among other hyped trends are able to ride that wave. It's pretty clear that those hyping it are either new themselves (don't know better), or cater to an audience of new programmers. Those in the latter group are doing it to farm engagement, and/or are really out of touch from what real software systems look like/require. The silent majority of moderate to highly experienced JS programmers know that these LLMs produce shit code outside of boilerplate and small demos. It's very easy to tell if you try to use them on anything else. It is concerning on many levels though that new programmers are being guided off a cliff like this. Programming influencers and companies advocating for "vibe coding" and the like should be called out for sabotaging the next generation of programmers.
- smlx 2y agonext.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 https://github.com/vercel/next.js/pull/73482/files In this vulnerability, adding a 'x-middleware-rewrite: https://www.example.com 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/repository/release-channels-publishing.md 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.
- czk 2y agoHeh, that commit you linked added a bunch of headers to INTERNAL_HEADERS (to prevent external use) but they forgot to add the one in this particular vulnerability. This was done in December 2024. There were probably a myriad of vulnerabilities with these headers before that commit. Wild it wasn’t a CVE.
- tmpz22 2y agoLook, we need to show some restraint here and some class. Vercel has only raised $538 million dollars, its not reasonable to be so critical of their security practices when weighed against the business value of their products.
- lilnasy 2y agoNot to mention the same critical vulnerability in Clerk's Next.js SDK, which should've been a wake up call. https://clerk.com/changelog/2024-02-02#:~:text=Our%20solution%20was%20to%20decorate%20the%20request%20with%20an%20additional%20header%20containing%20a%20boolean%20that%20indicated%20the%20authentication%20state. https://clerk.com/changelog/2024-02-02#:~:text=Our%20solutio...
- banana_dick_11 2y ago[flagged]
- banana_dick_11 2y ago[flagged]
- banana_dick_11 2y ago[flagged]
- banana_dick_12 2y ago[flagged]
- banana_dick_12 2y ago[dead]
- banana_dick_12 2y ago[dead]
- banana_dick_13 2y ago[dead]
- greysteil 2y agoCan 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.
- ianschmitz 2y agoIt took over two weeks to triage on Vercel’s side after disclosure. How is that “good”?
- blahbblah25 2y ago[dead]
- impulser_ 2y agoIf anyone is looking for a good alternate to NextJS, try looking into Tanstack Start. It's currently Beta but it will probably be the best way to build full stack React apps when it hits 1.0 so it might be worth looking into for future apps. You just add a plugin into Vite and gain SSR, streaming, server functions, API routes with minimal configuration. You basically just add a ssr.tsx and client.tsx file into your existing TanStack Router application and it becomes full stack with full type safe. If you want to go back to a React SPA just remove the plugin and config it back to SPA. I built an app with it recently and it has an amazing DX. Best part you can literally run it anywhere. It builds for any platform with a single configuration.
- blovescoffee 2y agoWhat makes it a good alternative? The fact it’s in beta would be a non starter for my org but it’s possible once it’s out of beta it would be worth looking at.
- azemetre 2y agoIs Vercel any different in this regard? they’ve often broke APIs between releases too. The fact that a company that raised $500million is on par with a small team of volunteers is more damning not less.
- unplug8224 2y agoThe maintainer also renamed their most popular package (react-query, which was ubiquitous and highly regarded) to fit their eponymous Tanstack branding, meaning if you didn't hear about it somewhere else you would just stop being notified of updates.
- zohaib304 2y ago[dead]
- zohaib304 2y ago[dead]
- dminik 2y agoTbh the entire middleware system in Next is awful and everyone would be better off if it was scrapped and reimplemented from scratch. For starters, there's no official way to chain multiple middlewares. If you want to do multiple things, you either stuff it all into a single function or you have to implement the chaining logic yourself. Worse, the main functions (next, redirect, rewrite, ...) are static members on an imported object. This means that if you use third party middlewares, they will just automatically do the wrong thing and break your chaining functionality. Then, there's no good way to communicate between the middleware and the route handlers. Funnily enough the only working one was to stuff data through headers and then retrieve it through headers(). If someone knows your internal header names this could be very unsafe. One additional issue with that is that headers() turns your route handler into a dynamic one. This opts you out of automatic caching. I think they recently gave up on this entirely, but this was the second biggest feature of Next 14 and you lost it because you needed data from the middleware ... And lastly it still hides information from you. For whatever reason request.hostname is always localhost. Along with some other properties that you might need being obfuscated. If you really wanted to get the actual hostname you needed to grab it out of the "Host" header. I'm not really surprised that the header/middleware system is insecure.
- IceDane 2y agoI would argue if you're trying to chain middleware or communicate between middleware, you're already holding it wrong. In basically every other framework you would have similar issues, in that there is no good, safe way to achieve what you're describing except persisting some data on an object and then hoping for the best. It's brittle, not type safe and just generally poor design. With that said, I do agree that nextjs middleware is trash. My main issue with it is that I never use nextjs on vercel, always on node, but I'm still limited in what I can use in middleware because they're supposed to be edge-safe. Eye roll. They are apparently remedying this, but this sort of thing is typical for next.
- ervine 2y agoWatch out, Lee is gonna show up and defend this decision and not respond to any valid criticisms.
- rglover 2y agoIf you want a simple but powerful full-stack JS framework (literally, client and server are separated as they should be—no trickery) that is being built carefully and slowly, check out Joystick [1][2]. To put it in simple terms: if Next.js is the hare, Joystick is the tortoise. It uses plain HTML, CSS, and JS for components (no React, Vue, Svelte, etc.—just simple components any skill-level can grok) in an easy-to-learn API and pairs that with a batteries-included Node.js back-end built on top of Express. The server automatically does old fashioned server-side rendering in routes (literally a callback function mapped to a URL pattern w/ req and res objects). This is not "just another JS framework." I intentionally designed it to not behave like Next.js and other JS frameworks (I take "never trust the client" very, very seriously). [1] https://cheatcode.co/joystick https://cheatcode.co/joystick [2] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- foldr 2y agoI find middleware annoying in general. It saves some typing, but it makes debugging much harder because you have to dig through layers of nested middleware to figure out why you’re seeing a 404, unexpected redirect, or whatever. I’d rather just factor common logic into a function and call it in the handler for every route that needs it. Boring, repetitive - but easy to understand and debug. It probably is a good idea to have some kind of thin middleware layer that adds an extra layer of auth protection, so that it’s more difficult to accidentally do something like allowing access to /api routes for users that aren’t logged in. But for reasons that are obvious in this context, you should never rely entirely on URL-based logic to protect access to resources.
- yieldcrv 2y agoI like NextJS and this vulnerability requires a specific self-hosting arrangement coupled with specific flag I think this discussion is bringing a lot of unrelated angst out of the wood works that is beyond the level of rationality warranted I think its rightful to be skeptical of Vercel’s incentives to vendor lock, and how long it took to deal with this vulnerability. Thats all independent of most of what I’m reading here