> 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 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.
Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.
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.
That number is misleadingly low, because it doesn't include Next.js which bundles the dependency. Almost all usage in the wild will be Next.js, plus a few using the experimental React Router support.
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
One could get the impression that the only really really important non-functional requirement for such a thing is to absolutely ensure that you can only call the "good" functions with the "good" payload.
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 is not related to ”use server”. That’s used to mark Server Actions / Server Functions, and it is not necessarily used in files with Server Components.
It sounds related to me. The react.dev blog post [1] says that the vulnerability is
> a flaw in how React decodes payloads sent to React Server Function endpoints
and the react.dev docs for React Server Functions [2] say that
> Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive
So it certainly sounds like the vulnerability is related to React Server Functions which are related to "use server".
> 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
https://blog.cloudflare.com/waf-rules-react-vulnerability/
We collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue.
We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.
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.
Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.
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.
It could also be https://github.com/facebook/react/commit/7dc903cd29dac55efb4... ("This also fixes a critical security vulnerability.")
It does the same thing here, too: https://github.com/facebook/react/commit/7dc903cd29dac55efb4...
Link should go to: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
More detail in the React Blog post here https://react.dev/blog/2025/12/03/critical-security-vulnerab...
CVE 10.0 is bonkers for a project this widely used
The packages affected, like [1], literally say:
> Experimental React Flight bindings for DOM using Webpack.
> Use it at your own risk.
311,955 weekly downloads though :-|
[1]: https://www.npmjs.com/package/react-server-dom-webpack
That number is misleadingly low, because it doesn't include Next.js which bundles the dependency. Almost all usage in the wild will be Next.js, plus a few using the experimental React Router support.
React is widely used, react server components not so much.
Next.js is still pretty damn widely used.
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.
easier/more reactivity, doesnt require your api responses to be text parsable to html
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
dupe: https://news.ycombinator.com/item?id=46136067
Hey, just wanted to thank you for your recommendation for The Rehearsal season 2. It was deep, funny, crazy, etc.
Sorry for the off topic, but figured this would be the least offensive spot to commit the faux pas
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.
Where else would it be? What would an RCE of the client even mean?
It's almost like trying to magically wire up your frontend to the backend through magical functions is a bad idea.
One could get the impression that the only really really important non-functional requirement for such a thing is to absolutely ensure that you can only call the "good" functions with the "good" payload.
Look at the money they’ve made to see if it was a bad idea or not.
I don't think money is a good proxy for idea quality. AI? Blockchain? Crime in general? Plenty of bad ideas make a whole lot of money.
Enron made boat loads.
ikr, no way this could have been predicted and warned about for months and months before now.
CV driven development needs new ideas for resume padding regardless of whether the idea is good or bad. Then you get this
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 is not related to ”use server”. That’s used to mark Server Actions / Server Functions, and it is not necessarily used in files with Server Components.
It sounds related to me. The react.dev blog post [1] says that the vulnerability is
> a flaw in how React decodes payloads sent to React Server Function endpoints
and the react.dev docs for React Server Functions [2] say that
> Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive
So it certainly sounds like the vulnerability is related to React Server Functions which are related to "use server".
[1] https://react.dev/blog/2025/12/03/critical-security-vulnerab...
[2] https://react.dev/reference/rsc/server-functions