React2Shell is now more than a scary disclosure—it’s being exploited. React’s own advisory on December 3 confirmed a CVSS 10.0 RCE in React Server Components, and within 24 hours proof‑of‑concepts surfaced publicly. Since then, providers have reported active probing and attacks targeting unpatched apps. If you rushed a fix, today’s job is verification, incident scoping, and hardening—before lingering access turns into Monday’s outage. (react.dev)
Here’s the thing: React2Shell isn’t just a React problem. It cascaded into framework ecosystems. Next.js tracked the downstream impact as CVE‑2025‑66478 and shipped patched releases; Vercel has updated guidance multiple times as new exploit patterns emerged and additional RSC issues were cataloged. Treat this as an extended security event, not a one‑and‑done patch. (nextjs.org)
What actually changed this week (and why it matters)
Timeline, with the highlights that matter for risk decisions:
• December 3, 2025: The React team discloses an unauthenticated RCE in RSC due to unsafe deserialization in the "Flight" protocol, affecting react-server-dom-* packages in React 19.0, 19.1.0–19.1.1, and 19.2.0. Patches: 19.0.1, 19.1.2, 19.2.1. (react.dev)
• December 4: Public exploit code appears; Vercel reports spikes in WAF detections and urges immediate upgrades. (vercel.com)
• December 5–11: Active exploitation is reported in the wild by multiple outlets and vendors; Vercel recommends secret rotation for any app that was online and unpatched as of December 4, 1:00 PM PT. (vercel.com)
• December 11: Vercel adds a bulletin noting two additional RSC‑related issues (DoS and source disclosure) discovered via community research—proof that scrutiny of the protocol is ongoing. Don’t assume yesterday’s mitigation covers tomorrow’s variants. (vercel.com)
Am I actually patched for React2Shell?
React side: You’re covered if your deployed app uses react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack at 19.0.1, 19.1.2, or 19.2.1. Anything at 19.0, 19.1.0–19.1.1, or 19.2.0 is vulnerable. Verify the versions in your deployed artifact, not just package.json. (react.dev)
Next.js side: If you’re on the App Router, you need one of the patched trains. Guidance from Vercel and ecosystem advisories points to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7. Canary 14.3 builds after 14.3.0‑canary.76 were impacted; move to a stable or a fixed canary. (community.vercel.com)
Caution: Even if you never defined a “Server Function” endpoint, you may still be vulnerable if your app supports RSC—the deserialization flaw lives in the protocol, not your business code. (react.dev)
React2Shell verification checklist (15‑minute triage, 2‑hour follow‑through)
This is the pragmatic order I use with client teams:
1) Confirm runtime versions in production
• Dump the resolved dependency tree on the server/container that actually serves traffic. For Node/Next: node -p "require('module').builtinModules.length" to confirm you’re in the right shell, then npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next react. Compare to the patched sets above. (react.dev)
2) Validate the fix path by rebuilding
• Reinstall from lockfile to force resolution, rm -rf node_modules, npm ci, rebuild, and redeploy. If using Vercel, kick a fresh production build; if self‑hosting, rebuild the Docker image. Check artifact digests against the new release. Vercel also offers an automated upgrade flow for many projects post‑disclosure. (vercel.com)
3) Hunt for exploit attempts and success indicators
• Log patterns: look for unexpected POSTs to RSC routes or API routes that resolve RSC payloads, anomalous content types (e.g., text/x-component), or unusually large serialized payloads near December 4–today. Vercel reported observable probing correlated with PoC publication. (vercel.com)
• Process anomalies: if Node started new child processes without deployment, or if unfamiliar .node/.so files appeared, escalate.
• Outbound traffic bursts to unknown IPs or unexpected chain to pastebins, Git hosting, or smart‑contract lookups can indicate persistence frameworks; recent reporting mentions adversaries experimenting with exotic C2 approaches. (techradar.com)
4) Assume exposure if you were unpatched on Dec 4
• Vercel’s bulletin: rotate secrets if your app was online and unpatched as of December 4, 1:00 PM PT. That means environment variables, API keys, DB passwords, OAuth client secrets, JWT signing keys, webhook tokens. Apply the same principle off‑Vercel—your risk posture is about exposure time, not hosting brand. (vercel.com)
5) Close the loop with end‑to‑end tests
• After patching, run smoke tests for SSR pages, RSC interactions, and file uploads. Flaky builds after emergency bumps usually trace to mismatched react/react-dom and react-server-dom-* versions. The React advisory lists the exact fixed versions—match them. (react.dev)
People also ask: common React2Shell questions
Does a WAF or CDN rule alone stop React2Shell?
No. WAF rules help, and Vercel deployed rules to block known patterns, but they’re not a guaranteed shield against new variants. The only complete fix is upgrading to patched versions. Use WAF as defense‑in‑depth, not as a substitute for patches. (vercel.com)
We don’t use Next.js—are we safe?
Not necessarily. If your framework or build uses React Server Components with the affected react-server-dom-* packages, you’re in scope. The React team’s advisory covers the vulnerable packages directly. (react.dev)
Is exploitation actually happening?
Yes. Multiple reports in the last week document live exploitation and sophisticated persistence attempts by state‑sponsored threat groups. If you were exposed, treat this like an incident, not a theoretical risk. (techradar.com)
Deep dive: version mapping and the practical edge cases
• React: fixed in 19.0.1, 19.1.2, 19.2.1. If you pinned react and react-dom but left react-server-dom-* semver‑loose, your build could resolve to a vulnerable RSC package even after bumping react. Audit your lockfile and the produced .next or server bundle to be sure. (react.dev)
• Next.js: patched in 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 14.x canaries after 14.3.0‑canary.76, upgrade or downgrade to a safe line. This matters for monorepos that stuck on canary for a specific feature. (community.vercel.com)
• Containers and layers: if your CI pulled cached node_modules or layer tarballs, your hotfix branch might still deploy old artifacts. Bust caches and rebuild from scratch.
• Self‑hosted reverse proxies: some teams terminated requests at Nginx/Traefik without propagating all headers, masking exploit patterns in app logs. Inspect proxy logs too—look for sudden POST spikes to seemingly benign routes.
A pragmatic hunt playbook you can run today
Here’s a lightweight flow that works whether you’re on Vercel, another PaaS, or bare VMs:
1) Evidence sweep (60 minutes)
• Logs: query last 10 days for requests with unusual content types or large bodies to routes that handle RSC. On Vercel, export request logs and WAF events; the Vercel post shows increased validation traffic as PoCs dropped. (vercel.com)
• Filesystem: search for unfamiliar binaries or writable temp dirs suddenly populated under your Node process user.
• Processes: baseline with ps snapshots. Any orphaned Node workers that survived redeploys are red flags.
2) Secret rotation and session invalidation (30–90 minutes)
• Rotate the big four first: database credentials, cloud provider keys, JWT/HMAC secrets, OAuth credentials. If you were vulnerable during the early window, follow the bulletin’s guidance and rotate proactively. (vercel.com)
• Invalidate long‑lived sessions and refresh tokens; force re‑auth for admin roles.
3) Integrity checks (30 minutes)
• Rebuild from clean caches; verify that the lockfile includes patched react-server-dom-* and a fixed Next.js version if applicable. Cross‑check with the Next.js advisory page. (nextjs.org)
4) Prevent recurrence (ongoing)
• Add CI policy to break builds when vulnerable versions of react-server-dom-* or next appear. A number of community scanners and GitHub Actions have popped up to help you detect CVE‑2025‑55182 in PRs. (github.com)
• Keep WAF rules enabled and monitor; treat them as an alerting surface for new variants, not a shield you hide behind. (vercel.com)
Zooming out: why React2Shell hit so hard
Protocol‑level flaws in widely adopted abstractions multiply quickly. RSC is used across frameworks, so a single serialization bug propagated downstream. That’s why you saw a React CVE (CVE‑2025‑55182) plus a Next.js tracking CVE (CVE‑2025‑66478), and new research uncovering adjacent RSC issues. The lesson: adopt platform features with a plan for patch velocity and verification—not just feature velocity. (react.dev)
What to do next (developers)
• Double‑check production versions against the fixed sets above. Then rebuild and redeploy from clean caches.
• Run the hunt playbook and rotate secrets if you were exposed on or before December 4, 1:00 PM PT. (vercel.com)
• Add CI/CD gates for vulnerable package ranges; wire a GitHub Action scanner until your SCA tool catches up. (github.com)
• If you ship Next.js at scale, bookmark our guide on the framework‑specific mitigations and version mapping: Next.js CVE‑2025‑66478: Patch, Verify, Prevent.
What to do next (engineering leaders)
• Treat this as an incident class. Fund secret rotation hours, log retention increases, and time for post‑mortems—even if you think you were safe.
• Add a “protocol risk” line to your architecture reviews. Anything that deserializes opaque inputs over the wire deserves stricter testing and chaos drills.
• If you’re juggling concurrent upgrades (Node, Next.js, infra), schedule them like a release train. We’ve published a calm process for major runtime moves: Node.js 24 LTS: The Zero‑Drama Upgrade Plan.
Related resources and playbooks
If you still need the fast‑patch specifics, use our operational guide: React2Shell: Patch Now—A Pragmatic Playbook. For teams formalizing a one‑week rollout with staged risk gates, see React Server Components Vulnerability: 7‑Day Rollout. If you want hands‑on help, explore our security and web platform services or contact us.
FAQ‑style clarity on edge cases
“We upgraded React but not Next.js. Is that safe?”
Not until your Next.js version is in a patched set. Next.js tracked the issue as CVE‑2025‑66478 and shipped fixes across each minor. Patch both layers. (nextjs.org)
“We don’t expose API routes. Are we immune?”
No. The vulnerable path involves the RSC protocol itself. Apps that support RSC may deserialize attacker‑controlled payloads even without custom endpoints. (react.dev)
“Can we wait for EPSS or risk scores to rise before acting?”
That lag has already been observed; exploitation started while some scoring signals remained modest. Don’t anchor on delayed probabilities—patch and verify. (hackerone.com)
Final word: prove safety, don’t assume it
Patching React2Shell fast was the right first move. But safety comes from evidence: verified versions in production, a clean hunt, rotated secrets if exposed, and pragmatic hardening to catch variants. Close the loop today and you’ll avoid the worst kind of surprise—discovering the attacker did your post‑mortem for you. If you want a second set of eyes or need an accelerated response team, we’re here to help.
