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…
RCE Vulnerability in React and Next.js
211–220 of 276 posts
Re: RCE Vulnerability in React and Next.js
#212Next.js/RSC has become the new PHP :) I guess now we'll see more bots scanning websites for "/_next" path rather than "/wp-content".
Re: RCE Vulnerability in React and Next.js
#213I'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!
Re: RCE Vulnerability in React and Next.js
#214Earlier 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?
Re: RCE Vulnerability in React and Next.js
#215Earlier 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
Re: RCE Vulnerability in React and Next.js
#216Earlier 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…
Re: RCE Vulnerability in React and Next.js
#217Re: RCE Vulnerability in React and Next.js
#218This 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…
Re: RCE Vulnerability in React and Next.js
#219Earlier 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.
Re: RCE Vulnerability in React and Next.js
#220I'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