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).
return moduleExports[metadata.name]
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.
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.
> 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__.
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.
I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a <script> (server calling client). You can still have an API layer of course, but this gives you a syntactical way to express that there's a piece of backend that prepares data for this piece of frontend.
This resolves tensions between evolving both sides: the each piece of backend always prepares the exact data the corresponding piece of frontend needs because they're literally bound by a function call (or rather JSX). This also lets you load data as granularly as you want without blocking (very nice when you have a low-latency data layer).
Of course you can still have a traditional REST API if you want. But you can also have UI-specific server computation in the middle. There's inherent tension between the data needed to display the UI (a view model) and the way the data is stored (database model); RSC gives you a place to put UI-specific logic that should execute on the backend but keeps composability benefits of components.
Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh.
I understand the logic, but there are several issues I can think of.
1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.
2 - as react was always celebrated as an unopinionated framework, RSC creates a deep coupling between 2 layers which were classically very far apart.
Here are a list of things that would rather have react provide:
- advanced form functionality that binds to model, and supports validation
- i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed
- signals, for proper reactive state
- better templating ability for control flows
- native animation library
All of these things are important so I wouldn’t have to learn each new project’s permutation of the libraries de jour.
IMO angular provides such a great experience developing.
They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated.
And what they DO add? Only things that improve dev exp
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 that stuff, which feels like a code smell).
I've also heard heard good things about Astro, which can wrap components written in other frameworks (like React) so that a total rewrite can be avoided:
I'm way outside my wheelhouse on this as a backend developer, so if anyone knows the actual names of the frameworks I'm trying to remember (hah), please let us know.
IMHO React creates far more problems than it solves:
- Virtual DOM: just use Facebook's vast budget to fix the browser's DOM so it renders 1000 fps using the GPU, memoization, caching, etc and then add the HTML parsing cruft over that
- Redux: doesn't actually solve state transfer between backend and frontend like, say, Firebase
- JSX: do we really need this when Javascript has template literals now?
- Routing: so much work to make permalinks when file-based URLs already worked fine 30 years ago and the browser was the V in MVC
- Components: steep learning curve (but why?) and they didn't even bother to implement hooks for class components, instead putting that work onto users, and don't tell us that's hard when packages like react-universal-hooks and react-hookable-component do it
- Endless browser console warnings about render changing state and other errata: just design a unidirectional data flow that detects infinite loops so that this scenario isn't possible
I'll just stop there. The more I learn about React, the less I like it. That's one of the primary ways that I know that there's no there there when learning new tools. I also had the same experience with the magic convention over configuration in Ruby.
What's really going on here, and what I would like to work on if I ever win the internet lottery (unlikely now with the arrival of AI since app sales will soon plummet along with website traffic) is a distributed logic flow. In other words, a framework where developers write a single thread of execution that doesn't care if it's running on backend or frontend, that handles all state synchronization, preferably favoring a deterministic fork/join runtime like Go over async behavior with promise chains. It would work a bit like a conflict-free replicated data type (CRDT) or software transactional memory (STM) but with full atomicity/consistency/isolation/durability (ACID) compliance. So we could finally get back to writing what looks like backend code in Node.js, PHP/Laravel, whatever, but have it run in the browser too so that users can lose their internet connection and merge conflicts "just work" when they go back online.
Somewhat ironically, I thought that was how Node.js worked before I learned it, where maybe we could wrap portions of the code to have @backend {} or @frontend {} annotations that told it where to run. I never dreamed that it would go through so much handwaving to even allow module imports in the browser!
But instead, it seems that framework maintainers that reached any level of success just pulled up the ladder behind them, doing little or nothing to advance the status quo. Never donating to groups working from first principles. Never rocking the boat by criticizing established norms. Just joining all of the other yes men to spread that gospel of "I've got mine" to the highest financial and political levels.
So much of this feels like having to send developers to the end of the earth to cater to the runtime that I question if it's even programming anymore. It would be like having people write the low-level RTF codewords in MS word rather than just typing documents via WYSIWYG. We seem to have all lost our collective minds ..the emperor has no clothes.
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.
As far as I'm aware, transitive dependencies are counted in this number. So when you npm install next.js, the download count for everything in its dependency tree gets incremented.
Beyond that, I think there is good reason to believe that the number is inflated due to automated downloads from things like CI pipelines, where hundreds or thousands of downloads might only represent a single instance in the wild.
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.
Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.
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.
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.
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
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.
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.
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
There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.
to be fair to bootcamp developers, i don't think they ever did "believe that there's virtue" in the setup, they were just told this is what you use and how you use it.
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.
This reminds me of the recent SvelteKit Remote Functions GH discussion:
> Even in systems that prevent server functions from being declared in client code (such as "use server" in React Server Components), experienced developers can be caught out. We prefer a design that emphasises the public nature of remote functions rather than the fact that they run on the server, and avoids any confusion around lexical scope. [0]
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.
The term is always ambiguous. But react is generally understood as a client library and client-side vulnerabilities are hardly a new thing. XSS exists as a whole subfield of study precisely because of the difficulty of keeping site code from getting fooled by malicious input.
Basically you're technically correct with your quip, but engaging in some pretty awful security analysis. IMHO most people reading this headline are not going to understand that they need to audit their server dependencies.
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".
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.
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.)
”use server” is not required for this vulnerability to be exploitable.
They were warned. I don't see how this can be characterized as anything but sloppy.
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.
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.
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__.
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.
Server Components is not really related to SSR.
I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a <script> (server calling client). You can still have an API layer of course, but this gives you a syntactical way to express that there's a piece of backend that prepares data for this piece of frontend.
This resolves tensions between evolving both sides: the each piece of backend always prepares the exact data the corresponding piece of frontend needs because they're literally bound by a function call (or rather JSX). This also lets you load data as granularly as you want without blocking (very nice when you have a low-latency data layer).
Of course you can still have a traditional REST API if you want. But you can also have UI-specific server computation in the middle. There's inherent tension between the data needed to display the UI (a view model) and the way the data is stored (database model); RSC gives you a place to put UI-specific logic that should execute on the backend but keeps composability benefits of components.
Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh.
I understand the logic, but there are several issues I can think of.
1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.
2 - as react was always celebrated as an unopinionated framework, RSC creates a deep coupling between 2 layers which were classically very far apart.
Here are a list of things that would rather have react provide:
- advanced form functionality that binds to model, and supports validation
- i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed
- signals, for proper reactive state
- better templating ability for control flows
- native animation library
All of these things are important so I wouldn’t have to learn each new project’s permutation of the libraries de jour.
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
IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated.
And what they DO add? Only things that improve dev exp
> They had minimal API changes in the last 10 years
The 1 to 2 transition was one hell of a burn though; people are probably still smarting...
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 that stuff, which feels like a code smell).
I've also heard heard good things about Astro, which can wrap components written in other frameworks (like React) so that a total rewrite can be avoided:
https://docs.astro.build/en/guides/imports/
I'm way outside my wheelhouse on this as a backend developer, so if anyone knows the actual names of the frameworks I'm trying to remember (hah), please let us know.
IMHO React creates far more problems than it solves:
I'll just stop there. The more I learn about React, the less I like it. That's one of the primary ways that I know that there's no there there when learning new tools. I also had the same experience with the magic convention over configuration in Ruby.What's really going on here, and what I would like to work on if I ever win the internet lottery (unlikely now with the arrival of AI since app sales will soon plummet along with website traffic) is a distributed logic flow. In other words, a framework where developers write a single thread of execution that doesn't care if it's running on backend or frontend, that handles all state synchronization, preferably favoring a deterministic fork/join runtime like Go over async behavior with promise chains. It would work a bit like a conflict-free replicated data type (CRDT) or software transactional memory (STM) but with full atomicity/consistency/isolation/durability (ACID) compliance. So we could finally get back to writing what looks like backend code in Node.js, PHP/Laravel, whatever, but have it run in the browser too so that users can lose their internet connection and merge conflicts "just work" when they go back online.
Somewhat ironically, I thought that was how Node.js worked before I learned it, where maybe we could wrap portions of the code to have @backend {} or @frontend {} annotations that told it where to run. I never dreamed that it would go through so much handwaving to even allow module imports in the browser!
But instead, it seems that framework maintainers that reached any level of success just pulled up the ladder behind them, doing little or nothing to advance the status quo. Never donating to groups working from first principles. Never rocking the boat by criticizing established norms. Just joining all of the other yes men to spread that gospel of "I've got mine" to the highest financial and political levels.
So much of this feels like having to send developers to the end of the earth to cater to the runtime that I question if it's even programming anymore. It would be like having people write the low-level RTF codewords in MS word rather than just typing documents via WYSIWYG. We seem to have all lost our collective minds ..the emperor has no clothes.
> 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)
Maybe if they compiled away their runtime like svelte and somewhat like angular, then running SSR would be faster.
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...
> 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.
Does AWS WAF have a mitigation in place?
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
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
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.
As far as I'm aware, transitive dependencies are counted in this number. So when you npm install next.js, the download count for everything in its dependency tree gets incremented.
Beyond that, I think there is good reason to believe that the number is inflated due to automated downloads from things like CI pipelines, where hundreds or thousands of downloads might only represent a single instance in the wild.
why is it not normal for CI pipelines to cache these things? its a huge waste of compute and network.
It's not a transitive dependency, it's just literally bundled into nextjs, I'm guessing to avoid issues with fragile builds.
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.
React is widely used, react server components not so much.
Next.js is still pretty damn widely used.
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".
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.
>now cz of the complexity I refuse to work with react.
What do you like to work with now?
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.
Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.
They don't address the exact same markets.
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
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.
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.
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
easier/more reactivity, doesnt require your api responses to be text parsable to html
Link should go to: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
Anyone know how Tanstack Start isn't affected?
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.
They haven't implemented RSC yet.
Do you really need React Server Conponents or even Server Side Rendering?
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.
Of course you do, in certain cases making less round-trips to the server is just straight more efficient
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
There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.
to be fair to bootcamp developers, i don't think they ever did "believe that there's virtue" in the setup, they were just told this is what you use and how you use it.
Not even remotely similar.
Care to elaborate on what it is like, then?
Actually he's more or less correct.
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.
It's almost like trying to magically wire up your frontend to the backend through magical functions is a bad idea.
This reminds me of the recent SvelteKit Remote Functions GH discussion:
> Even in systems that prevent server functions from being declared in client code (such as "use server" in React Server Components), experienced developers can be caught out. We prefer a design that emphasises the public nature of remote functions rather than the fact that they run on the server, and avoids any confusion around lexical scope. [0]
[0] https://github.com/sveltejs/kit/discussions/13897
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.
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
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.
static builds save the day.
dupe: https://news.ycombinator.com/item?id=46136067
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.
I suspect client developers are also affected at least to the extent that they need to explain this RCE to CVE driven management.
Bravo.
Where else would it be? What would an RCE of the client even mean?
The term is always ambiguous. But react is generally understood as a client library and client-side vulnerabilities are hardly a new thing. XSS exists as a whole subfield of study precisely because of the difficulty of keeping site code from getting fooled by malicious input.
Basically you're technically correct with your quip, but engaging in some pretty awful security analysis. IMHO most people reading this headline are not going to understand that they need to audit their server dependencies.
it would be an RCE on your own machine :D
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
No. You cannot find all vulnerable code by grepping for ”use server”, for instance.
So that’s your “it’s not related to use server” argument?
That seems like it could be a quote from their hardening guide.