CVSS 7.5. That’s the score on not one, but three Denial of Service vulnerabilities freshly disclosed in React Server Components. High severity. And they’re telling you to patch yesterday.
Look, I’ve been kicking tires in Silicon Valley for 20 years — seen hype cycles come and go, from Angular’s glory days to Vue’s quiet competence — and this React Server Components saga? It’s starting to smell like another rushed server-side experiment where the buzzwords flew faster than the security audits.
React Server Components vulnerabilities — yeah, we’re diving right into that phrase because if you’re building with Next.js or any of those frameworks leaning on RSC, this is your wake-up call. The React Team dropped this bomb on January 26, 2026, right after patching a critical RCE bug called React2Shell. Security researchers, poking at those fixes, unearthed more: DoS via crafted HTTP requests that crash servers, trigger OOM, or chew CPU like it’s free candy. Plus a medium-severity code leak that spits out your server functions’ source — secrets and all.
Security researchers have found and disclosed two additional vulnerabilities in React Server Components while attempting to exploit the patches in last week’s critical vulnerability.
That’s straight from the React Team’s mouth. No sugarcoating. Affected packages? A laundry list: react-server-dom-webpack from 19.0.0 up to 19.2.3. Backports hit 19.0.4, 19.1.5, 19.2.4. If your package.json has those, upgrade. Now.
Why React Server Components Keep Springing Leaks
Here’s the thing — RSC promised to blur client-server lines, streaming components from the server without full page reloads. Sounds slick, right? (Vercel loves it, naturally — they’re printing money on Next.js hosting.) But these vulns? They’re in the deserialization of Server Functions. Malicious HTTP requests to any endpoint — even if you don’t use ‘em explicitly — loop infinitely, hanging your process. Or expose stringified args that leak DB keys, like in their example:
'use server';
export async function serverFunction(name) {
const conn = db.createConnection('SECRET KEY');
// ...
}
Boom. Attacker sends a request, gets your source code back in mangled JSON. CVSS 5.3, but don’t sleep on it — that’s source code exposure, folks.
And the DoS trio (CVE-2025-55184, CVE-2025-67779, CVE-2026-23864)? Crafted requests to Server Function endpoints. Server crashes. Excessive CPU. OOM exceptions. Even apps without explicit Server Functions might catch it if RSC is supported. Brutal.
Frameworks in the crossfire: Next.js, react-router, Waku, Parcel RSC, Vite RSC plugin, RWSdk. Hosting providers threw up temp mitigations — but the Team says don’t bet your farm on ‘em.
React Native folks? Mostly safe unless monorepo’d with the dom packages. Pin react/react-dom, update the server-dom ones selectively. No version mismatches.
Is Your App Actually Vulnerable to These React Bugs?
Short answer: If no server-side React, you’re golden. No RSC-supporting framework or bundler? Same. But let’s be real — half the dev world runs Next.js. Vercel’s ecosystem is sticky. And here’s my unique hot take, one you won’t find in the advisory: This reeks of the same hubris that birthed Node.js security headaches a decade ago. Remember Heartbleed? Or the npm left-pad meltdown? RSC feels like React chasing serverless dreams without the hardening. Bold prediction: We’ll see enterprise pullback on RSC adoption until Meta/Netlify/Vercel prove it’s not a DoS magnet. Who’s really winning? Cloud providers billing for crashed instances.
Timeline’s a mess too — leaks reported December 3rd to bounties, fixes rolling January 26th. Good on the researchers (shoutout Andrew MacPherson, RyotaK), but React Team’s “details after rollout”? Classic PR spin to buy time.
Upgrading? Follow the prior post’s steps. But ask yourself: Is RSC worth the headache? Client-side React was battle-tested. This? Still wet behind the ears.
Patches block infinite loops, prevent source stringification, nix the crash paths. Effective against RCE still. But vigilance, people.
One punchy para: Don’t slack.
Now, a ramble: I’ve covered a dozen framework flameouts — SvelteKit’s edge cases, Remix’s rewrite woes — and RSC’s pattern is clear. Meta pushes open-source innovation (noble), but the velocity invites bugs. Security researchers are the real MVPs here, turning bounties into patches while VCs cheer deployment speed over audits. Cynical? Sure. But after 20 years, I’ve seen who foots the bill: you, the dev scrubbing logs at 3 AM.
Who Profits from React Server Components Hype?
Vercel. Obviously. Next.js is their cash cow, RSC the secret sauce. But these CVEs? They erode trust. Imagine: Attacker DoSes your prod endpoint, users bail, AWS bills spike. Meanwhile, React Team coordinates with hosts for mitigations — noble, but temporary. Long-term? Harden the spec, slow the hype train.
Historical parallel: jQuery’s plugin ecosystem in 2010. Infinite flexibility, infinite exploits. RSC’s Server Functions? Same vibe — powerful, perilous.
Final nudge: Check your deps. npm audit might miss RSC specifics. Manually scan for those versions.
🧬 Related Insights
- Read more: MLOps to LLMOps: Why AWS Teams Are Still Fumbling Production AI
- Read more: GitHub’s Frantic Fix for Bloated Pull Requests Finally Lands
Frequently Asked Questions
What are the React Server Components vulnerabilities?
Three DoS (CVSS 7.5) via crafted requests causing crashes/loops, one code exposure (5.3) leaking server function source. Hits react-server-dom-* packages 19.0.0-19.2.3.
Should I upgrade React for these Server Components bugs?
Yes, immediately to 19.0.4+, 19.1.5+, or 19.2.4+. Frameworks like Next.js affected too.
Does React Server Components affect my app?
Only if using server-side React or RSC frameworks/bundlers. Pure client-side or React Native (non-monorepo)? Safe.
