The React2Shell patch conversation changed again after December 11. If you’re trying to answer a simple question—what does a complete React2Shell patch look like right now?—this piece gives you the current, concrete definition of “safe,” how to prove it in production, and exactly what to do this week.
Where we are: the timeline and why it matters
On December 3, 2025, the React team disclosed a critical Remote Code Execution in React Server Components (CVE‑2025‑55182). The patch landed as React 19.0.1, 19.1.2, and 19.2.1. Within hours, exploit attempts were observed in the wild. One week later, on December 11, two additional RSC issues were announced: a Denial of Service (CVE‑2025‑55184, later requiring a complete fix tracked as CVE‑2025‑67779) and a Source Code Exposure bug (CVE‑2025‑55183). The key takeaway: you could be “patched” for the RCE and still be exposed to the DoS or code exposure if you stopped upgrading before the December 11 releases.
If your production stack includes Next.js with the App Router, these upstream changes propagate through specific Next.js patch versions. The safe set changed on December 11. That’s the catch many teams hit last week.
React2Shell patch: the exact versions that are safe right now
For React 19 applications that use React Server Components, you should be running one of the patched React lines—19.0.1, 19.1.2, or 19.2.1—to address the RCE (CVE‑2025‑55182). But that’s only half the story: the December 11 follow‑ups require you to make sure your framework is also at a version that includes the DoS and Source Code Exposure fixes.
For Next.js applications using the App Router, “safe now” means you’ve covered both the initial RCE and the December 11 pair. Today, these versions include the follow‑up fixes:
- Next.js 14.x: 14.2.35 (addresses DoS for 14.x users)
- Next.js 15.0.x: 15.0.7
- Next.js 15.1.x: 15.1.11
- Next.js 15.2.x: 15.2.8
- Next.js 15.3.x: 15.3.8
- Next.js 15.4.x: 15.4.10
- Next.js 15.5.x: 15.5.9
- Next.js 16.0.x: 16.0.10
- Canary tracks: 15.6.0‑canary.60 and 16.1.0‑canary.19
Important nuances:
- If you upgraded early last week to 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7, you covered the RCE but not the later DoS and Source Code Exposure fixes. Upgrade again to the latest versions above.
- Pages Router apps are not affected by the RSC protocol bugs. That said, if you’ve mixed App Router features anywhere, treat the app as affected and patch.
- If you’re on older canaries (starting from 14.3.0‑canary.77), move to the patched canary listed above or downgrade to a safe stable line.
Let’s get practical: a 60‑minute verification pass
Teams lost time last week hopping between PRs and dashboards. Here’s a crisp verification flow you can run in under an hour per app to confirm your React2Shell patch posture.
1) Inventory and fingerprint
Pull the production manifest for every internet‑reachable app. For each, capture: current Next.js version, React version, and whether App Router with RSC is enabled. Don’t trust local dev—read production artifacts (container image, lockfile, or the deployed bundle metadata) to avoid drift.
2) Check locked versions, not just package.json
Open your lockfile and search for react‑server‑dom‑webpack, react‑server‑dom‑turbopack, and react‑server‑dom‑parcel. Any 19.0, 19.1.0, 19.1.1, or 19.2.0 entries need to be replaced by patched React lines (19.0.1, 19.1.2, or 19.2.1). If you use Next.js, ensure the framework is at the post‑December 11 fixed version for your line (see list above).
3) Use the official fixer where available
For Next.js, run the vendor‑provided helper to deterministically bump to the correct fixed versions and verify your environment. Execute: npx fix-react2shell-next. In CI, fail the build if the checker reports any vulnerable dependency still resolved in the lockfile.
4) Rebuild from clean cache
Invalidate all caches that could pin an older RSC payload or partial dependency graph. For containerized builds, rebuild the image without layer reuse. For serverless or edge targets, trigger a full function rebuild so the patched RSC decoder ships with the artifact.
5) Redeploy, then validate at runtime
After deployment, hit a health endpoint that exercises an App Router path so you know the patched code is executing in production. Capture the resolved dependency versions at runtime and attach them to the release note for audit.
How to hunt for evidence of exploitation
Patching is non‑negotiable. But you should also assess whether someone tried (or managed) to exploit you between December 3 and your fix window. Focus your log review on:
- HTTP POST requests to application endpoints showing RSC or Server Action semantics, especially with headers like next-action or rsc-action-id.
- Request bodies containing odd serialization tokens such as "$@" or fields like "status":"resolved_model" that don’t match your normal traffic.
- Unusual process spawns tied to your Node.js runtime (whoami, id, uname) and suspicious writes in /tmp (for example, pwned.txt).
If you find any of the above during your exposure window, treat it as a potential incident: capture forensic artifacts, rotate secrets, and consider credential stuffing fallout in any systems your app could reach.
People also ask
Do I need to rotate secrets after patching React2Shell?
If your app was internet‑exposed and unpatched any time after December 4, 2025 at 1:00 PM PT, rotate secrets—starting with the most sensitive. Prioritize database credentials, cloud provider credentials, signing keys, and any tokens stored in environment variables. Don’t store secrets inline in code; the Source Code Exposure bug demonstrated how compiled outputs can reveal values referenced directly in Server Functions.
Can a WAF save me if I can’t patch immediately?
A WAF can blunt opportunistic scans with vendor rulesets crafted for React2Shell, but it’s not a substitute for upgrading. If you run on AWS, enable the updated KnownBadInputs managed rule set and monitor hits as a leading indicator of probing. Similar protections are available from other edge providers. Still, the only durable fix is to upgrade to patched React and framework versions and redeploy.
Are Pages Router apps safe?
Yes, if you’ve strictly stayed on the Pages Router and do not use App Router features, you’re outside the affected RSC protocol path. Many teams, however, have hybrid codebases or shared middleware; confirm no App Router endpoints are reachable before you skip upgrades.
Hardening beyond the version bump
Patching stops this set of bugs, but it won’t stop the next variant. Here’s how I recommend hardening RSC apps for the long run.
1) Secrets discipline
Never define secrets directly in code that can be bundled. Keep them in environment variables managed by your platform’s secret store. Review Server Functions that reference configuration; ensure nothing sensitive is inlined by your bundler.
2) Least‑privilege runtime
Run the app under a non‑privileged user, drop Linux capabilities, and lock down file system write access. If an attacker does achieve code execution, blast radius should be minimal. In Kubernetes, combine a read‑only root filesystem, no privilege escalation, and seccomp profiles with per‑namespace network policies.
3) Deterministic dependency control
Pin versions and verify checksums in CI. Generate and archive an SBOM per release so you can prove what shipped. If your organization uses multiple registries or mirrors, enforce a single source of truth and alert on out‑of‑band patches.
4) Observability tuned for app‑layer abuse
Add explicit dashboards for RSC endpoints and Server Actions. Alert on anomaly spikes in POSTs to App Router routes, unusual payload shapes, and increases in 500s or timeouts that could mask DoS attempts.
5) Edge controls as guardrails
Even after patching, keep targeted WAF rules and rate limits in place for a few weeks. Treat WAF telemetry as a tripwire: if it lights up, escalate and re‑check your versions and exposure surface.
A concise “48‑hour remediation sprint” checklist
If you lead an engineering team, here’s the sprint I’d run from today through tomorrow to eliminate doubt and document closure.
Day 1: patch and redeploy
- Freeze non‑security deploys.
- For each internet‑facing app, confirm whether it uses RSC (Next.js App Router is a common indicator). If yes, move to the relevant fixed version: 14.2.35 (14.x), 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, or 16.0.10; canaries 15.6.0‑canary.60 or 16.1.0‑canary.19.
- Ensure React is at 19.0.1, 19.1.2, or 19.2.1 in the lockfile.
- Use npx fix-react2shell-next for Next.js apps to enforce the correct bumps.
- Rebuild from a clean cache and redeploy to production.
Day 2: verify, hunt, and prove
- Runtime verification: capture resolved dependency versions from the live service and attach to the release note.
- Log review: query for suspicious headers (next‑action, rsc‑action‑id), odd payload tokens, and recon commands. Escalate any hits.
- Secrets hygiene: if you were exposed after December 4, rotate keys and tokens starting with the most sensitive. Document the rotation window.
- Stakeholder update: publish a short memo listing affected apps, patched versions, exposure window, log findings, and any rotations performed.
Want a deeper operational runbook? We’ve shared two complementary playbooks: our week‑two React2Shell fixes and test approach and how to close the RSC gaps beyond version bumps. If your team runs on Next.js, see our Next.js December 11 security update guide as well.
Risk for business leaders: how to frame this with the board
Boards don’t want a packet‑capture lecture; they want a clear risk statement and evidence you’re back to green. Here’s a pragmatic framing you can use:
What happened: a critical flaw in React’s server‑side protocol enabled unauthenticated RCE. Follow‑up flaws allowed service disruption and potential code exposure. Exploit attempts were seen within hours of disclosure.
What we did: we upgraded React and our framework to the vendor‑specified safe versions, rebuilt and redeployed, reviewed logs for known indicators, and rotated sensitive secrets where warranted.
Residual risk: we’ve added targeted WAF rules and monitoring for the next two weeks, and we’ve hardened our secret handling and runtime permissions to reduce blast radius for any future app‑layer issues.
Edge cases and gotchas we’ve seen in the field
Hybrid routers cause false confidence. Teams think they’re “Pages Router only,” but a legacy App Router test route is still reachable. Crawl your routes and check framework telemetry.
Canary drift bites CI. If you use canaries for partial prerendering or experiments, lock to the patched canary identifiers above or move to the corresponding stable. Keep an eye on nightly bots that might float versions.
Secrets embedded in code are time bombs. If a Server Function references static credentials, your bundler can inline them. Move all secrets to environment variables and rotate anything discovered during review.
“Patched in dev” isn’t “patched in prod.” Your SBOM or lockfile from development doesn’t prove what’s live. Export dependency data from the artifact you deploy and keep it with the release record.
What to do next
- Confirm your versions match the “safe now” list for both React and your framework.
- Run a targeted log review for the indicators above, covering December 3 through your patch date.
- Rotate secrets if you had any exposure after December 4 at 1:00 PM PT.
- Keep temporary WAF rules and enhanced monitoring in place for at least two weeks.
- Schedule a short post‑mortem: what slowed your patch speed, and how do you remove that friction?
If you need an extra set of senior hands, our team can help with rapid assessments, patch sprints, and hardening plans. Explore our security response services or reach out via contacts.
