Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js version 15.2.3 has been released to address a security vulnerability

nextjs.org

Post reply on HN
Print view View original

81–90 of 220 posts

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#81

Post by dimgl »

mikeocool wrote: post #50

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 yo…

> 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.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#83

Post by 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.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#84

Post by acdha »

c0redump wrote: post #45
acdha wrote: post #19

Earlier quoted context omitted.

I 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 vulner…

> no worse than things we’ve seen in Java space My memory fails me - I can’t recall a vulnerability in the JVM ecosystem that allows an attacker to circumvent auth entirely with such trivial ease. Can you name an example?

This doesn’t necessarily allow attackers to circumvent authentication entirely - it’s a framework so it depends on how you configure your app - but there have been plenty of vulnerabilities over the years which break auth or even allow an RCE for the conceptually similar challenge of trying to support complex proxying setups or, more broadly, failing to have clean boundaries for untrusted data.

I’m not defending this one - it’s bad, and an indicator about technical debt levels - but simply trying to encourage some humility about this. It’s not the language, it’s the complexity and attempts to paper over rather than reduce it.

If you want the most recent similar one I’ve seen, Apache Camel had one last week where you could inject their internal magic headers by using different case than the developers expected.

Going a bit older, in some ways this Tomcat exploit from 2020 feels similar because it’s an unenforced internal trust boundary. The AJP connector was more trusted, but also enabled hy default on all ports.

https://issues.apache.org/jira/plugins/servlet/mobile#issue/...

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#85

Post by slowtrek »

FirmwareBurner wrote: post #30
ilrwbwrkhv wrote: post #26

Earlier quoted context omitted.

I 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.

What product alternative to Nextjs would you say is targeted towards "good developers"?

There's no marketable benefit to using Mootools to build web apps at the moment.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#86

Post by no_wizard »

ronbenton wrote: post #54

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 repo…

Seems 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.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#87

Post by ratorx »

FINDarkside wrote: post #57
ratorx wrote: post #17

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 re…

That "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.

You’re right - I was specifically referring to it giving a concrete example (which may or may not be correct) of the vulnerability as opposed to the main article just pointing in the direction of the header.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#88

Post by no_wizard »

urbandw311er wrote: post #4

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.

After going through hell with self hosting and then their platform around version 12 we migrated away.

I recommend finding something else. In our case we moved that code to what is now react router 7 but eventually all the react code we have will get replaced by Vue in some manner. We mostly moved away from react as a whole over time

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#89

Post by acdha »

mgraczyk wrote: post #47
ashishb wrote: post #39

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).

I 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.

That could help in some cases (maybe even the areas where their server-side replicas of browser APIs aren’t quite consistent), but how would it handle things like someone putting a validation or access control check in the client-side code? A lot of these things come down to the code correctly doing what a confused author intended.

In this case, it’d also be interesting to try to figure out how a fix would look like in that model. You could have some way for a type-checker to tell the requests apart such as a union type for Client|Edge|Server requests but you’d need a way to assert that the header couldn’t be present on all of them, which suggests the real problem is using in-band signaling. It seems like a solid argument for type-checking since making the relationship clear enough to validate also makes it harder for humans to screw up.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#90

Post by czk »

smlx wrote: post #60

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 t…

Heh, 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.
Post reply on HN