React RSC: Update Now to Patch DoS and Source Leak (CVE-2025-55184, -55183)

React disclosed two new RSC vulnerabilities: a DoS that can hang servers and a source code exposure that can leak Server Function code when arguments are stringified. They do not enable RCE, but last week’s patches are insufficient and must be updated. Upgrade react-server-dom-{webpack,parcel,turbopack} to 19.0.2, 19.1.3, or 19.2.2 immediately; hosting mitigations are temporary.

Key Points

• Two new RSC CVEs: DoS (CVE-2025-55184, High) and Source Code Exposure (CVE-2025-55183, Medium); no new RCE.
• Immediate upgrade required: react-server-dom-{webpack,parcel,turbopack} to 19.0.2, 19.1.3, or 19.2.2.
• DoS via crafted request can cause an infinite loop on deserialization, potentially affecting any RSC-enabled app.
• Source code exposure occurs when a Server Function stringifies arguments, potentially leaking hardcoded secrets (not runtime env secrets).
• Frameworks/bundlers like Next.js, React Router, Waku, Parcel RSC, Vite RSC plugin, and rwsdk are affected; hosting mitigations exist but are not sufficient.

Sentiment

The overall sentiment is strongly negative toward React Server Components, with the vulnerabilities serving as a catalyst for pent-up frustration. The dominant mood is vindication among developers who have long been skeptical of RSC's approach. Most commenters view the blurred client/server boundary as a mistake, and many are actively considering or migrating to alternatives. A small contingent defends RSC, and React team members engaged constructively, but the prevailing view is that RSC's complexity-to-benefit ratio is deeply unfavorable and these CVEs were predictable consequences.

In Agreement

• The vulnerabilities validate long-standing concerns about RSC's opaque serialization RPC mechanism creating a dangerous security surface that developers cannot easily reason about.
• Follow-up CVEs after an initial disclosure are normal and expected, as security researchers scrutinize adjacent code paths after a vulnerability is revealed.
• The (de)serialization protocol's reliance on JavaScript's dynamic features like writable prototypes and function toString represents a legitimate and concerning attack surface.
• Affected users need to update again even if they patched last week's RCE, as the new CVEs are present in those patches.
• The vulnerabilities affect a broad range of frameworks beyond just Next.js, including react-router, waku, and others that use react-server-dom packages.

Opposed

• The blog post's prominent note normalizing follow-up CVEs reads as defensive spin and perception management rather than transparent disclosure.
• RSC is a fundamentally flawed concept that should never have existed — it solves problems that were self-created by blurring the client/server boundary.
• Meta does not even use RSC in production, undermining claims that it was built to solve real engineering problems rather than serve Vercel's commercial interests.
• Other major frameworks like Vue and SvelteKit explicitly rejected RSC-style approaches, suggesting the React team pursued this despite foreseeable risks.
• The React team should have conducted proactive security audits of the serialization protocol before shipping RSC to production rather than waiting for external researchers to find these flaws.
• Vercel's financial incentives to push server-side complexity that drives hosting revenue are distorting React's technical direction at the expense of developer experience and security.
• The DoS should not be rated higher severity than source code exposure — code leaks enable future breaches and represent a more fundamental security failure.