Next.js Security Update: What to Patch Now

The primary keyword here is simple: Next.js security update. A lot changed in the last 10 days. After the December 3 disclosure of a critical React Server Components (RSC) RCE (CVE‑2025‑55182) and the downstream Next.js advisory (CVE‑2025‑66478), the Next.js team pushed a follow‑on security update on December 11 that adds two more RSC fixes—one for denial‑of‑service (DoS) and one for source code exposure—and replaces an initial DoS patch that turned out to be incomplete. If you’re running the App Router on 14.x, 15.x, or 16.x (including canary), this is your patch train.

What changed since December 3?

On December 3, the React team disclosed an unauthenticated RCE in RSC with CVSS 10.0 and shipped fixes in React RSC packages (19.0.1, 19.1.2, 19.2.1). Next.js tracked the impact (CVE‑2025‑66478) and urged upgrades. Threat actors started probing and exploiting quickly, which is what you’d expect for a pre‑auth RCE touching popular frameworks.

On December 11, Next.js published a second advisory covering two additional RSC protocol issues discovered during patch review. Neither of these two is RCE, but both matter operationally:

• DoS vulnerability originally tracked as CVE‑2025‑55184; the initial patch was incomplete and was superseded by a complete fix under CVE‑2025‑67779.
• Source code exposure (CVE‑2025‑55183) where a crafted request could cause a server function to return compiled source for other server functions, potentially leaking logic or inlined secrets.

Pages Router apps aren’t affected by these RSC protocol bugs, but the Next.js team still recommends moving to patched versions. App Router apps are affected and must upgrade. There’s no reliable workaround; you need to install the fixed builds.

Exact versions to install (and why pinning matters)

Here’s the thing: “latest” can roll under your feet. For the December 11 advisory, the Next.js team listed specific patched releases by minor line, and they also pinned canary builds to known‑good versions. If you’re on App Router, land one of these now:

• 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
• 15.x canary: 15.6.0‑canary.60
• 16.0.x: 16.0.10
• 16.x canary: 16.1.0‑canary.19

These builds incorporate the complete DoS fix (CVE‑2025‑67779) and the source code exposure fix (CVE‑2025‑55183), in addition to the original React2Shell RCE patch. Treat them as security releases. Also upgrade your React packages to the fixed RSC versions (19.0.1, 19.1.2, or 19.2.1) if your lockfile hasn’t pulled them in.

The 7‑day Next.js security update plan

You can’t freehand this during an active exploit window. Use a tight, auditable sprint. Here’s a practical framework we’ve run with product teams.

Day 0–1: Inventory and freeze

List every internet‑facing app using Next.js App Router. Freeze deploys and canary upgrades. If you’re on a canary line, plan to move to the pinned canary in the advisory or back to the named stable line—don’t drift.

Quick commands:

# See what's actually installed (npm)
npm ls next react react-dom react-server-dom-webpack

# Pin to the recommended versions for your line
npm install [email protected]   # or your exact line's patched build

# If you're on a 15.x or 16.x canary line, pin to the advisory's canary
npm install [email protected]
npm install [email protected]

# Ensure React RSC packages are patched
npm install react@latest react-dom@latest react-server-dom-webpack@latest

Yarn and pnpm equivalents are fine—just pin explicitly and commit the lockfile. If you see an “unmet peer dep” warning that would drag in a non‑pinned Next.js, fix your range specifiers. Don’t rely on “^”.

Day 1–2: Upgrade with tooling

Run the Next.js team’s interactive helper to check versions and bump deterministically:

npx fix-react2shell-next

It validates your line against the recommended builds and updates package.json and your lockfile. That minimizes “I thought I upgraded” misses that we see during incident response.

Day 2–3: Prove the patch works

Security work without proof becomes rework. Capture artifacts that a security lead—or your customer—can trust:

• A lockfile diff showing the Next.js and React RSC package bumps.
• CI output from npm ls verifying the exact versions above.
• A short SBOM snapshot before/after. Even a basic npm ls --json > sbom.json is better than nothing.
• A change ticket linking the advisory and commit hashes.

If you need a lightweight format for accountable patching, see our guide Next.js CVE‑2025‑66478: Patch, Prove, Harden. It’s designed for busy teams under a clock.

Day 3–4: Regression testing that focuses on RSC pathways

Target the areas these patches touch: server functions, streamed responses under Suspense, and data‑heavy routes. Spin up a preview deployment without CDN caching to catch hangs. Add synthetic checks for “stream never completes” and “request count spikes while throughput drops,” which are telltale DoS side effects.

Day 4–5: Detect the aftermath

Even if you’ve patched, look backward for compromise. Early field signals we keep seeing:

• CPU pegged from unfamiliar Node or worker processes, often respawning quickly.
• Unusual outbound traffic to previously unseen domains or IPs from the app hosts.
• New services, crontabs, or startup scripts that weren’t in infrastructure code.
• Temp directories with recently dropped binaries or shell scripts under the app user.

If you observe any of the above, isolate the node, snapshot disks, and rotate credentials used by server functions. Then follow a structured aftercare routine like React2Shell Aftercare: Verify, Detect, Harden.

Day 5–6: Harden the edges

There’s no substitute for patches, but you can reduce blast radius. Simple, high‑yield moves:

• WAF: add a rule to throttle or block suspicious high‑rate requests to server function endpoints. If your WAF supports shield mode or emergency rulesets, use them while you roll patches.
• Rate limits: protect App Router APIs separately from public asset routes.
• Secrets hygiene: store secrets only in the runtime environment, not embedded in code. The source exposure bug reminded everyone why this line matters.
• Process isolation: run the Next.js server under a least‑privileged user; disable shell execution where you can.

If you operate at the edge, we wrote about shipping protective changes without introducing downtime in Cloudflare Outage: Ship WAF Fixes Without Going Down.

Day 6–7: Automate staying clean

Add weekly SCA checks that pin to your approved version list, not just “latest.” Wire alerts when any app drifts off the patched lines. Bake a simple playbook into your on‑call runbook so engineers can identify App Router services fast and pull the correct patched build without digging through wikis.

Who is affected—and who isn’t?

App Router apps are the primary concern because they use the RSC protocol by design. If your Next.js app still uses the Pages Router and you haven’t adopted RSC or server functions, these specific issues don’t apply directly. That said, dependency graphs are messy in real life; landing the patched Next.js versions across all lines keeps you aligned with the security baseline and avoids future upgrade friction.

React 18 apps without RSC support aren’t affected by the RCE. If you’ve got transitional hybrids (18 in places, 19 in others), treat each deployable independently: update where RSC is present, and still advance Next.js to the patched builds for consistency.

People also ask

Does this Next.js security update change performance or behavior?

In most apps, no material perf regression shows up after the patched builds. Where you might see differences is in edge cases around streaming server responses or error handling for malformed RSC payloads. Run a canary deployment behind a small traffic slice for 15–30 minutes to flush out anomalies before flipping the rest of traffic.

Can I stay on 14.x safely?

Yes—if you’re on 14.2.35. Older 14.x builds won’t include the complete DoS fix that replaced the initial patch. Pin to 14.2.35 and keep your React RSC packages at 19.0.1/19.1.2/19.2.1 accordingly.

Should I downgrade from a canary?

If you’re on a canary line not listed in the advisory’s known‑good versions, yes. Either move to the pinned canary (15.6.0‑canary.60 or 16.1.0‑canary.19) or roll back to the corresponding stable patched release for your minor line. Don’t run arbitrary canaries during a security incident window.

Is there a workaround while we schedule maintenance?

No reliable workaround. You can rate‑limit or block suspicious traffic patterns to reduce risk, but that’s defense‑in‑depth. The only way to close exposure is to install the patched builds.

How to prove you’re no longer exposed

Executives and customers will ask, “Are we safe now?” Have receipts:

• Version proof: a screenshot of npm ls next and npm ls react-server-dom-webpack on the running build image or container.
• Time proof: build IDs with timestamps on or after December 11 for the Next.js security update.
• Scope proof: an inventory list of exposed services with their patched versions.
• Change proof: a commit hash and ticket tying the patch to production deployment.

If you want a fuller process with checklists and evidence templates, grab our 30‑day plan in React Server Components Vulnerability: 30‑Day Plan.

If you see signs of compromise

Stop trying to nurse a live host back to health. Cut it from the pool, snapshot forensics, rebuild from clean images, then rotate any credentials that server functions could touch (database, queues, third‑party APIs). Our rapid triage notes are in React2Shell Aftermath: Verify, Fix, and Harden Now.

Operational guardrails most teams skip

Zooming out, a few habits make these weeks less chaotic:

• Version allowlists: define safe versions for each framework line and alert on drift.
• Lockfile governance: require lockfile diffs in PRs; reject unpinned major/minor bumps in security windows.
• Golden rollbacks: prebuild the last known‑good container image for emergency reverts.
• Runtime egress policies: block app servers from calling arbitrary hosts; allowlist known destinations. It makes exfiltration and C2 attempts obvious.
• Separate CI runners: don’t build on the same hosts that serve traffic.

What to do next

Let’s get practical. If you own a Next.js estate today, here’s your action list:

• Ship the December 11 Next.js security update on every App Router service using the exact versions listed above.
• Verify React RSC package versions are 19.0.1/19.1.2/19.2.1 and commit the lockfile.
• Run npx fix-react2shell-next to eliminate guesswork and drift.
• Backfill detection: scan the last 14 days for anomalous CPU, outbound traffic, and unexpected processes. Rebuild and rotate if anything looks off.
• Tighten edges: WAF throttle on server function routes; rate limits; no secrets in code.
• Codify the playbook so the next advisory takes hours, not days.

If you need an experienced team to stand this up in a hurry, see our security and engineering services, browse relevant work in the portfolio, or just get in touch. We’ve guided multiple orgs through this exact patch‑prove‑harden loop in the last week.