alt Hacker NewsRCE Vulnerability in React and Next.js
Comments
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 Function endpoints.
React's own words: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
> React Server Functions allow a client to call a function on a server. React provides integration points and tools that frameworks and bundlers use to help React code run on both the client and the server. React translates requests on the client into HTTP requests which are forwarded to a server. On the server, React translates the HTTP request into a function call and returns the needed data to the client.
> An unauthenticated attacker could craft a malicious HTTP request to any Server Function endpoint that, when deserialized by React, achieves remote code execution on the server. Further details of the vulnerability will be provided after the rollout of the fix is complete.
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 compiler, but instead of going the svelte route of handling the entire state, it only adds memoization?
If I can send a direct message to the react team it would be to abandon all their current plans, and work on allowing users to write native JS control flows in their component logic.
sorry for the rant.
I suspect the commit to fix is:
https://github.com/facebook/react/commit/bbed0b0ee64b89353a4...
and it looks like its been squashed with some other stuff to hide it or maybe there are other problems as well.
this pattern appears 4 times and looks like it is reducing the functions that are exposed to the 'whitelist'. i presume the modules have dangerous functions in the prototype chain and clients were able to invoke them.
- return moduleExports[metadata.name];
+ if (hasOwnProperty.call(moduleExports, metadata.name)) {
+ return moduleExports[metadata.name];
+ }
+ return (undefined: any);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
> Projects hosted on Vercel benefit from platform-level protections that already block malicious request patterns associated with this issue.
https://vercel.com/changelog/cve-2025-55182
> Cloudflare WAF proactively protects against React vulnerability
More detail in the React Blog post here https://react.dev/blog/2025/12/03/critical-security-vulnerab...
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".
Link should go to: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
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.
This is genuinely embarrassing for the Next.js and React teams. They were warned for years that their approach to server-client communication had risks, derided and ignored everyone who didn't provide unconditional praise, and now this.
I think their time as Javascript thought leaders is past due.
Do you really need React Server Conponents or even Server Side Rendering?
I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb
It's almost like trying to magically wire up your frontend to the backend through magical functions is a bad idea.
static builds save the day.
The CVE says the that flaw is in React Server Components, which implies strongly that this is a RCE on the backend (!!), not the client.
AHAHAHAHAHA, I'm sorry but we all knew this would happen.
I'm just laughing because I called it when they were in the "random idea x posts" about use server.
They'll fix it, but this was what we were warning about.
edit: downvote if you want, but I'm sorry React thinking they could shoehorn "use server" in and not create huge vulnerabilities was a pipe dream at best. I vote gross negligence because EVERYONE knew this was going to happen.
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).
We can patch hasOwnProperty and tighten the deserializer, but there is deeper issue. React never really acknowledged that it was building an RPC layer. If you look at actual RPC frameworks like gPRC or even old school SOAP, they all start with schemas, explicit service definitions and a bunch of tooling to prevent boundary confusion. React went the opposite way: the API surface is whatever your bundler can see, and the endpoint is whatever the client asks for.My guess is this won't be the last time we see security fallout from that design choice. Not because React is sloppy, but because it’s trying to solve a problem category that traditionally requires explicitness, not magic.