Ragebait and engagement farming has driven me to levels of frustration unimaginable. What originally drew me away from Twitter years ago is nothing compared to what we see on X today. That being said, React Server Components being the root of these emotions was not on my 2025 bingo card.
If you’ve managed to stay out the loop — I envy you. CVE-2025-66478 and more caused many sleepless nights across the industry, and for good reason. If you want a deep dive into how it works, Guillermo’s article is excellent. Here, I want to explore what’s next.
It’s natural for events like this to cause panic, and RSC has always been polarizing. So seeing the “move to TanStack” conversation explode isn’t shocking. If migrating was ever a thought, this month probably pushed it into serious consideration. But what does that actually mean? Is this the end of RSC? Do we all need to start a TanStack crash course?
These vulnerabilities were undeniably severe, but they stem from React’s design (not your framework or your provider). Abandoning RSC entirely may be an overcorrection. Switching frameworks is not a security strategy. At best, it trades one set of tradeoffs for another.
The truth is frameworks that enforce strict separation avoid an entire category of issues by design. That simplicity is appealing, and there is nothing wrong with wanting a model you can fully reason about. But you also lose the productivity benefits RSC brings (shared components, colocated logic, streaming, and a unified mental model).
Shipping at the edge of what’s possible always carries risk. For some teams, that’s exciting; for others, a terrible idea. In either case, incidents are inevitable. What matters is how quickly your platform responds, shields customers, and hardens the ecosystem.
Beyond the vulnerabilities themselves, the response infrastructure is just as important as the patch. Firewalls and edge protections can block exploit attempts before they reach production, protecting users in all types of environments. While RSC exploits are specific, strong platform-level security reduces risk across the board and helps teams maintain confidence to innovate safely.
Looking forward, RSC will continue to evolve, and so will the way we think about the web. The real question is how much architectural complexity we’re comfortable adopting long term. Do we want frameworks that blur the client/server boundary for convenience, or do we prefer explicit APIs and strict separation? There’s no universal answer, but this moment forces us to be more intentional about the tradeoffs we choose.
Liked this article? Share it with a friend on Bluesky or X. Have a question, feedback or simply wish to contact me privately? Shoot me a DM and I'll do my best to get back to you.