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

101–110 of 276 posts

Re: RCE Vulnerability in React and Next.js

#101

Post by IgorPartola »

j45 wrote: post #89
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.

I’m not asking if it’s fundamentally insecure. Architecturally there appears to be an increasingly insecure attack surface appearing in JavaScript at large, based on the insecurities in mandatory dependencies. If the foundation and dependencies of react has vulnerabilities, react will have security issues indirectly and directly. This explicit issue seems to be a head scratcher. How could something so basic exist for…

To be fair, the huge JavaScript attack surface has ALWAYS been there. JavaScript runs in a really dynamic environment and everything from XSS-onwards has been fundamentally due to why you can do with the environment.

If you remember “mashups” these were basically just using the fact that you can load any code from any remote server and run it alongside your code and code from other servers while sharing credentials between all of them. But hey it is very useful to let Stripe run their stripe.js on your domain. And AdSense. And Mixpanel. And while we are at it let’s let npm install 1000 packages for a single dependency project. It’s bad.

Re: RCE Vulnerability in React and Next.js

#102

Post by tshaddox »

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…

To me it just looks like unacceptable carelessness, not an indictment of the alleged "lack of explicitness" versus something like gRPC. Explicit schemas aren't going to help you if you're so careless that, right at the last moment, you allow untrusted user input to reference anything whatsoever in the server's name space.

Re: RCE Vulnerability in React and Next.js

#103

Post by harrall »

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

I see this type of vulnerability all the time. Seen it in Java, Lua, JavaScript, Python and so on.

I think deserialization that relying on blacklists of properties is a dangerous game.

I think rolling your own object deserialization in a library that isn’t fully dedicated to deserialization is about as dangerous as writing your own encryption code.

Re: RCE Vulnerability in React and Next.js

#104

Post by ivanjermakov »

_el1s7 wrote: post #50

Next.js/RSC has become the new PHP :) I guess now we'll see more bots scanning websites for "/_next" path rather than "/wp-content".

Inevitable when the line between the client and the server is blurred this much. RCE in a UI library is not a phrase you hear often.

Re: RCE Vulnerability in React and Next.js

#105

Post by yearolinuxdsktp »

halflife wrote: post #88
azangru wrote: post #84

Earlier quoted context omitted.

> They had minimal API changes in the last 10 years The 1 to 2 transition was one hell of a burn though; people are probably still smarting...

Well, the official statement is that 1 and 2 are 2 different frameworks. That’s why they were later named to angular JS and angular, to avoid confusion. The migration path between angular 1 and 2 is the same as react and angular, it’s just glue holding 2 frameworks together And that change happened 10 years ago

Easy migration was promised but never delivered. Angular 2 was still full of boilerplate. “Migrating” an AngularJS project to Angular 2 is as much work as porting it to React or anything else.

So yes, people got burnt (when we were told that there will be a migration path), and I will never rely on another Google-backed UI framework.

Re: RCE Vulnerability in React and Next.js

#106

Post by WatchDog »

j45 wrote: post #37
AgentK20 wrote: post #2

CVE 10.0 is bonkers for a project this widely used

The subjects of theses types of posts should report the CVSS severity as 10.0 so the PR speak can't simply deflect to what needs to be done.

A CVSS score of 10.0 may be warranted in this case, but so many other CVSS scores are wildly inflated, that the scores don't mean a lot.

Re: RCE Vulnerability in React and Next.js

#107

Post by morshu9001 »

j45 wrote: post #98
koakuma-chan wrote: post #78

Earlier quoted context omitted.

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?

Log4j almost seemed like it

Re: RCE Vulnerability in React and Next.js

#108

Post by morshu9001 »

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…

"React Server Functions allow a client to call a function on a server"

Intentionally? That's a scary feature

Re: RCE Vulnerability in React and Next.js

#109

Post by morshu9001 »

halflife wrote: post #54

Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve? What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compile…

I like the hooks :(
Post reply on HN