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

RCE Vulnerability in React and Next.js

github.com

Post reply on HN
Print view View original

91–100 of 276 posts

Re: RCE Vulnerability in React and Next.js

#91

Post by halflife »

cluckindan wrote: post #86
halflife wrote: post #58

Earlier quoted context omitted.

Maybe if they compiled away their runtime like svelte and somewhat like angular, then running SSR would be faster.

SSR with CSR is a worst-of-both-worlds approach. It leads to brittle ”isomorphic” behaviors when the same code needs to handle both SSR and CSR, inevitable client-side ”hydration” mismatches and various other issues. The same code needs to fetch eagerly but minimally, but also use and update the server-provided data on the client-side. Ultimately that so-called ”isomorphism” causes more numerous and difficult problem…

Sounds a little like hooks.

A purist approach with short term thinking got everyone deep in a rabbit hole with too many pitfalls.

Re: RCE Vulnerability in React and Next.js

#92

Post by FINDarkside »

swyx wrote: post #81
root_axis wrote: post #59

Earlier quoted context omitted.

As far as I'm aware, transitive dependencies are counted in this number. So when you npm install next.js, the download count for everything in its dependency tree gets incremented. Beyond that, I think there is good reason to believe that the number is inflated due to automated downloads from things like CI pipelines, where hundreds or thousands of downloads might only represent a single instance in the wild.

why is it not normal for CI pipelines to cache these things? its a huge waste of compute and network.

It's certainly not uncommon to cache deps in CI. But at least at some point CircleCI was so slow at saving+restoring cache that it was actually faster to just download all the deps. Generally speaking for small/medium projects installing all deps is very fast and bandwidth is basically free, so it's natural many projects don't cache any of it.

Re: RCE Vulnerability in React and Next.js

#93

Post by samdoesnothing »

cluckindan wrote: post #86
halflife wrote: post #58

Earlier quoted context omitted.

Maybe if they compiled away their runtime like svelte and somewhat like angular, then running SSR would be faster.

SSR with CSR is a worst-of-both-worlds approach. It leads to brittle ”isomorphic” behaviors when the same code needs to handle both SSR and CSR, inevitable client-side ”hydration” mismatches and various other issues. The same code needs to fetch eagerly but minimally, but also use and update the server-provided data on the client-side. Ultimately that so-called ”isomorphism” causes more numerous and difficult problem…

Especially cuz the vast majority of sites can either just be client rendered SPA's or server rendered multipage apps. There is no need for the complexity for most sites and yet this is the default for pretty much all js frameworks...

Re: RCE Vulnerability in React and Next.js

#95

Post by mirashii »

filearts wrote: post #19
embedding-shape wrote: post #6

From Facebook/Meta: https://www.facebook.com/security/advisories/cve-2025-55182 > A pre-authentication remote code execution vulnerability exists in React Server Components versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 including the following packages: react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack. The vulnerable code unsafely deserializes payloads from HTTP requests to Server Functi…

Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.

This comment from a dupe thread is worth considering: https://news.ycombinator.com/item?id=46137352

Re: RCE Vulnerability in React and Next.js

#96

Post by rvnx »

dizlexic wrote: post #75
coffeecoders wrote: post #35

This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…

They were warned. I don't see how this can be characterized as anything but sloppy.

You can call anything, anytime, anywhere without restrictions or protection.

Imagine these dozens of people, working at Meta.

They sit at the table, they agree to call eval() and not think "what could go wrong"

Re: RCE Vulnerability in React and Next.js

#97

Post by homebrewer »

mvdtnz wrote: post #67
javaking wrote: post #32

I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.

It's just the latest take on what we had 20 years ago with .NET's WebForms and Java's JSF. Both of which tried to hide the network separation between client and server and were not fun to work with.

Those who don't learn history are bound to repeat it, and all that.

Re: RCE Vulnerability in React and Next.js

#98

Post by j45 »

koakuma-chan wrote: post #78
coffeecoders wrote: post #41

Earlier quoted context omitted.

Not quite. This isn’t saying React or Next.js are fundamentally insecure in general. The problem is this specific "call whatever server code the client asks" pattern. Traditional APIs with defined endpoints don’t have that issue.

You mean call whatever server action the client asks? I don't think having this vulnerability was intentional.

I don’t think I’ve heard of intentional vulnerabilities?

Re: RCE Vulnerability in React and Next.js

#99

Post by henryfjordan »

punkbit wrote: post #65

Do you really need React Server Conponents or even Server Side Rendering?

Before SSR (unless you were using PHP I guess) you had to ship a shell of a site with all the conditionals being decided only AFTER the browser has gotten all the HTML + JS pulled down. If you need to make any API calls, you've delayed rendering by hundreds of milliseconds or worse (round trip to your server)

With SSR, those round trips to the server could be down to single-digit milliseconds assuming your frontend server is in the same datacenter as your backend. Plus you send HTML that has actual content to be rendered right away.

A truly functional pageload can go from seconds to milliseconds, and you're transferring less data over the wire. Better all around at the expense of running a React Server instead of a static file host.

Post reply on HN