Top
Best
New

Posted by rayhaanj 12/3/2025

RCE Vulnerability in React and Next.js(github.com)
628 points | 258 commentspage 3
darepublic 12/4/2025|
Next is only good for it's static build, once it drops support for that I'm out.
cced 12/10/2025|
Yeah but even there, how do you get dynamic routes for static builds?
heldrida 12/3/2025||
Do you really need React Server Conponents or even Server Side Rendering?
henryfjordan 12/3/2025||
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.

jazzypants 12/4/2025||
Thank you. It's disappointing that you have to say this on a website full of supposedly technically proficient people.
quentindanjou 12/3/2025|||
It's very use-case dependent.

SSR can be a game-changer in domains like e-commerce. But completely useless for some other use case.

RSC advantages are a bit more complex to explain, because even a simple portfolio website would benefit from it. Contrary to the common belief created by long-term ReactJS dev, RSC simplifies a lot of the logic. Adapting existing code to RSC can be quite a mess and RSC is a big change of mindset for anybody used to ReactJS.

venturecruelty 12/4/2025|||
Yes. Web applications were impossible before these libraries.
Levitating 12/4/2025|||
If you truly believe that than we must really be moving backwards
jeroenhd 12/4/2025||
I think they have a point, before cgi-bin it was almost impossible to have a real web application. It took a decade for server-side rendering to fall out of favour. Flash websites and Gmail starting to become seriously interactive in the mid 2000s were the start of frontend-first web applications, but even those relied on the backend to provide them with an initial data set to make performance usable.
jacquesm 12/4/2025|||
No, they were not. They required a lot more round-trips to the server though, and rendering the results was a lot harder. But if you think of a browser as an intelligent terminal there is no reason why you couldn't run the application server side and display the UI locally, that's just a matter of defining some extra primitives. Graphical terminals were made first in the 60's or so.
gloosx 12/3/2025||
Of course you do, in certain cases making less round-trips to the server is just straight more efficient
testjag 12/5/2025||
How do hacker exploit it? I want to test on my websites
z3ratul163071 12/4/2025||
there can be no React RCE. if it is on the frontend, it is a browser RCE. if it is on the backend, then, as in this case it is a Next.js RCE.
Tomuus 12/4/2025||
The vulnerable code exists inside of the React Flight wire protocol that is used by Next.js but also Vite, Parcel, Waku and any other custom RSC implementation that exists. Your comment was accurate circa 2019 but not since React released server components.
steve_adams_86 12/4/2025|||
You're wrong, but this is one of the unsettling things about the vulnerability and what React has become. Intuitively, you'd think a view library can't have RCE vulnerabilities like this. But that's not what React is anymore.
antonstihl 12/4/2025||
The Next.js server runs React modules. While one may argue that Next.js shouldn't bundle vulnerable dependencies, React does have modules for server-side runtimes these days and should be accountable.
fergie 12/4/2025||
Is there some sort of example exploit somewhere?
darig 12/4/2025||
[dead]
cowsandmilk 12/4/2025||
https://github.com/ejpir/CVE-2025-55182-poc
Tomuus 12/4/2025|||
This POC is not realistic and doesn't work against production builds of Next.js. It requires explicit exposure of gadgets by the user (eg. vm.runInContext) so is invalid as noted on https://react2shell.com
cluckindan 12/4/2025||||
I will believe it works when it is demonstrated against a create-next-app project.
slop-cop 12/4/2025|||
The guy who discovered the actual vulnerability says otherwise.

Delete this distraction to genuine blue teamers and stop shitting up the information landscape with this utter hogwash.

This is why infosec is dead.

https://react2shell.com/

https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...

Copenjin 12/4/2025||
Incredibile, completely unexpected, no one ever ever pointed out that RCS and most of the rest was not good software. No one, no one.
gcau 12/4/2025||
I'm a big fan of react, but all the server stuff was a cold hard mistake, it's only a matter of time before the (entire) react team realises it, assuming their nextjs overlords permit it.
kachapopopow 12/3/2025||
static builds save the day.
nickthegreek 12/3/2025||
dupe: https://news.ycombinator.com/item?id=46136067
anonymars 12/3/2025|
[flagged]
sylware 12/4/2025|
one fixed... one bazillion to go...
More comments...