RCE Vulnerability in React and Next.js
56 comments
·December 3, 2025coffeecoders
sophiebits
The endpoint is not whatever the client asks for. It's marked specifically as exposed to the user with "use server". Of course the people who designed this recognize that this is designing an RPC system.
A similar bug could be introduced in the implementation of other RPC systems too. It's not entirely specific to this design.
(I contribute to React but not really on RSC.)
j45
For the layperson, does this mean this approach and everything that doesn't use it is not secure?
Building a private, out of date repo doesn't seem great either.
coffeecoders
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.
halflife
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.
paularmstrong
> What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering?
RSC is their solution to not being able to figure out how to make SSR faster and an attempt to reduce client-side bloat (which also failed)
paulhebert
I wish React wasn’t the “default” framework.
I agree that the developer experience provided by the compiler model used in Svelte and React is much nicer to work with
embedding-shape
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.
filearts
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__.
benmmurphy
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);hackhomelab
It could also be https://github.com/facebook/react/commit/7dc903cd29dac55efb4... ("This also fixes a critical security vulnerability.")
nine_k
It does the same thing here, too: https://github.com/facebook/react/commit/7dc903cd29dac55efb4...
karimf
> 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
Rauchg
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.
semiquaver
Does AWS WAF have a mitigation in place?
serhalp
Same for Netlify: https://www.netlify.com/changelog/2025-12-03-react-security-...
and Deno Deploy/Subhosting: https://deno.com/blog/react-server-functions-rce
_el1s7
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".
phelm
More detail in the React Blog post here https://react.dev/blog/2025/12/03/critical-security-vulnerab...
AgentK20
CVE 10.0 is bonkers for a project this widely used
nine_k
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 :-|
ascorbic
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.
j45
The subjects of theses types of posts should report the CVSS severity as 10.0 so the PR speak can't simply deflect to what needs to be done.
rs_rs_rs_rs_rs
React is widely used, react server components not so much.
_jab
Next.js is still pretty damn widely used.
dzonga
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.
leptons
>now cz of the complexity I refuse to work with react.
What do you like to work with now?
TranquilMarmot
Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.
switz
They lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly.
It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the developer with more grounded flexibility than RSCs. I wrote a blog post about this[0].
To answer your question, htmx solves this by leaning on the server immensely. It doesn't provide a complete client-side framework when you need it. RSCs allow both the server and the client to co-exist, simply composing between the two while maintaining the full power of each.
[0] https://saewitz.com/server-components-give-you-optionality
ptx
But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be marked as simply and clearly as possible instead.
paulhebert
Yep! It’s really hard to reason in Next about when things happen on the server vs client. This makes it harder to make things secure.
You can create clean separation in your code to make this easier to understand but it’s not well enforced by default.
AstroBen
You can optionally enhance it and use React on the client. Doing that with HTMX is doable with "islands" but a bit more of a pain in the ass - and you'll struggle hard if you attempt to share client state across pages. Actually there are just a lot of little gotchas with the htmx approach
I mean it's a lot of complexity but ideally you shouldn't bring it in unless you actually need it. These solutions do solve real problems. The only issue is people try to use it everywhere. I don't use RSC, standard SPAs are fine for my projects and simpler
nonethewiser
easier/more reactivity, doesnt require your api responses to be text parsable to html
null
croemer
Link should go to: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
c-hendricks
Anyone know how Tanstack Start isn't affected?
serhalp
TanStack Start has its own implementation of Server Functions: https://tanstack.com/start/latest/docs/framework/solid/guide.... It doesn't use React Server Functions, in part because it intends to be agnostic of the rendering framework (it currently supports React and Solid).
To be fair, they also haven't released (even experimental) RSC support yet, so maybe they lucked out on timing here.
dimitrisnl
They haven't implemented RSC yet.
javaking
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
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.