The Next.js security update dropped into an already tense month: React’s RSC protocol saw a critical RCE (CVE‑2025‑55182, widely called React2Shell) on December 3, then two follow‑ups on December 11 (CVE‑2025‑55183 source code exposure and CVE‑2025‑55184 DoS, with a complete DoS fix later tracked as CVE‑2025‑67779). If you ship with the App Router, this is not a “we’ll get to it Friday” situation. Below is a field‑tested patch order, the exact versions to land, and a short list of artifacts to collect so you can prove you’re safe without grinding production to a halt.
What changed in the Next.js security update on December 11?
After the React2Shell RCE fix, researchers found two more issues in the RSC protocol. The December 11 Next.js advisory confirms:
• DoS: CVE‑2025‑55184, superseded by CVE‑2025‑67779, could hang your server processes via a crafted request.
• Source code exposure: CVE‑2025‑55183 could cause a Server Function to return compiled source of other Server Functions. If you hard‑coded secrets in code (don’t), they may be exposed.
These hit App Router apps. Pages Router apps aren’t directly affected by these two, but you should still upgrade to the patched line so your base stack is aligned with the ecosystem fixes and future mitigations.
Patched Next.js versions to know (choose your line):
• 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
• Canary lines are also patched (15.6.0‑canary.60 and 16.1.0‑canary.19 as of Dec 11).
There’s also a one‑liner helper: npx fix-react2shell-next, which checks and bumps you deterministically to the recommended versions.
Quick timeline: how we got here
• December 3, 2025: React discloses CVE‑2025‑55182 (CVSS 10.0) affecting react-server-dom-* packages (RSC) in versions 19.0, 19.1.0, 19.1.1, 19.2.0, and publishes fixes (19.0.1, 19.1.2, 19.2.1). Next.js posts its advisory for App Router users, including a secrets rotation note if you were online and unpatched as of December 4, 1:00 PM PT.
• December 5, 2025: Exploitation is observed in the wild; initial payloads skew toward cryptominers, with some RATs and persistence techniques reported.
• December 11, 2025: Two more RSC issues disclosed (DoS and code exposure). Next.js releases the follow‑up bulletin and a consolidated patch matrix. The DoS fix requires the later CVE‑2025‑67779 completion.
• December 15, 2025: Defender researchers detail exploitation patterns, including targeting of cloud metadata endpoints and secret discovery tooling post‑compromise.
What’s actually vulnerable right now?
If your application supports React Server Components, you were exposed to the original RCE unless you upgraded the affected packages to 19.0.1, 19.1.2, or 19.2.1, and you were running a patched framework (for Next.js, see the version list above). The DoS and code exposure issues require the December 11+ framework fixes. Default configurations were enough to be at risk, which is why this spike matters even for teams that weren’t experimenting with custom Server Function plumbing.
Frameworks and tooling the React team called out as downstream consumers include Next.js, the Vite RSC plugin, Parcel’s RSC plugin, React Router’s RSC preview, Redwood SDK, and Waku. If any of those are in your pipeline, validate their patched state as well.
Here’s the thing: even if you think “we don’t use Server Functions,” many App Router apps still include RSC machinery via framework defaults. Treat this as an upgrade‑and‑verify event, not a debate about whether you toggled the right feature flag six months ago.
The 48‑Hour Patch‑and‑Prove Plan
This is the shortest, safest route my team uses with clients. Ship the fix, collect evidence, and keep prod healthy.
1) Inventory your exposure (30–60 minutes)
• Identify App Router services first. In monorepos, list Next.js apps and any services running RSC‑aware bundlers or previews.
• On each service, check for RSC packages and framework versions:
npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack next
• Snapshot your lockfile and node_modules/.package-lock.json or pnpm-lock.yaml for evidence. Export a quick SBOM (npx @cyclonedx/cdxgen -o sbom.json) so you can show “before/after” deltas later.
2) Upgrade with deterministic versions (60–90 minutes)
• For Next.js App Router apps, install the patched line for your major: for example, npm i [email protected] or npm i [email protected]. If you’re unsure, run npx fix-react2shell-next for guardrails.
• For custom stacks that wire React RSC directly, bump the affected packages to fixed versions: 19.0.1, 19.1.2, or 19.2.1. Keep React and React DOM aligned per your framework’s guidance.
• Rebuild. If your CI uses caching, clear module caches to avoid stale transitive deps. Verify no lockfile reverts post‑install.
3) Redeploy and verify behavior (90 minutes)
• Smoke tests: exercise key App Router routes and any Server Functions. Watch for regressions in serialization, streaming, and error boundaries.
• Metrics: confirm cold start and steady‑state latency didn’t balloon. DoS fixes should not materially dent throughput; if they do, profile custom middleware for tight loops.
• Logs: Search for anomalous POST requests to RSC endpoints around December 3–15. Save a short timeline export; it becomes part of your patch evidence.
4) Rotate secrets if you were online and unpatched (2–4 hours)
If your app was internet‑exposed and unpatched during the window highlighted by the advisories (notably December 4, 1:00 PM PT), rotate credentials used by the application. Prioritize:
• Cloud metadata‑reachable tokens (AWS/GCP/Azure/Tencent IMDS).
• Database and message queue credentials.
• API keys (OpenAI, Stripe, Twilio, etc.).
• OAuth client secrets and JWT signing keys.
• Any secrets baked into code (fix that practice during rotation).
Use your cloud’s automated key rotation where possible, and document new ARNs/URIs/fingerprints in a change ticket.
5) Prove you’re safe (60 minutes)
Collect these five artifacts and you’ll survive most audits:
• Dependency diff showing patched versions (lockfile delta).
• CI build log with the exact Next.js and RSC package versions.
• SBOM “after” file plus hash of the deployment image or function bundle.
• Log slice showing no suspicious RSC POST patterns post‑patch.
• Secrets rotation record: what rotated, when, by whom.
People also ask
Are Pages Router apps affected?
They weren’t impacted by the App Router‑specific DoS and code exposure issues disclosed on December 11. The RCE tied to RSC was about the server components protocol; if you’re purely Pages Router, you still benefit from being on a patched framework line for consistency and future hardening. In short: lower risk, still update.
Do I need to patch if I don’t use Server Functions?
Yes. The original React post made it clear: even apps that don’t explicitly expose Server Functions may be at risk if they support RSC. The safest posture is to update the affected packages and your framework, then verify.
What versions “fix” React2Shell and the follow‑ups?
For React’s RSC packages, fixed versions are 19.0.1, 19.1.2, and 19.2.1. For Next.js, choose the patched line for your major (e.g., 14.2.35, 15.0.7, 16.0.10). The DoS fix was completed under CVE‑2025‑67779; make sure you’re on or beyond those December 11 recommendations.
Can a WAF replace patching?
No. Several providers rolled out temporary mitigations, but the React and framework teams were explicit: treat mitigations as a seatbelt while you drive to the shop. You still need the patched packages and framework versions. That said, rate‑limit and anomaly detection on RSC endpoints can reduce noise while you patch.
How to keep production stable while you update
• Blue/green or canary deploys: shift 5–10% traffic to patched builds and watch error rates and p50/p95 latency for 10–15 minutes before full cutover.
• Lock your package manager: use --save-exact and a frozen lockfile to avoid surprise minor bumps that make debugging harder during an incident.
• Keep a rollback ready: store the pre‑patch image digest and a health‑checked rollback route in your deploy pipeline.
Evidence your execs will understand
Non‑technical leadership wants two answers: “Are we safe?” and “How do we know?” Give them:
• One‑page memo: versions before/after, date/time patches landed (UTC), and the services affected.
• Attachments: lockfile diff, build log snippet with exact versions, secrets rotation receipt from your vault/cloud KMS, and a 24‑hour log sample showing clean traffic after the cutover.
Detection ideas if you suspect compromise
• Hunt for unusual outbound traffic immediately after suspicious POSTs to RSC endpoints.
• Review system user creation, SSH authorized_keys changes, and installation of RMM tools you didn’t approve.
• Scan for common coin miner processes and persistence, then widen to any bespoke RATs seen in your telemetry. If you find anything, isolate hosts, rotate all credentials, and assume lateral movement attempts.
Strategic takeaways for engineering leaders
1) Treat RSC as server code. It runs close to your data and secrets; gate it with the same standards you use for APIs.
2) Budget for “security sprints.” Incidents like this aren’t hypothetical—and the cost of delay compounds.
3) Prove changes with artifacts. SBOMs and lockfile diffs remove ambiguity when auditors (or customers) ask hard questions.
4) Stop hard‑coding secrets. Environment variables and vault integrations exist for a reason.
What to do next (today and this week)
Today (2–4 hours):
• Run the inventory command, patch to the correct Next.js line, rebuild, redeploy.
• If you were online and unpatched on December 4 at 1:00 PM PT, start secret rotation immediately.
• Export and store your patch evidence (diffs, logs, SBOM, image digests).
This week (1–2 days):
• Add regression tests around Server Functions and App Router routes so future bumps are safer.
• Put a standing playbook on the shelf. If you need one, start with our Node.js patch frameworks here: 48‑Hour Node.js patch plan and the Dec 18 playbook we maintain for release weeks: Node.js Patch Playbook.
• For Next.js‑specific cadence, compare notes with our guide: Next.js Security Update: Patch, Prove, Repeat, and if you’re catching up on the exploit side, read the incident‑safe tips in React2Shell: Secure Next.js This Week.
FAQ for busy teams
Does Pages Router plus API routes need action?
You won’t see the App Router‑specific issues, but you should still align to the patched major/minor and verify no react-server-dom-* packages sit in your tree. Keep audits simple by standardizing on the recommended versions.
Can I skip secret rotation if I saw nothing suspicious?
Risk‑based call, but the guidance after the initial advisory set a clear line: if you were live and unpatched at that timestamp, rotate. Detection gaps are common in web stacks; err on the side of caution.
What about performance after patching?
RSC serialization and DoS hardening shouldn’t materially hurt throughput. If you observe regressions, profile user code and middleware first; the fixes address malformed payload handling, not core render performance.
Zooming out
RSC sits where client requests become server work. That’s powerful—and fragile if you treat it like a view template. The December 2025 cycle wasn’t “business as usual”; it was your reminder to treat framework servers like any other internet‑facing service. Patch quickly, prove it, and keep receipts. If you make that your norm, the next advisory is a routine sprint, not a midnight war room.
If you need a second set of eyes on a tricky deployment or rollback path, our team is happy to help. Start a conversation via Bybowu contacts and we’ll get you a plan that fits your release train.
