Next.js Security Update: Patch Again After Dec 11

The latest Next.js security update isn’t optional. After the December 3 disclosure of React2Shell (CVE‑2025‑55182, a CVSS 10.0 RCE in React Server Components), the React team followed up on December 11 with two related RSC issues: a Denial‑of‑Service bug and a source code exposure bug. Next.js shipped patches across supported release lines—and then clarified that the initial DoS fix was incomplete, with a new complete fix issued shortly after. If you run the App Router, plan to update again, verify in production, and in some cases rotate secrets.

What changed after React2Shell?

Here’s the thing: critical CVEs attract variant hunting. The December 3 React2Shell patch blocked the RCE path in RSC, but researchers quickly uncovered two additional issues disclosed on December 11, 2025:

• CVE‑2025‑55184 (High): A crafted request could trigger an infinite loop during deserialization, hanging the server and causing a DoS.
• CVE‑2025‑55183 (Medium): A crafted request could cause a Server Function to return compiled source code for other Server Functions. If you hardcoded secrets directly in code (don’t), those could leak.

Shortly after, maintainers noted that the initial fix for the DoS was incomplete and published a complete fix tracked under CVE‑2025‑67779. Bottom line: if you patched immediately on December 11, patch again to the latest point version in your line.

Next.js versions you should target

For App Router apps, update to or beyond the following versions (or their successors):

• 14.x: 14.2.35 or later
• 15.0.x: 15.0.7 or later
• 15.1.x: 15.1.11 or later
• 15.2.x: 15.2.8 or later
• 15.3.x: 15.3.8 or later
• 15.4.x: 15.4.10 or later
• 15.5.x: 15.5.9 or later
• 16.0.x: 16.0.10 or later

Pages Router apps aren’t affected by the RSC path, but you should still move to the latest patched version to keep future upgrades smooth.

Am I affected? A quick triage you can do right now

If your app uses the App Router with React 19 packages, assume exposure until you prove otherwise. Run these checks in your project root:

# 1) Do you depend on RSC packages (directly or via Next.js)?
npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack || true

# 2) What Next.js line are you on?
npx next --version || node -p "require('./package.json').dependencies['next']"

# 3) Are you on a patched version?
# Compare your version against the target list above.

Using monorepos with React Native? You may have RSC packages installed for web targets. Patch only the affected packages to avoid version mismatch warnings in React Native, then verify.

Next.js security update: the 20‑minute patch plan

Let’s get practical. If you’re on 14.x, 15.x, or 16.x with the App Router:

1. Checkpoint your lockfile and CI: Commit your lockfile, ensure CI runs your full test suite on PRs, and confirm rollback is one click away.
2. Apply the official upgrader (if applicable): The maintainers published a helper. Run: npx fix-react2shell-next. It updates affected packages and nudges you to the patched line.
3. Upgrade to the patched version in your line: For example:
   npm i [email protected] or npm i [email protected] (or later). If you manage React directly, update react-server-dom-* to the patched series as well.
4. Rebuild and redeploy staging with production flags. Validate SSR, Server Actions, and any endpoints that stream RSC payloads.
5. Promote to production during a staffed window. Monitor error rates, saturation, and latency for 30–60 minutes.

Using pnpm or yarn? Use the equivalent commands. In all cases, destroy and rebuild images or layers that could cache vulnerable artifacts.

Do I need to rotate secrets?

If your app was online and unpatched as of December 4, 2025 at 1:00 PM PT during the initial React2Shell window, you should rotate critical secrets (cloud credentials, database passwords, tokens) and review logs for anomalous server‑side execution. If you hardcoded secrets into Server Functions, treat them as compromised and eradicate that practice immediately—use runtime env vars and a secrets manager instead.

Prove you’re safe: verification checklist

Don’t stop at “it builds.” You’ll be asked for evidence. Use this checklist to build a defensible record:

• Inventory proof: Snapshot npm ls output for next and react-server-dom-* packages. Store the artifact in your ticketing system.
• Version gates in CI: Add a policy check to fail builds if next is below your patched threshold. A simple Node script parsing package.json is enough.
• Functional probes: Exercise at least one route that triggers Server Actions and server streaming. Keep the canary probe in production for 72 hours post‑patch.
• Traffic sanity: Watch for spikes in 5xx, worker restarts, or watchdog restarts that could indicate lingering DoS edge cases.
• Log correlation: Grep ingress logs for requests to RSC endpoints with unusual binary payloads or oversized frames. Keep samples for incident response.

Deploying on Deno Deploy? They implemented a runtime‑level mitigation for the DoS variant on December 11. That’s good defense‑in‑depth, but it doesn’t remove your obligation to patch code. Platform mitigations can disappear when you switch providers or execution modes.

People also ask: the questions your team will ping you with

Which Next.js versions are considered safe now?

Use the latest point release in your line. For 14.x, target 14.2.35+. For 15.x, target 15.0.7+, 15.1.11+, 15.2.8+, 15.3.8+, 15.4.10+, or 15.5.9+. For 16.x, target 16.0.10+ (or newer). Staying current matters because the DoS fix was refined after the first patch.

Does Pages Router avoid the blast radius?

Yes for these RSC‑specific bugs, because Pages Router doesn’t use RSC. Still, stay on patched Next.js versions for other hardening and to keep upgrade paths clean.

Are managed hosts immune?

No. Some providers added mitigations, but those are not a substitute for dependency upgrades. Always patch your app, then treat host‑level defenses as a helpful backstop.

Does this affect React Native?

Only if your workspace installs vulnerable react-server-dom-* packages. Patch those packages directly without bumping react / react-dom to avoid version mismatch warnings in RN projects.

Defense‑in‑depth for RSC apps: practical hardening

RSC introduced powerful server execution paths—treat them as an RPC boundary, not a simple render pipeline. Here’s a pragmatic hardening set we’ve rolled out on production teams:

• Ingress limits: Apply strict request body limits and timeouts to RSC endpoints. Reject overly large frames and slowloris patterns.
• Auth first, always: Ensure Server Actions that mutate data require session context and CSRF protections where relevant. Don’t rely solely on middleware for auth decisions.
• Secret hygiene: Never inline secrets into code. Use environment variables and a secrets manager. Ban patterns via static analysis (Semgrep can do this in minutes).
• SBOM + SCA: Generate a software bill of materials per release. Pin to exact versions and scan for CVEs during CI.
• RSC‑aware logging: Add correlation IDs to server function invocations and surface them in client telemetry. If anything goes sideways, you’ll trace it fast.
• WAF signals: Add signatures for malformed RSC payloads and block known exploit probes. Rate‑limit bursts to RSC endpoints.
• Chaos in staging: Reproduce the DoS pattern safely against staging to validate that your process supervisors and autoscaling behave as expected.

Zooming out: what this means for your roadmap

Security in 2025 isn’t just about patching after the blog post. RSC centralizes privileged execution inside your web tier. The upside is velocity; the downside is that serialization bugs turn into server‑side code execution or hangs. Build a culture where every feature that crosses the server boundary has a threat model, a default deny posture on inputs, and safety nets at the process and platform layers.

If you lead a platform team, bake these expectations into templates and guardrails. New apps should ship with request limits, structured logging, and dependency policy checks from day one. Make the right thing the easy thing.

Related guides and deeper dives

We’ve been tracking this closely. If you want a concise walkthrough of the first wave, read our Next.js Security Update: Dec 11 fixes you need now. For a step‑by‑step rollout, grab our Dec 11 Patch Playbook. And if you’re assessing blast radius and long‑term prevention, our React2Shell Aftershocks: Patch, Prove, Prevent explains how to prove remediation to auditors and avoid repeat incidents. Keeping your Node runtime current also matters—use our Node.js December Security Releases: Your Upgrade Plan to keep the foundation solid.

Field-tested rollout framework you can reuse

Here’s a compact framework we use with teams who ship weekly:

1. Discover: Inventory all apps using App Router and any service bundling react-server-dom-*. Tag owners and business criticality.
2. Decide: Pick the nearest patched line. If you’re already on 15.x or 16.x, don’t backport—move forward.
3. Deliver: Upgrade with a single PR per app. Include lockfile, SBOM, and CI policy checks. Attach the npm ls proof as an artifact.
4. Defend: Rollout in rings (canary → low traffic → full). Gate promotions on synthetic RSC probes and error budget health.
5. Document: Record versions, times, and sign‑offs. If secrets were rotated, capture the rotation IDs and scope.

This is boring by design. Boring is repeatable. Repeatable beats heroic when incidents pile up.

What to do next (today/tomorrow/this week)

Today (Dec 16, 2025):

• Run npx fix-react2shell-next and upgrade to the latest patched Next.js in your line.
• Verify in staging, then ship during a staffed window. Keep a rollback ready.
• If you were online and unpatched during the initial RCE window, rotate critical secrets now.

Tomorrow:

• Add CI guards to block unpatched next or react-server-dom-* versions.
• Turn on request size/time limits at the edge or ingress; add WAF rules for malformed RSC payloads.

This week:

• Formalize your playbook. Save evidence artifacts for audit (versions, logs, probes).
• Schedule a brown‑bag on RSC threat modeling. Move any hardcoded secrets into your secrets manager.
• If you need a partner for a clean, low‑drama rollout, our engineering team can help—we’ve done this across stacks and clouds.

FAQ for execs and stakeholders

Is customer data at risk? With the RCE window, yes—potentially. That’s why we patch promptly and rotate any exposed secrets. For the source exposure bug, only code from Server Functions could leak. Well‑managed secrets (in env/config) weren’t exposed by that path.

Can we defer this? No. The attack surface hits the server and requires no auth. Automatable exploits exist. This is the kind of issue adversaries scan for at scale.

What’s the measurable outcome? Patched dependencies in production, CI guards in place, RSC probes passing, and secrets rotated where required. Expect a short change window and a post‑deployment health review.

Want a second set of eyes? See our contact page to set up a rapid review. Or browse recent projects to see how we roll out high‑confidence changes under pressure.

Final thought

The story arc here is familiar: a critical server‑side bug lands; follow‑on issues shake out; the real work is the disciplined, provable rollout. Treat this Next.js security update as an opportunity to institutionalize better defaults around RSC, logging, and dependency policy. The next variant will come. Your processes—not adrenaline—should carry the day.