Live data from Hacker News

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

nextjs.org

131–140 of 220 posts

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

#131
post #99

Earlier quoted context omitted.

What's the next best alternative? Astro?

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

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

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

#132

Earlier quoted context omitted.

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

nextjs is in a class of software that should not exists (backend-for-frontend). You can have an SPA and an API in any backend language/framework.

Agreed. A SPA without some backend for front end is always going to push you to store authentication tokens in local storage.

It feels like a shortcoming in browsers that we need a BFF to resort to cookies that JS can’t access.

I like React, but I feel that we primarily use Next.js just for session cookie management.

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

#133
post #114

Earlier quoted context omitted.

Why shouldn’t middleware be responsible for access control?

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

The issue is, everyone uses middleware because Next.js doesn't provide a primitive for a middleware like how it's done for any other framework. Just something to execute before your endpoint, that's it.

They haven't had one for years and everyone wrapped their endpoints which was error prone and also flat out annoying, it's reasonable that people then jump to middleware

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

#134
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…

Unfortunately, in-band signalling seems to be the norm when dealing with HTTP. There isn't really a standard mechanism for wrapping up an HTTP request in a standard format and delivering it, plus some trusted metadata, over HTTP to another service.

Or if there is, and I've somehow missed it, please *please* share it with me.

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

#135

Earlier quoted context omitted.

Yeah, "obvious" critical vulnerability that is easy to use against any Nextjs app, spend 2 weeks making a fix and then announce on Friday evening that all Nextjs apps are free game. Lovely. Luckily doens't affect any of the sites I'm responsible for, since I hated middleware and most of the Nextjs "magic" features already.

> spend 2 weeks making a fix They didn't spend 2 weeks making a fix, that took a few hours. It took them two weeks to look at the report.

It took them a week to respond about the initial report for v12.0.0, the exploit was so trivial and obvious that even that should have been a warning to go check newer versions themselves, even if they hadn't seen the follow up message that had been sent a few days prior showing that the vulnerability was present in later versions.

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

#136
post #118
post #94

Earlier quoted context omitted.

> 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. You're using a different frame of reference. Those people you're referring to, including gp, probably mean that frameworks add complexity to the frontend. That would include all the ones you listed.

Okay, so go before that the jQuery (should win the Nobel Peace Prize) used with vanilla JS building absolutely bonkers custom scripts all over the place. React was a paradigm shift towards more complex frontend apps, but there was still complexity. It replaced a bunch of .erb or mustache or whatever templating that then tried to be interactive with JS layered on. What React replaced was not less complex overall, thou…

I don't think people like GP are arguing that there is no place for these frameworks. the argument is that there are too many people just using these frameworks in projects where it may not be needed and blindly running "npm create react-app" or whatever. Then you add something like NextJS on top which makes things even worse.

I would argue that majority of NextJS projects are not needed to be built in NextJS but could do with simpler front end JS.

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

#137
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…

Unfortunately, in-band signalling seems to be the norm when dealing with HTTP. There isn't really a standard mechanism for wrapping up an HTTP request in a standard format and delivering it, plus some trusted metadata, over HTTP to another service. Or if there is, and I've somehow missed it, please *please* share it with me.

Just use MIME multipart content-type to wrap an HTTP message inside another. This is commonly done for batching requests. Here is an example of how it might look like: https://cloud.google.com/storage/docs/batch#http

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

#138

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…

If there is no evidence of in the wild exploitation and no reason to think the vulnerability is publicly known, then 2 weeks seems like an acceptable turn around time. If you start looking at big corps, you will very quickly find instances of fairly severe vulns that sit for months before a fix is issue. (I'm assuming "started triaging" actually means worked on fixed. If they didnt even respond to reporter for 2 week…

> no evidence of in the wild exploitation

That's how zero day exploits work. People keep it quiet so they can keep exploiting it.

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

#139
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…

Unfortunately, in-band signalling seems to be the norm when dealing with HTTP. There isn't really a standard mechanism for wrapping up an HTTP request in a standard format and delivering it, plus some trusted metadata, over HTTP to another service. Or if there is, and I've somehow missed it, please *please* share it with me.

This is something like it, though no finished standard exists: https://en.wikipedia.org/wiki/HAR_%28file_format%29

(An abandoned spec is at https://w3c.github.io/web-performance/specs/HAR/Overview.htm...)

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

#140

Earlier quoted context omitted.

What's the takeaway?

The takeaway is that most people don’t think this way. A large portion of online recommendations for auth in Nextjs recommends middlewares for it. Knowing this, you’d expect a faster response time from the people maintaining the framework and stand to lose the most.

The Vercel-like auth company Vercel's CEO invested in default recommends middleware for protecting routes:

https://clerk.com/docs/references/nextjs/clerk-middleware

You wouldn't get a user's info, but you'd get free reign to explore every page of a product

Post reply on HN