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

51–60 of 220 posts

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

#51

Post by apsurd »

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"?

seems 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

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

#53

Post by ashishb »

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.

How many startups/small companies that uses next.js do any static verification?

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

#54

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

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

#55

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

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

#56

Post by slowtrek »

jsheard wrote: post #43
butterlettuce wrote: post #8

Vercel’s reputation is so cooked. Jeez.

This recent post by their CEO is funny in hindsight: https://xcancel.com/rauchg/status/1901786957149032869 Hypes up AI coding, hypes up AI for security in particular, then immediately faceplants onto a critical auth bypass.

"It’s too easy for a human today to forget to auth an endpoint."

Woah. Is this real?

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

#57

Post by FINDarkside »

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.

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

#58

Post by rvz »

ronbenton wrote: post #25

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?

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

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

#59

Post by mgraczyk »

ashishb wrote: post #53
mgraczyk wrote: post #47

Earlier quoted context omitted.

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.

How many startups/small companies that uses next.js do any static verification?

I 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

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

#60

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

Post reply on HN