The latest Next.js security update isn’t just another advisory—it’s the follow-on to React2Shell and it lands squarely on teams running the App Router. On December 11, 2025, the React team disclosed two additional React Server Components (RSC) issues (a Denial of Service and a Source Code Exposure). Next.js shipped coordinated patches the same day and later added an addendum clarifying that the initial DoS fix (CVE‑2025‑55184) required a complete replacement (CVE‑2025‑67779). If you’re still mid‑holiday sprints, here’s the clear path: patch fast, prove it’s fixed, and harden your RSC surface.
Why this week matters: a quick timeline with exact dates
What happened—and when? Dates matter because many teams patched once and assumed they were done.
• November 29, 2025: A researcher reported a critical RSC issue to the React team.
• December 3, 2025: React publicly disclosed CVE‑2025‑55182 (“React2Shell”), a pre‑auth RCE affecting RSC packages in the 19.0–19.2.0 range. Active exploitation began within hours and continued across sectors.
• December 11, 2025: React disclosed two more RSC issues: a High‑severity DoS (initially CVE‑2025‑55184) and a Medium‑severity Source Code Exposure (CVE‑2025‑55183). Next.js published downstream guidance and patched releases across supported lines.
• December 11–12, 2025: Next.js added an addendum: the initial DoS fix was incomplete and is now fully addressed under CVE‑2025‑67779. Teams that upgraded on December 11 may need to upgrade again to the latest patched build in their line.
Bottom line: if your last upgrade landed before December 12, verify your version numbers. You may still be exposed to the DoS variant until you install the corrected builds.
Who’s actually affected—and how
Let’s separate signal from noise so you can make the right moves.
• Next.js App Router apps are affected by the new RSC issues (DoS and Source Code Exposure). The prior RCE mitigation for React2Shell remains effective if you’re on the patched versions.
• Pages Router apps aren’t directly affected by the new RSC issues, but upgrading to a patched Next.js in your major line is still wise to keep transitive RSC packages aligned and avoid surprises when you adopt App Router features later.
• The Source Code Exposure bug can cause a Server Function to return compiled code of other Server Functions. If secrets are inlined into code (for example, constants or build‑time injected values), you risk leakage. Secrets read from environment variables at runtime are safer, but still audit your patterns.
Exact Next.js versions to install today
The project advises upgrading to the latest patched release in your line. As of December 11–12 patches, these fixed versions are listed for the current trains:
• 14.x → 14.2.35
• 15.0.x → 15.0.7
• 15.1.x → 15.1.11
• 15.2.x → 15.2.8
• 15.3.x → 15.3.8
• 15.4.x → 15.4.10
• 15.5.x → 15.5.9
• 16.0.x → 16.0.10
• 15.x canary → 15.6.0‑canary.60
• 16.x canary → 16.1.0‑canary.19
Command to get moving: npx fix-react2shell-next. The tool scans monorepos, bumps next and RSC packages to their patched counterparts, and refreshes your lockfile deterministically. It’s the fastest way to align every package.json without hand editing.
The 90‑minute Patch‑and‑Prove plan (copy/paste this)
Teams keep asking for a plan that fits in a sprint back‑to‑back. This is the one we’ve used on real projects.
1) Inventory and freeze (10 minutes)
• List all Next.js apps and services that expose RSC endpoints (monorepos included).
• Freeze deploys for 90 minutes. If you can’t, set a feature‑flag guard to temporarily reduce attack surface (e.g., rate limit or gate risky endpoints) while you patch.
2) Patch deterministically (15–25 minutes)
• From repo root, run npx fix-react2shell-next. Accept the recommended bumps.
• Verify the resulting versions match your line’s fixed targets above. If they don’t, pin explicitly in package.json and re‑install.
• Ensure your Node.js runtime matches what the new build expects in CI and prod (Node 18+ for most 15.x/16.x apps). Mismatched engines will create flaky deploys you’ll mistake for regression.
3) Prove the RSC path is safe (20–25 minutes)
• Run your e2e tests against endpoints that trigger Server Actions and dynamic RSC payloads—this is where deserialization happens.
• Add a negative test: send malformed RSC payloads (e.g., fuzzed headers or corrupted Flight data) and assert the server responds with an error and recovers on the next request. The DoS fix should prevent hangs or runaway loops.
• Smoke test authenticated flows that depend on server functions. If you cache RSC responses at the edge, purge and validate fresh responses.
4) Ship with guardrails (10 minutes)
• Enable short‑term higher‑sensitivity alerts: spike in 5xx from RSC endpoints, sudden CPU saturation, or unusual memory growth (classic DoS indicators).
• If you run a WAF, add a temporary rule to throttle suspicious RSC requests until traffic normalizes.
5) Watch for exposure and rotate where needed (10–20 minutes)
• Search request logs and APM traces for abnormal bytes‑in on RSC routes after December 3 and again after December 11. Look for repeated malformed or oversized request bodies.
• If any Server Function returned unexpected serialized output, assume compiled code could have been exposed. Rotate secrets that might be inlined by your build (API keys baked into constants, static salts, etc.). Favor runtime process.env reads.
How to tell if you’re vulnerable—fast
Three practical checks, in order of speed:
• Version check: if next -v reports anything below your line’s fixed build (e.g., 15.4.10 on 15.4.x), upgrade now.
• Traffic check: scan logs for repeated errors or timeouts on RSC endpoints since Dec 11. A sudden increase right after your first “React2Shell” patch can signal you installed the incomplete DoS fix and need the replacement build.
• Fuzz test: against a staging clone, send intentionally malformed RSC payloads and confirm the server rejects them without hanging. Keep this test in CI; it costs little and catches regressions.
People also ask: your quick answers
Is Pages Router affected?
No for the Dec 11 RSC issues, but upgrade anyway to keep your dependency tree aligned and reduce friction when you adopt App Router features. And if you added any RSC preview features to a Pages app, you’ve effectively opted into the same risk class.
Do I need to rotate secrets?
If you used constants or build‑time inlining for sensitive values in Server Functions, yes—treat them as potentially exposed. If you load secrets at runtime via environment variables and don’t inline them, risk is lower, but review call sites and rotate where doubt remains.
Does the React2Shell RCE still work after I update?
No—if you’re on patched RSC packages (19.0.1, 19.1.2, or 19.2.1 and their framework integrations) and on the Next.js fixed builds for your line, the RCE path is mitigated. The Dec 11 advisories addressed different issues (DoS and source exposure) that surfaced after scrutiny of the initial fix.
Could an attacker have crashed my servers without leaving logs?
Possibly. A tight loop DoS may look like a hang and force a process restart without a clean stack trace. Correlate with infra metrics: CPU pegged, request queue growth, and abrupt pod restarts around identical timestamps.
Hardening your RSC surface for the rest of Q4
Patch, then make abuse less interesting. Here’s what we’re rolling out on client projects:
• Put light rate limiting in front of RSC endpoints. You’ll catch brute‑force probes and give autoscaling time to react.
• Set a sane max body size and header size on the edge or ingress. Malformed payloads tend to be big or oddly small.
• Prefer runtime secrets over build‑time constants. Avoid bundling secrets into compiled server code to reduce blast radius from any future exposure bugs.
• Keep a synthetic test that exercises a typical RSC request/response path and fails loudly on unbounded latency. This closes the loop on future regressions.
CI caveat: npm classic tokens were revoked on December 9
Unrelated to RSC but painfully adjacent to your upgrade window: npm permanently revoked classic tokens on December 9, 2025. If your builds suddenly started failing while you were trying to roll security patches, that’s probably why. Switch your pipelines to granular access tokens, apply the new 2FA defaults appropriately, and avoid using local 2‑hour session tokens in CI. We published a short field guide—see how to fix your CI after npm classic tokens were revoked.
Data you can put in a ticket right now
When leadership asks, “Are we covered?”, give them exacts:
• React2Shell (CVE‑2025‑55182) disclosed December 3, 2025; RCE path mitigated by updating RSC packages to 19.0.1, 19.1.2, or 19.2.1 and corresponding framework patches.
• Two additional RSC issues disclosed December 11, 2025: DoS (initially CVE‑2025‑55184, superseded by CVE‑2025‑67779) and Source Code Exposure (CVE‑2025‑55183).
• Next.js fixed builds include 14.2.35, 15.0.7, 15.1.11, 15.2.8, 15.3.8, 15.4.10, 15.5.9, and 16.0.10 (plus latest canaries).
• npm classic tokens revoked December 9, 2025; CI may fail until you migrate to granular tokens.
A quick test matrix you can reuse
Use this to standardize validation across services:
• Deserialization abuse test: corrupted Flight payload → server returns 4xx/5xx and stays responsive on next request within 1 second.
• Concurrency test: 50 parallel RSC calls → p95 latency holds steady within 10% of baseline.
• Source exposure negative test: Server Function returning unexpected serialized code triggers alert in staging and blocks deploy via canary health checks.
• Secrets hygiene check: no hard‑coded secrets or static salts in Server Functions; all secrets fetched at runtime via environment variables or secret manager.
What to do next (developers)
• Run npx fix-react2shell-next and upgrade to the patched build for your train.
• Add a malformed‑payload CI test and a 50‑parallel RSC test. Keep them.
• Audit Server Functions for build‑time secret inlining; refactor to runtime reads if found.
• Turn on temporary WAF throttling for RSC routes until traffic settles.
What to do next (product and security leaders)
• Ask for a one‑page rollup by end of day that lists every Next.js service, its patched version (e.g., 15.4.10), the date/time deployed, and the test evidence (screenshots or CI links).
• Approve a short maintenance window for follow‑up upgrades this week; the DoS fix replacement means some teams must patch twice.
• Require rotation of any secrets discovered in code during the audit, with owners and deadlines.
Want hands-on help?
If you need an external pair of hands to stabilize your release train, we’ve been shipping these fixes with clients all week. Read our deeper breakdown in Next.js Security Update (Dec 11): Fixes, Risks, Plan and our practical version‑by‑version guide in Next.js Security Update: What to Patch Now. If you’re still catching up on the original RCE, we have a focused playbook in React2Shell: Your 14‑Day Patch and Proof Plan. And if your builds went red last week because of npm auth changes, start here: Fix your CI after npm classic tokens were revoked.
Zooming out
Here’s the thing: critical bugs invite follow‑ups. The Dec 11 advisories are not surprising—they’re what happens when researchers swarm adjacent code paths after a big RCE lands. The right muscle to build is fast, repeatable upgrades plus a few cheap tests that scream if something drifts. Do that, and the next time a CVE hits your stack on a Thursday, you’ll still make your Friday ship.
