Denial of service and source code exposure in React Server Components
react.dev77 points by sangeeth96 an hour ago
77 points by sangeeth96 an hour ago
It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities."
Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server.
It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we've recently seen, is a risky spot in terms of potential security vulnerabilities.
I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."
Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed.
Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.
That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?
It also decoupled fe and backend. You could use the same apis for say mobile, desktop and web. Teams didnt have to cross streams allowing for deeper expertise on each side.
Now they are shoving server rendering into react native…
So we have a new React CVE and tomorrow is Friday, so please be prepared for a new outage brought to you by the super-engineers at Cloudflare.
Next team just published this: https://nextjs.org/blog/security-update-2025-12-11
Seems to affect 14.x, 15.x and 16.x.
Im confused, did the update from last week for the RCE bug also include fixes for these new CVEs or will I need to update again? npm audit says theres no issues
is it not obvious?
> These issues are present in the patches published last week.
> The patches published last week are vulnerable.
> If you already updated for the Critical Security Vulnerability, you will need to update again.
Related:
React2Shell and related RSC vulnerabilities threat brief - Cloudflare
https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-... (https://news.ycombinator.com/item?id=46237515)
dammit
After Log4Shell, additional CVEs were reported as well.
It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.