The latest Next.js security update isn’t a routine bump. It lands on top of React2Shell and adds two more fixes in the React Server Components (RSC) protocol—one for a Denial of Service and one for potential source code exposure. If you applied the first round of patches, you may still need to upgrade again due to an incomplete DoS fix that was superseded with a new CVE. Treat this Next.js security update as a must‑do: patch, then verify at runtime. (nextjs.org)
What changed on December 11—and why it matters
On December 11, 2025, the Next.js team disclosed two additional RSC issues discovered during post‑mortem analysis of React2Shell patches. They’re not RCE, but they’re serious:
• CVE‑2025‑55183: a flaw that can cause a Server Function to return compiled source of other Server Functions—risking exposure of business logic or inlined secrets if your build setup embeds them.
• CVE‑2025‑55184: a crafted request that can hang your server process (DoS). The initial fix for this DoS was later deemed incomplete and replaced by a complete fix under CVE‑2025‑67779. If you upgraded early, you should upgrade again to the latest patched versions. (nextjs.org)
The advisory is explicit: App Router apps using RSC are affected; Pages Router apps are not. Still, upgrading is recommended so your fleet stays on supported, patched lines. (nextjs.org)
How this ties back to React2Shell (CVE‑2025‑55182)
A week earlier, React2Shell hit with a CVSS 10.0 pre‑auth RCE rooted in RSC serialization. Next.js tracked it as CVE‑2025‑66478 before it was merged into the upstream React CVE. Public guidance urged immediate upgrades and even secret rotation for any app exposed while unpatched. (nextjs.org)
Microsoft’s telemetry observed exploitation attempts as early as December 5, with successful compromises often dropping coin miners and a mix of RATs, and impacting both Linux and Windows environments. If you were late to patch, assume exposure and investigate. (microsoft.com)
Which Next.js versions are actually safe right now?
For the December 11 update, the safe targets vary by release line. Highlights include:
• 14.x: upgrade to 14.2.35
• 15.0.x: 15.0.7
• 15.1.x: 15.1.11
• 15.5.x: 15.5.9
• 16.0.x: 16.0.10
• Canary lines also have patched builds.
Run the interactive fixer: npx fix-react2shell-next. It checks versions and performs deterministic bumps to the recommended releases. If you patched immediately after the first DoS fix, upgrade again to catch the complete CVE‑2025‑67779 remediation. (nextjs.org)
Next.js security update: a practical patch‑and‑prove playbook
Here’s the thing—dependency bumps alone aren’t the finish line. You need a plan that gets you to “running, observed, and safe” without derailing delivery. Use this six‑step flow we’ve used on real teams.
1) Put guardrails up
Freeze unrelated deployments for 24–48 hours. Announce a maintenance window. Turn on feature flags to allow quick rollback of high‑risk endpoints. If you run a monorepo, isolate the Next.js workspaces so you can ship them independently.
2) Inventory and scope, fast
Map every internet‑facing app using RSC and the App Router. Grep for server actions and use server annotations. Don’t forget SSR utilities or shared server functions used by multiple apps. Tag apps by traffic tier and customer impact to prioritize rollout.
3) Upgrade the framework—then lock it down
Set explicit version ranges in package.json and ensure your lockfile captures the exact patched build. In CI, enforce a denylist for known vulnerable versions. Use npm ls next react to confirm transitive consistency. If your build requires canary for Partial Prerendering (PPR), move to the patched canary mentioned in the advisory. (nextjs.org)
4) Rebuild, test, and rehearse failure
Rebuild containers and redeploy to a pre‑prod environment with production‑like headers and caching. Hit key Server Actions with fuzzed payloads to catch regressions. Add tests that assert non‑leakage of server code in responses and verify the server stays responsive on malformed requests.
5) Ship with observability in place
On rollout, enable elevated logging for 24–48 hours. Track: error rate for App Router routes, CPU saturation, event loop lag, and any sudden surge in 5xx. Alert on unusual multipart/form-data or form‑encoded POSTs to RSC endpoints, which have been used in exploit attempts. Pair this with rate limiting on the RSC endpoints.
6) Prove it’s safe in prod
After patching, confirm the app reports the patched Next.js version, verify lockfile integrity, and run synthetic probes that would have hung the server prior to the fix. Keep a dashboard with version and health checks per service for the next week.
Do I need to rotate secrets after React2Shell?
If your app was internet‑facing and unpatched around December 4, 2025, the Next.js team recommended rotating secrets. That’s still wise if you lagged on patching, especially for cloud credentials and payment keys. Prioritize secrets referenced by server actions, then rotate the rest on a schedule. (nextjs.org)
What about WAFs and managed platforms?
WAFs can help—but they’re a seatbelt, not the brake. Google Cloud shipped an opt‑in Cloud Armor rule to detect/block common React2Shell payloads and also enabled platform‑level protections across several serverless services. Use this as a temporary shield while you patch, and start in preview/log‑only mode to validate no false positives before enforcing. Patch anyway; WAFs can’t fix vulnerable parser logic. (cloud.google.com)
Running on Vercel or Netlify? Their security advisories and runtime controls help, but the vulnerability lives in your app’s dependency graph. You still need to bump versions, rebuild, and redeploy.
How to check if you were compromised
Signs we’ve seen (and Microsoft reported) in the wild include: sudden CPU spikes from cryptominers, suspicious reverse shells, new system users, unexpected RMM agents, and outbound connections to tunnel services. Inspect containers and hosts for unauthorized keys, odd processes, and scheduled tasks. If you find anything, treat the box as burned: rebuild from clean images and rotate secrets. (microsoft.com)
A quick host and container triage
• Review recent child processes of your Next.js runtime, looking for shells and network beacons.
• Check for newly created users or SSH keys.
• Scan for known miner binaries and common persistence mechanisms.
• Enumerate environment variables to spot exposed secrets; invalidate them.
Gotchas that bite teams during this upgrade
• Shadow dependency drift: a nested app or example folder still compiling an old Next.js/React pair. Block merges until npm ls shows a single, patched set.
• Canary surprises: if you adopted canary for PPR, make sure you’re on the patched canary lines referenced in the advisories.
• Partial patching: the DoS fix needed a second pass (new CVE). If your upgrade was early, you must upgrade again to the latest patched release in your line. (nextjs.org)
People also ask
Is the Pages Router affected by these new CVEs?
No, the December 11 advisories target RSC in App Router. Pages Router apps aren’t affected by these specific issues, but keeping them updated is still smart for overall security posture. (nextjs.org)
Can I just rely on a WAF and skip patching?
No. WAFs can block known exploit traffic but won’t fix the vulnerable behavior in your app. Use platform rules (like Cloud Armor’s) while you patch, not instead of patching. (cloud.google.com)
Which exact Next.js versions should I install?
Target the patched versions listed by the Next.js team for your release line—examples include 14.2.35 (14.x), 15.0.7/15.1.11/15.5.9 (15.x lines), and 16.0.10 (16.x). Run npx fix-react2shell-next to guide upgrades and validate. (nextjs.org)
A simple verification checklist you can run today
• Confirm Next.js and React versions are at or above patched levels in package.json and your lockfile.
• Rebuild images; don’t hot‑swap node_modules in place.
• Add a synthetic monitor that hits typical RSC endpoints with malformed inputs and ensures the server stays responsive.
• Turn on elevated logs and alerts for App Router endpoints for 48 hours.
• Review WAF logs in “preview” mode; then enforce if clean. (cloud.google.com)
If you lead the team, ask these five questions today
• Which apps use App Router with RSC, and which are customer‑facing?
• What version is each app running in prod, and when will it hit the patched line?
• How do we prove our fix is live (observability and synthetic probes)?
• Which secrets will we rotate, and in what order?
• What’s our rollback path if we see regressions?
If you need a ready‑made runbook, our earlier write‑ups walk through a safe cadence to ship without breaking prod—start with a Next.js patch‑and‑prove checklist and the broader React2Shell: secure Next.js this week guidance. For larger estates, the disciplined approach in our 48‑hour patch plan maps well to web stacks too. When in doubt, contact our team—we’ve helped clients ship these upgrades with minimal downtime.
Data points and dates you can bring to the exec update
• Dec 3, 2025: React2Shell disclosed (CVE‑2025‑55182), CVSS 10.0; Next.js tracked as CVE‑2025‑66478. (nextjs.org)
• Dec 5, 2025: Exploitation observed in the wild; coin miners frequently dropped. (microsoft.com)
• Dec 11, 2025: Next.js adds two RSC fixes (DoS and source exposure); early DoS fix later superseded by CVE‑2025‑67779; new patched target versions published. (nextjs.org)
• Google Cloud shipped an opt‑in Cloud Armor rule and platform‑level protections for common exploit attempts; guidance updated through Dec 12. (cloud.google.com)
What to do next
• Upgrade to the latest patched version in your release line and rebuild.
• Run npx fix-react2shell-next and confirm lockfile integrity.
• Deploy with enhanced logging; add synthetic probes that validate non‑hang behavior and no code leakage.
• Enable a WAF rule (preview → enforce) if your platform supports it.
• If you were late patching in early December, rotate secrets starting with the most sensitive.
• Conduct a quick compromise assessment; if you find anything, rebuild from clean images and invalidate credentials. (nextjs.org)
Zooming out, the lesson is clear: shipping RSC apps means treating framework updates like operational events. Patch promptly, verify in production, and keep a muscle‑memory playbook handy. Do that, and security releases become routine, not fire drills.
