React2Shell—the nickname for CVE-2025-55182—is a CVSS 10 remote code execution bug in React Server Components (RSC). It hit on December 3, 2025, and exploitation started the same day. If you run Next.js with the App Router or any RSC-enabled stack and your app was exposed to the internet, treat this as an incident, not just a routine dependency bump. Patching is mandatory, but the real job is verifying nothing else snuck in while the window was open.
What changed between Dec 3 and Dec 10, 2025?
Here’s the short timeline you should internalize for executive updates and postmortems:
• Dec 3, 2025: The React team disclosed an unauthenticated RCE in React Server Components, affecting react-server-dom-* packages at 19.0, 19.1.0, 19.1.1, and 19.2.0. Patched versions shipped as 19.0.1, 19.1.2, and 19.2.1. (react.dev)
• Dec 3, 2025: Vercel published Next.js guidance. Affected when using the App Router on 15.x, 16.x, and 14.3.0-canary.77+; fixed in 16.0.7 and a set of 15.x point releases (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7). They also released npx fix-react2shell-next and urged secret rotation for apps online and unpatched as of Dec 4 at 1:00 PM PT. (nextjs.org)
• Dec 3–10, 2025: Cloud providers rolled out emergency WAF protections (Cloudflare Managed Rules; Google Cloud Armor preconfigured rules), while stressing these are only stopgaps. (blog.cloudflare.com)
• Dec 4–8, 2025: Threat intel teams observed scanning and exploitation attempts, including China-nexus activity (Earth Lamia, Jackpot Panda). Indicators include telltale RSC headers like next-action and rsc-action-id and payload patterns in request bodies. (aws.amazon.com)
Are you vulnerable?
You’re at risk if any internet-exposed service supports React Server Components on the affected versions—regardless of whether you explicitly used React Server Functions. If you’re on React 19.0, 19.1.0, 19.1.1, or 19.2.0 with react-server-dom-*, you must upgrade to 19.0.1, 19.1.2, or 19.2.1. (react.dev)
For Next.js, the vulnerable surface spans 15.x, 16.x, and recent canaries when using the App Router. Fixed releases are 16.0.7 and the listed 15.x patch lines; Next.js 13.x/14.x stable using the Pages Router and the Edge Runtime are not affected. (nextjs.org)
Public exploit code exists and works even against “hello world” defaults created with create-next-app, which is why default deployments were so exposed. (securitylabs.datadoghq.com)
React2Shell triage: a 4-step framework you can run now
Here’s a battle-tested flow we’ve used with product teams this week. Run it end-to-end; don’t cherry-pick.
1) Patch deterministically
• React/RSC: bump to 19.0.1, 19.1.2, or 19.2.1 across react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Lock with exact versions in package.json and your lockfile. (github.com)
• Next.js: move to the exact patched line for your minor: 16.0.7 or a fixed 15.x (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7). If you’re on a canary to test PPR, use the specified canary fixes. The npx fix-react2shell-next tool can automate safe bumps. (nextjs.org)
• Redeploy everything. Immutable image? Rebuild. Serverless? Ship a new deployment. Monorepo? Ensure all apps using RSC are rebuilt and promoted through your pipeline gates.
2) Verify exposure and hunt for compromise
• Check traffic headers: query logs for next-action and rsc-action-id. Look for request bodies containing $@ or "status":"resolved_model". These are common in exploit attempts AWS observed. (aws.amazon.com)
• Host indicators: sudden spikes of Node.js child processes, recon commands (whoami, id, uname), odd files under /tmp (e.g., pwned.txt), or miners appearing after restarts (common in opportunistic campaigns). (aws.amazon.com)
• Secrets review: if you were online and unpatched as of Dec 4, 2025 at 1:00 PM PT, rotate secrets (OAuth client secrets, API keys, JWT signing keys, database passwords). That’s the official guidance from Next.js. (nextjs.org)
• Asset inventory: don’t forget background workers, preview deployments, or admin tools using RSC endpoints. Scan container images and lockfiles for react-server-dom-*. (cirt.gov.bd)
3) Harden ingress and runtime
• WAF rules: enable Cloudflare Managed Rules (the emergency React RCE rules are on by default for proxied zones), or deploy Google Cloud Armor’s preconfigured CVE rule with the provided expression. Both vendors explicitly recommend patching—treat WAF as a seatbelt, not a force field. (blog.cloudflare.com)
• Rate limiting and path isolation: isolate server function endpoints behind auth or private networking where feasible. Even if you can’t move the whole app, carve out high-risk paths.
• Runtime principles: drop Linux capabilities in containers, run as non-root, restrict egress by default, and enable syscall constraints (seccomp). If malware landed, you want it boxed in.
4) Report, learn, and prevent regressions
• Document a clear timeline: detection time, patch time, indicators, and outcomes. Add this to your incident wiki. • Backlog the “never again” items: lockfile policies, SBOM generation, runtime controls, and WAF-as-code. • If you’re a SaaS, notify customers you’ve patched and rotated secrets.
How to check for compromise in one focused session
Use this granular checklist to cover 80% of real-world cases without boiling the ocean:
• Central logs: filter by Dec 3–10, 2025. Search for the RSC headers and suspicious body markers noted above. Sample queries take minutes to draft in your SIEM. (aws.amazon.com)
• Process audit: list recent processes owned by the app user; flag shells spawned by Node.js and any binaries you don’t recognize. Watch for miners or persistence scripts that respawn under different names.
• Filesystem sweep: diff /tmp and app directories since Dec 3. Hunt for dropped files and strange systemd services. Community reports show attackers toggling filenames aggressively. (reddit.com)
• Secrets and tokens: invalidation plan for JWT signing keys, OAuth refresh tokens, CI deploy keys, and any cloud access keys present in the runtime. If your logs suggest exfiltration, assume the worst and rotate broadly.
• External exposure: validate that traffic only reaches your origin through your WAF/CDN. If your origin IP is public, add ACLs to require the CDN egress ranges, then redeploy.
Can WAFs really stop React2Shell?
Yes, vendors shipped helpful detections quickly. Cloudflare has explicit rules mapped to the CVE and enabled Block by default across managed and free rulesets for proxied zones. Google Cloud shared a precise Cloud Armor expression including header checks for next-action and rsc-action-id. Both are valuable guardrails—especially while you roll patches across fleets—but neither replaces upgrading React/Next.js. (blog.cloudflare.com)
On the edge-runtime side, Cloudflare clarifies Workers aren’t affected by this class of exploit. That doesn’t mean your origin is safe; it means RSC-specific deserialization isn’t happening in the Workers runtime. Patch anyway if the origin serves RSC. (blog.cloudflare.com)
People also ask: fast answers for your team
Is React 18 affected?
No. The vulnerability targets React 19 RSC packages. If your app doesn’t use a server or doesn’t support RSC, you’re not affected by CVE-2025-55182. Validate your dependency graph anyway. (react.dev)
Are Next.js Pages Router apps impacted?
Next.js 13/14 stable with Pages Router aren’t affected. The risk is with App Router on 15.x and 16.x (and certain canaries). (nextjs.org)
Do I need to rotate secrets even after patching?
If your app was online and unpatched as of December 4, 2025 at 1:00 PM PT, yes—rotate. That’s direct guidance from the Next.js advisory. (nextjs.org)
We’re behind Cloudflare. Are we automatically protected?
Cloudflare’s WAF rules were pushed network-wide, including on free plans, with default action set to Block. That helps, but it’s not a substitute for upgrading React/Next.js. (blog.cloudflare.com)
Let’s get practical: the 48‑hour recovery sprint
Use this as a working plan for your Slack war room:
Day 0 (today)
- Freeze deploys except security fixes. Bump RSC to 19.0.1/19.1.2/19.2.1 and Next.js to the fixed line; redeploy. (github.com)
- Enable Cloudflare Managed Rules or deploy the Cloud Armor rule; set to Block after a preview period. (blog.cloudflare.com)
- Run log queries for RSC headers/body patterns; flag anomalies for IR. (aws.amazon.com)
Day 1
- Rotate secrets and invalidate tokens where policy requires (especially if you were unpatched on Dec 4 at 1:00 PM PT). (nextjs.org)
- Sweep hosts for persistence: systemd services, unfamiliar binaries, and suspicious
/tmpartifacts. (aws.amazon.com) - Block direct origin access; require traffic from your CDN/WAF egress ranges only.
Day 2
- Backfill a “virtual patch” dashboard: WAF hits by rule ID, unique IPs, and top URIs—so leadership can track remaining bot noise and confidence rises. (developers.cloudflare.com)
- Write a tight internal PIR (post-incident review) with dates and times, and create follow‑ups for lockfile pinning and SBOM checks in CI.
Zooming out: what React2Shell means for your roadmap
RSC is powerful, but it introduces server‑only execution paths tightly coupled to your build tooling. That blend accelerates product work—and concentrates risk. The lesson from this week:
• Default‑on features become default‑sized attack surfaces. Keep an inventory of server‑side feature flags and protocol endpoints that can be hit pre‑auth.
• “Hello world” scaffolds are not harmless. If a blank template can be exploited, treat first deploys as high-risk until protective defaults catch up. (securitylabs.datadoghq.com)
• WAFs as code. Whether it’s Cloudflare, Cloud Armor, or your ADC, manage rules alongside app code, with staged preview modes, rollouts, and metrics. (cloud.google.com)
Want a structured plan for broader platform hygiene? Our React2Shell: Patch Now—A Pragmatic Playbook goes deeper on emergency response. For teams standardizing on Next.js, pair this with our Next.js CVE-2025-66478 patch guide and the earlier 7‑day rollout plan for the RSC vulnerability. If you’re scheduling broader runtime updates, see December’s Node.js patch runbook to consolidate restarts and testing windows.
FAQ for leadership briefings
How bad is the blast radius?
Material. This is pre‑auth RCE hitting default configurations in one of the most popular web stacks. Multiple vendors and universities report active exploitation and hundreds of attempts across sensor networks. (aws.amazon.com)
Do we need to pull the site offline?
Usually no—if you can deploy the fixed versions quickly and enforce WAF coverage. If logs show likely exploitation or you find persistence, follow your IR plan, consider maintenance mode, and perform a clean redeploy with rotated credentials.
Can we wait for the next sprint?
No. The exploit window has been measured in hours, not weeks. Ship the patch and mitigation now; then chase deeper hardening work in the next sprint. (aws.amazon.com)
What to do next
- Confirm your exact framework and package versions. If you see React 19.0/19.1.0/19.1.1/19.2.0 or Next.js 15.x/16.x with App Router, upgrade immediately. (github.com)
- Re-deploy, then rotate secrets if you were unpatched on Dec 4, 2025 at 1:00 PM PT. (nextjs.org)
- Query logs for RSC headers and suspicious payloads; review hosts for persistence and odd processes. (aws.amazon.com)
- Enable Cloudflare Managed Rules or Cloud Armor rule and keep them in code‑reviewed IaC. (blog.cloudflare.com)
- Close the loop: PIR, playbook updates, and CI checks for
react-server-dom-*versions.
Staying power comes from disciplined basics: known‑good versions, traffic controls, and fast feedback loops. React2Shell won’t be the last zero‑day to hit your web tier, but the way you handle this week can make the next one a non‑event.
Appendix: exact versions and signals (for copy/paste)
Patched RSC versions: 19.0.1, 19.1.2, 19.2.1. (github.com)
Patched Next.js versions: 16.0.7; 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7; canaries 15.6.0‑canary.58 and 16.1.0‑canary.12. (nextjs.org)
WAF quick references: Cloudflare Managed Rules for React RCE; Cloud Armor CVE rule with header checks for next-action and rsc-action-id. (blog.cloudflare.com)
Common IOCs: RSC headers (next-action, rsc-action-id), body markers ($@, "status":"resolved_model"), repeated POSTs probing commands, and suspicious files under /tmp. (aws.amazon.com)
