Next.js Security Update Dec 11: Patch Map + Proof Plan

The December 11 Next.js security update lands on the heels of the React2Shell scramble and closes two newly disclosed React Server Components issues. If your app uses the App Router, this Next.js security update is not optional—and rolling it out cleanly requires both a precise version target and a quick CI fix because npm classic tokens were revoked two days earlier. (nextjs.org)

Here’s the thing: the React2Shell remote code execution (CVE‑2025‑55182) from December 3 is still fixed with the prior patches. The new issues are a High‑severity Denial of Service (DoS) and a Medium‑severity Source Code Exposure in RSC. Neither of these two allows RCE, but both are exploitable via a crafted HTTP request, and they touch real production risk—availability and confidentiality. (react.dev)

What changed in the Next.js security update?

On December 11, Next.js published an advisory that downstreams two React fixes into specific Next.js release lines. The advisory also notes an addendum: the initial fix for one vulnerability (CVE‑2025‑55184) was incomplete and was superseded by a complete fix (CVE‑2025‑67779). If you patched early on December 11, you likely need to bump again to the latest patched versions below. (nextjs.org)

The two new vulnerabilities are:

• CVE‑2025‑55184 (High): a request that, when deserialized by the RSC protocol, can trigger an infinite loop and hang the server (DoS).
• CVE‑2025‑55183 (Medium): a request that can cause a Server Function to return the compiled source of other Server Functions; secrets hard‑coded in code may be revealed if your bundler inlines them. (react.dev)

Affected Next.js versions (App Router) and fixed versions called out by the team:

• 14.x: upgrade to 14.2.35
• 15.0.x: upgrade to 15.0.7
• 15.1.x: upgrade to 15.1.11
• 15.2.x: upgrade to 15.2.8
• 15.3.x: upgrade to 15.3.8
• 15.4.x: upgrade to 15.4.10
• 15.5.x: upgrade to 15.5.9
• 16.0.x: upgrade to 16.0.10
• Canary lines: 15.6.0‑canary.60 and 16.1.0‑canary.19 or later

Pages Router apps aren’t affected by these two issues, but if you’re on a mixed app or plan to adopt RSC, upgrade to the patched release anyway to avoid surprises. (nextjs.org)

Are you actually affected?

If you’re on the App Router (src/app) or you use Server Actions/Server Functions (the "use server" directive), assume you’re in scope. Even if you don’t explicitly expose a custom endpoint, the RSC protocol is present and can be probed. That was the lesson from React2Shell: the protocol surface exists even when it’s not obvious. (react.dev)

A quick triage routine I use on audits:

• Identify RSC usage: git grep -n "\"use server\"\|\'use server\' and inventory the hit list (these are Server Functions).
• Confirm router: look for app/ directory and server components in your routes.
• Check bundler inlining risk: if you’ve got secrets literally in code (don’t), assume they could be exposed by CVE‑2025‑55183 on unpatched builds depending on bundler behavior. The React team explicitly warns that only hard‑coded secrets are at risk; env‑based secrets read at runtime are not exposed by this bug. (react.dev)

The patching plan you can ship today

Let’s get practical—this is the sequence we’re recommending to client teams this week:

1) Freeze deploys for 30–60 minutes and notify stakeholders. Treat this as a security hotfix release.
2) Upgrade in place within your current release line to the exact patched target (see matrix above). Example commands:
npm i [email protected] [email protected] [email protected] --save-exact
pnpm up [email protected] [email protected] [email protected] --latest
yarn add [email protected] [email protected] [email protected] --exact
Double‑check that your React packages also land on patched versions to preserve the upstream fixes. (nextjs.org)

3) Rebuild and redeploy with cache busting. In Vercel, trigger a production redeploy; in containerized setups, rebuild the image so the runtime actually contains the patched bits.

4) Smoke test the RSC endpoints. Hit a couple of Server Actions (form submissions, dashboard actions) and confirm no regressions.

5) Backport to all maintained branches. Don’t leave a trailing long‑term branch behind; these issues are request‑triggered and easily scanned for.

6) Document the change (ticket + commit messages) so auditors see the upgrade trail for December 2025.

Proving you’re safe: a repeatable verification checklist

Security reviewers will ask, “How do you know the fix is effective?” Use this simple, repeatable evidence plan:

1) Show versions in production

Capture the exact Next.js and React versions in your deployed artifact. For Docker, run npm ls next react react-dom inside the container and attach the output to your change ticket. The acceptable versions are 14.2.35 (14.x), 15.0.7/15.1.11/15.2.8/15.3.8/15.4.10/15.5.9 (15.x), or 16.0.10 (16.x), with React at a patched 19.2.x line. (nextjs.org)

2) Negative test for Source Code Exposure

Before patching, a crafted request could extract compiled code for a Server Function. After patching, attempts to stringify functions should be blocked. The React team shipped this hardening on December 11; keep a red/green test that asserts your function endpoints don’t return function source. (react.dev)

3) Availability test for DoS

Run a synthetic that opens a request against a known Server Action endpoint with a malformed RSC payload and asserts response within a timeout. You’re checking that the server doesn’t hang. The Next.js advisory describes the incomplete initial fix and the corrected CVE; ensure your test runs against the final patched build. (nextjs.org)

4) Secrets posture review

Search for hard‑coded secrets: git grep -n -E "(SECRET|API_KEY|TOKEN|PASSWORD)\s*=\s*['\"]". If you find any in Server Functions, rotate them. React’s note is clear: runtime env secrets aren’t exposed by this bug, but literal values in code could leak on unpatched builds. (react.dev)

What about React2Shell—are attackers still poking at RSC?

React2Shell (CVE‑2025‑55182) was disclosed on December 3 as a CVSS 10 pre‑auth RCE via the RSC protocol. Patches exist in React 19.2.1 and coordinated framework updates landed promptly. Several outlets reported exploitation attempts and state‑linked activity soon after disclosure, which is why many teams put RSC behind extra filters last week. If you’ve patched React to 19.2.1+ and upgraded Next.js per this article, the original RCE path remains closed. (react.dev)

Timeline you can share with leadership:
• Nov 29: Vulnerability reported to React team.
• Dec 3: React discloses CVE‑2025‑55182 and ships fixes.
• Dec 11: Follow‑up CVEs (55183, 55184; later corrected to 67779 for a complete DoS fix) disclosed; Next.js publishes downstream versions. (react.dev)

But there’s a catch: your CI might fail mid‑patch

On December 9, npm permanently revoked classic tokens, introduced 2‑hour session tokens for npm login, and shipped CLI support for creating and managing granular access tokens. If your pipeline still relies on classic tokens, your builds may have started failing just as you’re trying to roll out the Next.js fix. Move CI to granular access tokens or, if you’re on GitHub/GitLab, adopt OIDC trusted publishing. (github.com)

If you need a deeper walkthrough (with examples for GitHub Actions, GitLab, and CircleCI), we wrote up what to change and how to rotate credentials in npm Classic Tokens Revoked: Fix Your CI Now.

People also ask

Does this affect the Pages Router?

No—these December 11 CVEs target the RSC protocol used by the App Router and Server Functions. Pages Router apps aren’t affected, though the Next.js team still recommends updating to a patched release so you’re ready when you adopt RSC. (nextjs.org)

If we’re on 15.5.9, do we still need 16.0.10?

Not necessarily. You need to be on a fixed version for your release line. 15.5.9 is patched for these CVEs; 16.0.10 is the patched target for the 16.x line. Choose the latest in your current line and backport across supported branches. (nextjs.org)

Can a WAF mitigate this without upgrading?

It’s risky to rely only on network filters because the RSC protocol is legitimate app traffic and the exploit shape can vary. If you must buy time, rate‑limit and isolate RSC endpoints and aggressively throttle abnormal request sizes, but ship the upgrade as the primary control. This aligns with the React/Next guidance: patch first, then layer mitigations. (react.dev)

A pragmatic test harness to drop into CI

Use this lightweight harness to keep you honest during future upgrades:

• Build step: assert package versions using npm ls and fail if Next.js/React drift below patched ranges.
• API probe: call a known Server Action endpoint with an intentionally malformed RSC payload and expect a fast error (not a hang).
• Source leak check: send a probe that previously returned function source in staging; assert it now returns a sanitized error or structured response.
• Secrets check: run a secrets scanner on Server Functions; fail on detecting literal credentials in code.

Bundle these as a separate job so your team sees green lights tied to specific CVEs (55183, 55184/67779). This is the quickest way to prove the negative: “we tested the exploit paths and the app held up.” (react.dev)

Executive brief for non‑technical leaders

• What happened: After a critical RCE in React’s RSC (Dec 3), two additional non‑RCE bugs were found and fixed on Dec 11; Next.js shipped specific patched versions per release line.
• Business risk: Unpatched, attackers can hang servers (DoS) or read compiled server function code, potentially exposing hard‑coded secrets. No customer action is required beyond updating our app.
• Our plan: Upgrade to the patched Next.js version in our line, confirm React 19.2.x is present, run synthetic tests for DoS and source leak, rotate any exposed secrets, and document the change. (react.dev)

What to do next (developers)

• Today: Upgrade Next.js and React to the patched versions for your line; rebuild and redeploy.
• This week: Add the CI harness above, rotate any secrets found in code, and ensure your error monitoring samples RSC endpoints.
• This month: Review RSC surface area (what truly needs to be a Server Function?) and reduce exposure by moving non‑sensitive work to edge/client where appropriate. (nextjs.org)

What to do next (platform & security)

• Fix CI auth: Replace classic npm tokens with granular tokens or OIDC; add short‑lived credentials by default. Our CI playbook covers the mechanics.
• Patch windows: Bundle this with your December maintenance; if you haven’t processed Microsoft’s December updates yet, coordinate to minimize downtime overlap. See our Patch Tuesday playbook for sequencing. (github.com)

Zooming out: the RSC learning curve

RSC brings real developer ergonomics, but it also introduces a protocol surface that’s new to many teams. It’s normal to see variant CVEs appear in the weeks after a critical disclosure as researchers comb related code paths. That happened here: React2Shell (RCE) was followed by DoS and source exposure variants, which were then patched again when the first DoS fix proved incomplete. Expect the ecosystem to harden quickly—and expect more test cases to land in public scanners. (react.dev)

Where to go deeper

We’ve been shipping same‑day guides as this story evolved. If you need a template for board reporting or a two‑week engineering plan, these will help:

• React2Shell: Your 14‑Day Patch and Proof Plan
• React2Shell Week Two: Patch RCE, Fix New RSC CVEs
• Next.js Security Update (Dec 11): Fixes, Risks, Plan
If your team needs hands‑on help with triage, testing, or secure migration, our security and engineering services team can jump in this week.

Final take

Patch now, prove it with tests, and clean up any hard‑coded secrets while you’re in the code. The Next.js security update is straightforward once you target the correct fixed version for your line. The only real snag we’re seeing is CI auth breaking after npm’s token changes—solve that once with OIDC or granular tokens and keep the pipeline boring again. Then get back to shipping features, with an RSC test harness watching the door. (nextjs.org)