Live data from Hacker News

RCE Vulnerability in React and Next.js

github.com

211–220 of 276 posts

Re: RCE Vulnerability in React and Next.js

#211
post #188

Earlier quoted context omitted.

I couldn't agree more. I'll probably switch from React to something like ArrowJS in my personal work: https://www.arrow-js.com/docs/ It makes it easy to have a central JSON-like state object representing what's on the page, then have components watch that for changes and re-render. That avoids the opaqueness of Redux and promise chains, which can be difficult to examine and debug (unless we add browser extensions for…

Nobody is using Redux any more, and it's even publically discouraged by the creator. It's a legacy system and including it in your problems list just makes me think you have no React experience and no idea what you are talking about (beyond technical yapping also Redux as a product still achieved what it tried to solve so your dx doesn't even matter). Firebase in this context is just a database and how you poll data…

I love reading this while my boss is pushing "redux everything" as the next step in our (React 17) codebase...

Re: RCE Vulnerability in React and Next.js

#212
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".

I have seen a number of attempts at exploiting this on our deployment already. Luckily I saw and was able to apply the patch last night, but as a European, it wasn't great to only get the announcement after dinner time.

Re: RCE Vulnerability in React and Next.js

#213
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

Thanks for the writeup, it's incredible!

The PoC is AI generated crap - sorry for the initial comment lauding it. I should have checked better. See: https://github.com/ejpir/CVE-2025-55182-poc/issues/1 and https://react2shell.com/

Re: RCE Vulnerability in React and Next.js

#214

Earlier quoted context omitted.

Half of web map solutions rely on workers, which can't be easily loaded from 3rd party origins, so are loaded as blobs. loading worker from blob is effectively an eval.

The client sort of exists to have code injected into it though?

If you want to describe text mark-up as programming, then yes. But most people do not do that.

Re: RCE Vulnerability in React and Next.js

#215

Earlier quoted context omitted.

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.

hmm isn't eval is used in figurative-sense here eh? maybe you should get some sleep

No, their whole point is that what they are doing is the literal equivalent of calling eval. Whether that actually uses the word 'eval' or a function called 'eval' is besides the point.

Re: RCE Vulnerability in React and Next.js

#216

Earlier quoted context omitted.

100’s of thousands used to use php too :) most developers (roughly 97.56% are terrible/incompetent so going with the herd should tell you you are on the wrong train :)

Thousands of developers still use PHP… and even more users… Wordpress (43% of web), Facebook (billions of users), Wikipedia (billions of users)…. all PHP. htmx is a a toy, mildly amusing to play with, built on an insecure foundation that bypasses basic browser security controls and hands a blob of JavaScript to a bunch of backend developers who can’t be bothered to learn it because they think they know better… No ser…

“No serious project uses [insert any framework/language/…] and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development” if team is incompetent

Re: RCE Vulnerability in React and Next.js

#218

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…

Just like the old days of PHP servers exposing their source code

Re: RCE Vulnerability in React and Next.js

#219

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.

This is only really fine as long as you have extremely clearly, well defined actions. You need to verify that the request is sane, well-formed, and makes sense for the current context, at the very least.

Re: RCE Vulnerability in React and Next.js

#220
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

FYI as of just now, the author has (correctly) added a disclaimer that this poc doesnt quite work.
Post reply on HN