React2Shell: What to Patch Now in Next.js

React2Shell is the shorthand many teams are using for a critical CVSS 10.0 remote code execution vulnerability in the React Server Components (RSC) protocol that directly impacts Next.js apps using the App Router. If your services accept untrusted requests and run RSC, you have real exposure. The good news: there are clear patched versions to move to today—and practical ways to prove you’re safe without torpedoing your error budget.

What changed this month: a quick, data-backed timeline

On December 3, 2025, the React team disclosed an unauthenticated RCE in RSC (CVE-2025-55182) affecting packages such as react-server-dom-webpack and related implementations. Next.js followed with downstream guidance noting that App Router apps are affected and provided patched releases. A week later (December 11), additional protocol issues were documented; these didn’t reintroduce RCE, but they did require further upgrades, including an addendum clarifying an incomplete fix that was superseded by a newer patch. By mid-December, major security vendors reported exploitation attempts in the wild—mostly coin miners, some red-team traffic, and opportunistic probes—validating that this isn’t a drill.

Separately, the Node.js project updated its December security release schedule, ultimately moving the drops to January 7, 2026 to finish complex patches across 25.x, 24.x, 22.x, and 20.x. That means many teams will run two security moves: React/Next.js now, and Node.js platform updates right after the holidays.

React2Shell: the exact Next.js patches to install

If you’re running Next.js with the App Router, upgrade immediately to one of the fixed lines below. Pages Router apps aren’t directly affected by the RSC protocol flaw, but upgrading keeps you aligned with dependency hardening and future fixes.

Recommended fixed versions:

• Next.js 14.x: upgrade to 14.2.35
• Next.js 15.x LTS lines: upgrade to the latest patched point release (for example, 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, or 15.5.9 depending on your branch)
• Next.js 16.0.x: upgrade to 16.0.10 or newer

If you’re unsure which path you’re on, pin to the newest patch in your major/minor to reduce blast radius. Also verify that your underlying React RSC packages are on the patched versions for your toolchain.

Is there a one-shot fixer?

Yes. The Next.js team published a helper you can run to accelerate remediation and ensure your RSC dependencies and config are in a known-good state. For teams managing dozens of services, standardize this into your secure baseline job and run it across repos before opening individual PRs.

What about the Pages Router?

Pages Router apps aren’t impacted by the RSC protocol bug the same way the App Router is, but they still benefit from dependency updates and the ecosystem’s fast-follow fixes. If you’re mid-migration to the App Router, prioritize patching before enabling new RSC features.

Here’s the thing: patching is table stakes—proof matters

Security leaders don’t want vague “we upgraded” statements. They want evidence. Treat this like a compliance-grade change: document versions, tests, and runtime signals. Below is a tight, no-drama workflow you can run today.

The Patch–Prove–Prevent checklist (works in monorepos and polyrepos)

Patch

• Inventory: enumerate all services that use Next.js App Router or RSC. Include internal tools and marketing microsites—attackers don’t care about your org chart.
• Upgrade: apply the fixed Next.js version for your branch and update lockfiles. Rebuild containers from scratch; don’t rely on layer cache.
• Re-deploy: roll out to at least one pre-prod environment with production parity for runtime flags and build tooling.

Prove

• Runtime verification: expose a build metadata endpoint (or header) that returns the Next.js and React RSC versions at runtime. Capture a screenshot or structured log line during rollout and archive it in your change ticket.
• SBOM attestation: regenerate an SBOM for the build (CycloneDX or SPDX) and store it with the release artifact so auditors can trace versions later.
• Exploit simulation: use safe request payloads against your RSC endpoints to confirm expected error codes and behavior—no deserialization exceptions, no server crashes, no unexpected stack traces. Record the request/response and attach it to the ticket.

Prevent

• WAF and rate limits: add explicit rules for RSC endpoints, including size limits and anomaly thresholds, even if the patch is in place.
• Guardrails: add an e2e test that asserts the runtime Next.js/React RSC versions are within an allowlist, failing the pipeline if they drift.
• Secrets rotation (conditional): if your app was public and unpatched between December 3 and December 6 Pacific time, rotate tokens and high-value credentials. It’s cheap insurance compared with incident response.

People also ask: do I really need to rotate secrets?

If your internet-facing App Router service was online and unpatched in the first 72 hours after disclosure, assume reconnaissance. Even if you don’t find smoking-gun logs, you should rotate your most sensitive secrets—cloud access tokens, CI deploy keys, and upstream API keys. Keep the blast radius small by scoping tokens tightly for future services.

How to detect vulnerable RSC usage in your estate

Not every team has perfect service catalogs. Use multiple signals:

• Source scan: search your repos for imports of react-server-dom-* packages and for App Router constructs that indicate RSC usage.
• Lockfile scan: look for react-server-dom-* and Next.js versions below the fixed lines. Do this for both npm and pnpm/yarn lockfiles in monorepos.
• Runtime headers: many RSC responses use an internal format (the “Flight” protocol). Sample responses in non-prod and confirm your runtime is on a patched release by checking build metadata.
• Traffic telemetrics: in your reverse proxy logs, isolate requests that hit RSC endpoints and look for anomalous payload sizes or spikes beginning December 5–15.

Will this patch break production?

Most teams report clean upgrades within a minor line. The top breakage causes we’ve seen are custom server setups that drifted from defaults, pinned or vendored RSC internals, and brittle build pipelines that assumed a specific chunk naming convention. Run canary deploys to a small percentage of production traffic and watch for error-rate deltas before ramping to 100%.

Security and platform leaders: set the rules of engagement

Your job is to turn a patch scramble into a repeatable muscle memory. A few standards worth locking in:

• Time-bound SLAs: for critical CVEs on internet-facing services, define a 72-hour SLA to upgrade, prove, and complete a change record.
• Attestation by default: every production deploy must export build metadata (framework version, commit, build time) so security can verify without guessing.
• SBOM or it didn’t happen: require SBOM generation on all builds and store them with artifacts for 18–24 months.
• Change windows: pre-book patch windows around known ecosystem events (e.g., Node.js security releases) so you’re not negotiating calendars under pressure.

Node.js security releases moved to January 7: what to expect

Originally targeted for mid-December, the bundled Node.js security fixes were pushed to January 7, 2026 to finish complex patches. Release lines 25.x, 24.x, 22.x, and 20.x are on deck, with multiple high-severity issues in scope. Expect rapid distro updates and container base image refreshes that week. Treat this as a separate, planned change from your React/Next.js remediation—even if they land close together—so you can isolate regressions.

If you want a ready-made cadence, use our short playbooks tailored to busy teams: start with the 48‑hour plan for triage and staging, then the 72‑hour plan for production rollout and audit artifacts. They distill the operational steps we’ve used across dozens of client environments.

• Follow the 48‑hour response in Node.js Security Releases: Your 48‑Hour Plan.
• Use the production-safe checklist in Node.js Security Releases Today: Your 72‑Hour Plan.
• For Next.js specifics, see Next.js Security Update: Patch, Prove, Repeat and our practical follow-up React2Shell Aftershocks: Patch, Prove, Don’t Break Prod.

Let’s get practical: a 90-minute war-room runbook

If you’ve got one hour and thirty minutes to pull your situation together, use this sequence with two people: one operator, one reviewer.

1. Confirm scope (10 minutes). List all internet-facing services with Next.js. Tag App Router vs. Pages Router. Flag anything that handles authentication or secrets as P1.
2. Pick target versions (5 minutes). Choose the fixed Next.js version for each service’s branch and write it into a shared doc.
3. Automate the bump (20 minutes). Use your fixer script plus package manager updates. Regenerate lockfiles and build images with no cache. Kick off CI.
4. Functional smoke (15 minutes). Run login, checkout, dashboard, and any RSC-heavy pages. Screenshot success states for the change record.
5. Runtime attestation (10 minutes). Pull a response header or metadata route showing Next.js and RSC versions. Paste into the ticket.
6. Pre-prod canary (15 minutes). Route 5–10% traffic for 10 minutes. Compare errors and latency. If clean, ramp to 100%.
7. Post-deploy guard (15 minutes). Add WAF rules and rate limits on RSC endpoints, enable anomaly alerts, and schedule a secrets rotation if your exposure window overlapped early December.

What about other frameworks using RSC?

Anything that implements the RSC “Flight” protocol and runs server-side execution deserves scrutiny. Frameworks that adopted RSC early or maintain compatible transports need explicit guidance from their maintainers; watch their release notes and advisories, and prefer versions that call out CVE-2025-55182 remediation. If you’re experimenting with custom RSC implementations, consider disabling them until you can verify the protocol-level fixes are present.

Edge cases and gotchas we’ve seen in real teams

Private subdomains exposed via temporary DNS during QA can still be hit by scanners; treat them as public. Build pipelines sometimes ignore the lockfile on Docker builds and pull stale caches—force a clean build. Monorepos with mixed package managers hide drift; standardize on one or add a preflight that fails if multiple lockfiles are present. Finally, don’t forget long-lived preview deployments on Platform-as-a-Service providers—tear down unpatched previews.

Why this matters to business leaders

This is less about a scary headline and more about operational maturity. The vulnerability window started on December 3; exploitation attempts appeared within days. Teams that can patch, prove, and prevent within a 72-hour window reduce customer risk and prove they can handle platform-level issues like the Node.js January releases without drama. Documenting this response also makes the next vendor security questionnaire faster—and more favorable.

FAQ speed round

Is React2Shell being exploited in the wild?

Yes, defenders have reported attempts shortly after disclosure. Most were noisy miners, but that’s beside the point: if it’s exploitable, assume scanning and move.

Do I need to rotate secrets for every app?

No. Prioritize services that were internet-facing and unpatched in the first few days after December 3. Start with cloud tokens, CI/CD deploy keys, and partner API keys.

We’re on Pages Router. Can we sit this out?

You’re in a better place, but you should still upgrade to a patched line and add the guardrails above. Future changes ride on these versions.

We have a holiday code freeze. Now what?

Freeze exceptions for critical CVEs exist for a reason. Use feature flags to minimize risk, deploy in canary mode, and capture proof so stakeholders are comfortable.

What to do next (today and next three weeks)

Today

• Upgrade your Next.js App Router apps to a fixed patch version and document runtime proof.
• Add WAF/rate limits to RSC routes and schedule secrets rotation if you were exposed.
• Create a single page in your runbook with the patch–prove–prevent checklist.

Next 7 days

• Audit all internet-facing sites and marketing microsites for drift and update them.
• Build the SBOM generator into CI and require version attestation for prod deploys.
• Run an exploit simulation in a sandbox to baseline alerts.

Week of January 6–10

• Allocate time for the Node.js security releases on January 7, 2026; plan a rolling upgrade per service.
• Use our short playbooks to avoid regressions while keeping audit trails tight.

Want help pressure-testing your plan or running a rapid response? Our team ships fixes and proof, fast. See our security and platform services, browse relevant work on the portfolio page, and reach out via contacts if you need a guided patch sprint.

Zooming out

RSC is powerful—and young. Protocol-level bugs happen in young tech. The right response isn’t to freeze innovation; it’s to enforce clean baselines, fast patching, and production proofs. Do that now for React2Shell, and your team will be ready when the Node.js updates land in the first week of January.