React2Shell: What to Patch Now and Why It Broke

React2Shell—tracked as CVE‑2025‑55182—blew a hole through React Server Components on December 3, 2025. It’s a pre‑auth remote code execution bug scored 10.0. Next.js assigned a downstream advisory (CVE‑2025‑66478) for the App Router. Within roughly a day, public proof‑of‑concepts emerged, and hosting providers rolled out emergency filters. If you ship React 19 or Next.js 15–16, assume exposure until proven otherwise and patch before attackers or scanners find you. This is the practical, operator’s guide to fix React2Shell—and verify the fix sticks.

What is React2Shell (CVE‑2025‑55182), in plain English?

React Server Components (RSC) stream component trees and server actions over a protocol informally called Flight. The vulnerable code trusted identifiers in those Flight payloads. An attacker could craft an HTTP request that tricked the server into resolving and executing code paths it shouldn’t—resulting in remote code execution before any authentication happened. You didn’t need to enable exotic features. If your framework or bundler wired up RSC, you were likely in the blast radius.

Key dates for your incident log: vulnerability reported November 29, 2025; patches and disclosure on December 3, 2025; active exploit tooling appeared within the next 24–36 hours. On December 5, Cloudflare had a brief global availability incident while tuning body‑parsing and WAF protections in response—more on what that teaches us below.

Who’s affected—and which versions are safe?

React packages with the bug: react‑server‑dom‑webpack, react‑server‑dom‑parcel, and react‑server‑dom‑turbopack in 19.0, 19.1.0, 19.1.1, and 19.2.0.

Patched React package lines: 19.0.1, 19.1.2, and 19.2.1.

Downstream impact: Next.js App Router on 15.x and 16.x (plus certain 14.3.0 canaries). Next.js shipped fixed releases: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7. If you’re on a 14.3.0‑canary.77+ build, downgrade to the latest stable 14.x or move to a patched 15.x/16.x.

Other affected ecosystems called out by vendor guidance include React Router’s RSC preview, Waku, Parcel’s RSC plugin, and Vite’s RSC plugin. Hosting platforms rolled out mitigations, but those are safety nets, not cures—you still need to update.

A 90‑minute triage, then a 24‑hour patch plan

Here’s the fastest path I’ve used with teams this week. Treat times as max budgets; many shops will finish sooner.

0–30 minutes: declare, scope, freeze

• Open an incident with a single owner and comms channel. Document dates: December 3 disclosure, your detection time, and patch start/finish.
• Freeze deploys unrelated to this fix. If you must ship mitigations, isolate them behind feature flags.
• Inventory which apps use RSC: Next.js App Router, or any bundler/plugin enabling RSC. Don’t forget internal tools and marketing sites.

30–60 minutes: identify vulnerable versions

• In each repo, list versions: npm ls react-server-dom-webpack (or parcel/turbopack). Note 19.0, 19.1.0, 19.1.1, or 19.2.0.
• For Next.js, capture exact framework version and whether App Router is in use. Pages Router‑only apps are not in scope.
• Flag any canary builds from late 14.x that adopted RSC—these need special handling.

60–90 minutes: put guardrails in place

• Enable or tighten WAF rules that specifically inspect multipart/form‑data and RSC‑shaped payloads; log blocks separately. If you don’t control edge WAF, stand up a temporary app‑level filter that rejects oversized or malformed action payloads.
• Rotate any CI/CD tokens exposed to build logs where RSC endpoints may be probed; some PoCs dump environment variables after RCE.

Within 4 hours: patch application dependencies

• React-only stacks: upgrade react‑server‑dom‑webpack (or parcel/turbopack) to 19.0.1, 19.1.2, or 19.2.1 depending on your line, along with react and react‑dom to the corresponding safe versions.
• Next.js: move to a fixed release in your line—15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. If you’re on 14.3.0 canaries with RSC, either downgrade to the latest stable 14.x or jump to a patched 15/16. Vercel published a helper script (npx fix-react2shell-next) if you prefer automation; still review the diff.
• React Router RSC preview, Vite RSC, Parcel RSC, Waku, Redwood SDK: update all RSC‑related packages to their latest advisories and re‑lock your manifest.

By end of day: rebuild, redeploy, and verify

• Rebuild from clean cache. Redeploy progressively (canary + 5% + 25% + 100%) with rollback plans.
• Run smoke tests that cover Server Actions and form submissions. Confirm patched package versions in the live image/container.
• Review WAF logs: declining block counts after redeploy is a good signal. Keep mitigations on for at least a week.

Why Cloudflare stumbled trying to protect you—and what that means for your WAF

On December 5, 2025, Cloudflare briefly impacted about a quarter of its HTTP traffic for ~25 minutes while increasing request‑body buffers and toggling internal test rules tied to new protections for this RSC issue. The takeaway isn’t to avoid mitigations; it’s that edge defenses are production software too. They need gradual rollouts, kill‑switches that fail gracefully, and parity testing across versions.

Your lesson: if you add or tweak WAF rules for React2Shell, stage them, validate memory limits and body sizes end to end (Next.js defaults to ~1 MB), and test “fail‑open vs. fail‑closed” behavior. The goal is to block malicious payloads without turning an exploit attempt into a self‑inflicted outage.

How to verify you’ve actually fixed React2Shell

Don’t stop at “build passed.” Use this checklist to prove remediation:

• Lockfile evidence: your lockfile includes react-server-dom-* at 19.0.1, 19.1.2, or 19.2.1, and/or Next.js at a patched version listed above.
• Runtime evidence: container or function layer manifests show patched versions at runtime, not just in dev.
• Functional probes: legit Server Actions still work (upload forms, mutations) with no 500s; malformed payloads are rejected and logged.
• Edge telemetry: WAF detections decline after the patch, not because traffic vanished, but because exploitation attempts fail early.
• Threat hunting: review web server logs around December 3–7 for suspicious multipart/form‑data to RSC endpoints, odd boundary markers, or requests lacking CSRF/headers that still hit action routes.

“People also ask” — quick answers teams keep pinging me about

Are Pages Router apps affected?

No. The advisory scope is RSC and the App Router. A legacy Pages Router‑only app that never adopted RSC isn’t targeted by this CVE set.

We don’t use Server Actions. Are we safe?

Not automatically. The bug lives in how RSC decodes payloads to reach server code paths. If your framework wires those endpoints by default, you can still be exposed even without explicitly defining actions.

Can WAF rules replace patching?

No. Treat WAF rules as seatbelts, not airbags. They help, and some hosts added day‑zero protections, but only upgrading removes the vulnerable code path.

Does the Edge Runtime avoid this?

Edge runtimes that don’t run the vulnerable RSC path aren’t in scope per the downstream advisory. Validate your runtime per service; don’t assume.

What about older React versions?

The advisories and fixed versions targeted React 19 lines and the frameworks bundling RSC. If you’re on React 18 with no RSC integrations, you’re outside this specific bug—still, audit transitive deps before you exhale.

The developer’s field kit: commands and checks you can run today

Copy/paste responsibly and adapt to your line. Run these in a branch with CI:

• List vulnerable RSC packages: npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack
• Upgrade React RSC line: npm i -E [email protected] [email protected] [email protected] (or use 19.0.1/19.1.2 to align with your minor)
• Upgrade Next.js to a fixed version in your line: npm i -E [email protected] (or the matching 15.x fixes listed above)
• Regenerate lockfile cleanly: delete lock + node_modules, reinstall, rebuild
• Verify at runtime: bake an image, then npm ls | grep react-server-dom inside the container

Risk and impact for executives: pre‑auth RCE with live exploits

Two realities should drive your prioritization. First, this is pre‑authentication RCE reachable over the public internet in default configurations. Second, exploit code appeared quickly after the December 3 disclosure, and scanning surged immediately after. Treat this as a production incident with potential data exfiltration, credential leakage, and lateral movement. If you saw unusual child_process invocations, opaque temporary files in /tmp, or spikes in multipart/form‑data to action endpoints, plan for a compromise assessment, not just a patch.

If you’re running on a managed platform, platform protections buy you time—but not much. Put a 24‑hour SLA on shipping the safe versions, and a 7‑day SLA on completing log reviews and closing follow‑on hardening tasks.

Beyond the patch: hardening moves worth keeping

• Turn on request body size caps aligned with your framework defaults (Next.js at ~1 MB by default) and fail in a controlled, observable way.
• Enforce CSRF tokens on mutation endpoints—even where RSC abstracts it—so opportunistic probes don’t get a free ride.
• Run SSR/RSC under a strictly scoped identity. If RCE happens, the blast radius should be tiny (no root, no broad network egress, no cloud metadata access).
• Alert on unexpected child_process usage or dynamic require/import of core Node modules from web workers.
• Bake SCA (software composition analysis) and advisories into CI so new CVEs generate blocking checks, not Slack pings nobody triages.

What to do next this week

• Today: patch to safe versions, keep WAF mitigations on, and verify in production. Open a ticket for a light compromise review if traffic logs look odd between December 3–7.
• Tomorrow: add automated SCA gates in CI, and create an RSC‑specific security test that feeds malformed payloads to your canary environment.
• This week: document how you’ll roll out edge rule changes safely (progressive rollouts, config versioning, a tested kill‑switch). The Cloudflare lesson is for everyone.

Working with us

If you want a structured response, our team has shipped multiple playbooks around high‑severity supply‑chain and framework bugs. Start with our earlier guidance in a 72‑hour plan for RSC incidents, then adapt it to this CVE pair and your runtime. If you need help with dependency upgrades, runtime verification, or WAF tuning, see our security incident playbooks and modernization work, browse application hardening services, or just talk to us. For broader engineering leadership topics during crises, our Copilot metrics piece shows how to close the loop between developer velocity and risk controls.

Primary sources to track (and what to log for audit)

You should record the exact patch versions applied, the date/time of deployment, and references to official advisories in your internal incident ticket. If regulators ask later, you’ll have a clean chain of evidence. Also, capture any mitigations enabled (WAF rule IDs, body size limits, rollout percentages) and their activation/deactivation timestamps.

One last reality check

React2Shell hit a nerve because it turned “modern defaults” into the attack path: server actions, streaming UI, and smart tooling. Those defaults are still worth it—just assume new surface means new rules. Patch fast, verify in runtime, and treat edge defenses as code with their own blast radius. If your team needs an outside partner to move faster or validate the fix, we’re here when you’re ready.