RCE Vulnerability in React and Next.js • Hacker News Board

Re: RCE Vulnerability in React and Next.js

#111

Post by azangru » Thu, Dec 04, 2025, 12:02 AM UTC

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

> That’s why they were later named to angular JS and angular, to avoid confusion.

Angular.js and angular. That's not confusing at all :-)

Re: RCE Vulnerability in React and Next.js

#112

Post by azangru » Thu, Dec 04, 2025, 12:05 AM UTC

yearolinuxdsktp wrote: post #105

halflife wrote: post #88

Earlier quoted context omitted.

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.

> I will never rely on another Google-backed UI framework.

Lit is pretty good :-) Though it was never positioned as a framework. And it recently was liberated from google.

Re: RCE Vulnerability in React and Next.js

#113

Post by altbdoor » Thu, Dec 04, 2025, 12:15 AM UTC

azangru wrote: post #84

halflife wrote: post #61

Earlier quoted context omitted.

IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated. And what they DO add? Only things that improve dev exp

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

It was one hell of a ride, but I would say the Angular team did one hell of a job too, supporting the glue code until v18 (not sure if the latest version still does).

Having both old and new Angular running in one project is super weird, but everything worked out in the end.

Re: RCE Vulnerability in React and Next.js

#114

Post by chatmasta » Thu, Dec 04, 2025, 12:24 AM UTC

ethanwillis wrote: post #60

TranquilMarmot wrote: post #51

Earlier quoted context omitted.

Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.

Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare. They don't address the exact same markets.

Yeah… one of them addresses a market populated by hundreds of thousands of developers with extensive professional experience in the framework, and the other addresses a niche of Python developers who refused to learn JavaScript until somebody hid it from them and called it hypermedia.

Re: RCE Vulnerability in React and Next.js

#115

Post by j45 » Thu, Dec 04, 2025, 12:31 AM UTC

WatchDog wrote: post #106

j45 wrote: post #37

Earlier quoted context omitted.

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.

Regardless it can still provide some context and adjustment cs none.

The above could be seen as spin too, how could cvss be more accurate so you’d feel better?

Re: RCE Vulnerability in React and Next.js

#116

Post by WatchDog » Thu, Dec 04, 2025, 12:47 AM UTC

ejpir wrote: post #79

I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc

I ran your exploit-rce-v4.js with and without the patched react-server-dom-webpack, and both of them executed the RCE.

So I don't think this mechanism is exactly correct, can you demo it with an actual nextjs project, instead of your mock server?

Re: RCE Vulnerability in React and Next.js

#117

Post by venturecruelty » Thu, Dec 04, 2025, 12:59 AM UTC

dzonga wrote: post #24

till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.

React lets you inflate your salary.

Re: RCE Vulnerability in React and Next.js

#118

Post by jacquesm » Thu, Dec 04, 2025, 12:59 AM UTC

tshaddox wrote: post #102

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.

But once that particular design decision is made it is a question of time before that happens. The one enables the other.

The fact that React embodies an RPC scheme in disguise is quite obvious if you look at the kind of functionality that is implemented, some of that simply can not be done any other way. But then you should own that decision and add all of the safeguards that such a mechanism requires, you can't bolt those on after the fact.

Re: RCE Vulnerability in React and Next.js

#119

Post by ejpir » Thu, Dec 04, 2025, 1:00 AM UTC

WatchDog wrote: post #116

ejpir wrote: post #79

I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc

I ran your exploit-rce-v4.js with and without the patched react-server-dom-webpack, and both of them executed the RCE. So I don't think this mechanism is exactly correct, can you demo it with an actual nextjs project, instead of your mock server?

I'm trying that, nextjs is a little different because it uses a Proxy object before it passes through, which blocks the rce.

I'm debugging it currently, maybe I'm not on the right path after all.

Re: RCE Vulnerability in React and Next.js

#120

Post by jacquesm » Thu, Dec 04, 2025, 1:01 AM UTC

rvnx wrote: post #96

dizlexic wrote: post #75

Earlier quoted context omitted.

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"

Eval has been known to be super dangerous since before the internet grew up and went mainstream. It is so dangerous that to deploy stuff containing it should come with a large flashing warning whenever you run it.