Denial of service and source code exposure in React Server Components

Posted by sangeeth96 12/11/2025

Denial of service and source code exposure in React Server Components(react.dev)

346 points | 225 commentspage 2

bflesch 12/11/2025|

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.

venturecruelty 12/11/2025|

Look on the bright side: maybe GitHub will be down first, so nobody can upload any vulnerable code right before the weekend.

kpozin 12/12/2025||

A framework designed to blur the line between code running on the client and code running on the server — forgot the distinction between code running on the client and code running on the server. I don't know what they expected.

(The same confusion comes up regularly whenever you touch Next.js apps.)

bitbasher 12/11/2025||

I remember when my greatest fear was sql injection. It’s great to see we have become more secure with our technology.

dzonga 12/12/2025||

react server components is something that should've never existed anyway.

are people shipping faster due to them ? or it's all complexity, security vulnerabilities like this. you're not facebook. render html the classic way if you need server rendered html. if you really do need an SPA - which is 5% of the apps out there - then yeah use client side react, vue, svelte etc - none of those RPC server actions etc

CodingJeebus 12/12/2025|

Agreed. Unfortunately, there's an entire content/bootcamp ecosystem pushing this stuff that came of age largely during the tech boom, as well as a bunch of early and mid-career devs and companies that are deeply tied to it. With major VC funding backing projects like Bun, Vercel, etc., I don't think this deeply flawed approach to development is going anywhere because the utopian JS fantasy of "it just works and runs everywhere flawlessly" is the ultimate myth of building for the web.

yread 12/11/2025||

Were there not enough eyes on React Server Components before the patches from last week?

manfre 12/12/2025||

I've noticed a pattern in the security reports for a project I'm involved in. After a CVE is released, for the next month or so there will likely be additional reports targeting the same (or similar) areas of the framework. There is definitely a competitive spirit amongst security researchers as they try to get more CVEs credited to them (and potentially bounties).

Inviz 12/11/2025||

have you seen the code of next.js? its completely impenetrable, and the packages have legacy versions of the same files coexisting, it's like huge hairball

nathants 12/12/2025||

Just exchange json.

Backend in python/ruby/go/rust.

Frontend in javascript/typescript.

Scripts in bash/zsh/nushell.

One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.

KronisLV 12/12/2025|

I really like having a good old RESTful API (well maybe kinda faking the name because don't need HATEOAS usually)!

Except I find most front end stacks to lead to either endless configuration (e.g. Vue with Pinia, router, translation, Tailwind, maybe PrimeVue and a bunch of logic for handling sessions and redirects and toast messages and whatnot) and I feel the pull to just go and use Django or Laravel or Ruby on Rails mostly with server side templates - I much prefer that simplicity, even if it feels a bit icky to couple your front end and back end like that.

ManuelKiessling 12/12/2025||

I really wonder why the swarm intelligence of software developers still hasn’t decided on a single best clearly defined architecture for serving web applications, decades after the building blocks have been in place.

Let the server render everything. Let JS render everything, server is only providing the initial div and serves only JSON from then on. Actually let JS render partial HTML rendered on the server! Websockets anyone?

Imagine SQL server architecture or iOS development had this kind of ADHS syndrome.

rvz 12/11/2025||

React patches one vulnerability and two more are revealed, just like a Hydra.

At this point you might as well deprecate RSC as it is clearly a contraption for someone trying to justify a promotion at Meta.

Maybe they are going to silently remove “Built RSC at Meta!” in their LinkedIn bios after this. So what other vulnerabilities are going to be revealed in React after this one?

marksomnian 12/12/2025|

Meta don’t use RSC: https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs2...

> We are not using RSC at Meta yet, bc of limits of our packaging infra (it’s great at different things) and because Relay+GraphQL gives us many of the same benefits as RSCs. But we are fans and users of server driven UI and incrementally working toward RSC.

(as of April 2025)

LittleOtter 12/12/2025||

Our team is working to fix our Next.js project.It's so painful.

Now I'm doubting RSC is a good engineering technology or a good practice.The real world is tradeoffs: RSC really help us improve our develop speed as we have good teamates that has good understanding of fullstack.

Do hope such things won't happen again.

IceDane 12/12/2025|

How is it painful? You need to bump a minor version? It took me less than 5 minutes 90% of which was waiting for CI. There's even a tool you can run to do it for you.

metta2uall 12/12/2025|

For the vast majority of projects it seems like the disadvantages of these highly complex RPC systems far exceed the benefits... Not just in terms of security but also the reduced observability compared to simple JSON..

More comments...