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

151–160 of 220 posts

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

#151

Post by abxyz »

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.

I like NextJS and actively choose it for many projects. However, there is a big caveat: self-hosting NextJS is not the "real" NextJS experience that most people have because most people are using Vercel's platform and that is the focus of Vercel. Self-hosting NextJS is a bad idea, the benefits of NextJS are inextricably linked to the Vercel platform. You will live to regret self-hosting. I would never, ever consider doing it again and still suffer the pain of it day in day out because of a bad decision I made a few years ago. Use NextJS as expected (on Vercel's platform) or don't use it. If you self-host on your own serverless infrastructure, that's not a terrible idea, but if you try to self-host NextJS on servers, it will fall over at the first hint of traffic.

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

#152

Post by urbandw311er »

abxyz wrote: post #151
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.

I like NextJS and actively choose it for many projects. However, there is a big caveat: self-hosting NextJS is not the "real" NextJS experience that most people have because most people are using Vercel's platform and that is the focus of Vercel. Self-hosting NextJS is a bad idea, the benefits of NextJS are inextricably linked to the Vercel platform. You will live to regret self-hosting. I would never, ever consider…

I’d like to understand more about why this is and whether your experience is universal.

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

#153

Post by arandomusername »

whoknowsidont wrote: post #101
arandomusername wrote: post #100

Earlier quoted context omitted.

I disagree. Why pollute every function with code checking for auth if you can just do it in a middleware?

You don't do it everywhere. You do it in the source system. The Next.JS application should just be doing "sanity" checks and passing along identity information at most. That belongs in the middleware layer, but it's not authoritative. If bypassing a middleware layer is the one "trust me bro" check you have in your web app, then lol. That's actually really hilarious and you should tell me what company/website that's f…

Isn't next.js the "source system" (or whatever that means) in most cases, since most apps are just next.js + database? I don't use next.js but my understanding is it does both backend and frontend.

You will never bypass middleware on my services because they actually always run. If you can't rely on your middleware then you are using the wrong tech.

I haven't heard any good reason as to why not have auth in your middleware lawyer. Just attempt to shrug it away as a "trust me bro" check. Are if statements trust me bro too? Only thing you shouldn't be doing is using garbage software like next js

From next.js homepage > Middleware > Take control of the incoming request. Use code to define routing and access rules for authentication, experimentation, and internationalization.

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

#154

Post by wmil »

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…

> Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen.

I'm going to disagree on this. Browsers and ISPs have a long history of adding random headers, a website can't possibly function while throwing an error for any unknown header. That's just the way HTTP works.

This is clearly a case of the Next devs being silly. At a minimum they should have gone with something like `-vercel-` as the prefix instead of the standard `x-` so that firewalls could easily filter out the requests with a wildcard.

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

#155

Post by dminik »

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

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

#156

Post by wmil »

dontlaugh wrote: post #61
jsheard wrote: post #34

Earlier quoted context omitted.

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

Somehow people never learn to avoid in-band signalling.

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

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

#157

Post by ratorx »

wmil wrote: post #154
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…

> Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen. I'm going to disagree on this. Browsers and ISPs have a long history of adding random headers, a website can't possibly function while throwing an error for any unknown header. That's just the way HTTP works. This is clearly a case of the Next devs being silly. At a minimum they should have gone with someth…

Well, there’s 2 possibilities:

1) Plain HTTP, go wild with headers. No system should have any authenticated services on this.

2) HTTP with integrity provided by a transport layer (so HTTPS, but also HTTP over Wireguard etc for example). All headers are untrusted input, accept only a whitelisted subset.

With this framing, I don’t think it’s an unreasonable for a given service to make the determination of which behaviour to allow.

I guess browser headers are still a problem. But you can get most of the way by dropping them at the request boundary before forwarding the request.

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

#158

Post by masklinn »

wmil wrote: post #154
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…

> Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen. I'm going to disagree on this. Browsers and ISPs have a long history of adding random headers, a website can't possibly function while throwing an error for any unknown header. That's just the way HTTP works. This is clearly a case of the Next devs being silly. At a minimum they should have gone with someth…

Even if they had to make things go through headers (a bad idea in and of itself, in-band signalling always causes issues), the smart move would have been to make it a non-string, such that clients would not be able to pass in a valid value.

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

#159

Post by pier25 »

bawolff wrote: post #149
pier25 wrote: post #138

Earlier quoted context omitted.

> no evidence of in the wild exploitation That's how zero day exploits work. People keep it quiet so they can keep exploiting it.

Sure, but its also how vulns not currently being exploited works. Good security is about risk management. For a vuln not thought to be exploited, an extra week or two is a reasonable cost/benefit to ensure a proper job was done fixing it and making sure nobody has to pull an all nighter. If they sat on it for a year, that would be a different story.

It's impossible to know how many people knew about it before it was reported. It's also trivial to add a header to bypass middleware. Apparently it was there since v12 released in 2021 so god only knows how much damage this has caused already.

And let's not forget there are still many unpatched Next self hosted apps, right now.

I can't believe how anyone can downplay this in any way.

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

#160

Post by arnaudsm »

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…

Most bad tech decisions of Next.js are motivated by their business model, notably the middleware system to promote edge functions.

If you're looking for something simpler that's closer to Next's original premice, Remix.js is awesome and much lighter.

Post reply on HN