Next.js shipped two critical RCE fixes on 14 October — here is exactly what to patch this week (and why npm audit may stay quiet)

Key takeaways

• On 14 October 2026 Vercel released an out-of-band security update for Next.js: 16.4.1 (Active LTS) and 15.5.28 (Maintenance LTS). It closes two critical, unauthenticated remote-code-execution (RCE) bugs and one high-severity denial-of-service bug (official advisory).
• The RCE in use cache functions (GHSA-673q-mjm6-r5xr) has no workaround. Vercel's advice is to upgrade even if your app has no such function.
• The SVG RCE (CVE-2026-96889) lives in the image pipeline (sharp → librsvg) and only bites on glibc-based Linux — which is most Docker images and VPS servers. Interim fix: sharp 0.35.5 or later.
• Two of the three advisories carry no CVE, so npm audit and Dependabot may not flag them (reported by The Hacker News). Check your version by hand.
• Same week: Node.js has pre-announced HIGH-severity security releases for 22.x, 24.x and 26.x on or after 21 October (nodejs.org). Plan one maintenance window for both.
• No public exploitation was reported as of 15 October — which is the best time to patch, not a reason to wait.

1. What was fixed, in one table

Two details matter more than the scores. First, the use cache and Server Actions bugs are really React Server Components bugs; Vercel links the upstream React advisories (GHSA-xqc2-xf4c-x3h3 and GHSA-h3gv-c5rc-p453). If you run RSC outside Next.js, you need the patched React packages too — Pantheon lists them as 19.0.9, 19.1.10, 19.2.9 or 19.3.1 depending on your line (Pantheon release note). Second, Vercel says two of these fixes were postponed from the September release because of upstream dependency delays — so if you patched in September and felt safe, you were not fully covered.

2. Are you exposed? A five-minute check

Run these in the project root, not from memory:

npm ls next react react-dom sharp          # the actual resolved versions
grep -rn "dangerouslyAllowSVG" next.config.*   # SVG optimisation on?
grep -rn "cacheComponents\|use cache" next.config.* app/ src/ | head  # Cache Components in use?
grep -rln "\"use server\"" app/ src/ | head  # any Server Actions?

Read the results against the table:

• Next.js 16.0.0–16.4.0 → you are in range for all three. Upgrade to 16.4.1 today.
• Next.js 13.0.0–15.5.27 → in range for the SVG RCE (if SVG processing is on) and the Server Actions DoS. Upgrade to 15.5.28.
• Next.js 15.5.28 but npm ls sharp shows 0.34.x → still vulnerable to the SVG bug. The 15.5 line accepts the older sharp; force sharp@^0.35.5 in package.json or overrides. This is the trap most teams will fall into.
• Pages Router only, no Server Actions, no dangerouslyAllowSVG → the DoS and SVG bugs do not apply, but Vercel still asks you to move to a patched version. Do it in the same window.
• Static export (output: 'export') served by Nginx/Hostinger → there is no Node process at request time, so the server-side bugs do not apply in production. Your build machine still runs the image optimizer, so update anyway.

Why npm audit is not enough this time: the caching and Server Actions advisories were published without CVE IDs and, as of 15 October, were not in the npm advisory feed. Tools that only read that feed show a clean report on a vulnerable app.

3. The fix

# 16.x line
npm install next@16.4.1
# 15.x line
npm install next@15.5.28 sharp@^0.35.5
npm ls sharp            # must print 0.35.5 or higher
npm run build && npm test

If you cannot upgrade Next.js this week (frozen release, vendor-managed app), the only partial mitigation is for the SVG bug: install sharp 0.35.5+ or block the SVG loader with sharp.block({ operation: ["VipsForeignLoadSvg"] }). There is no mitigation for the use cache RCE or the Server Actions DoS other than upgrading — a WAF rule is not a substitute, because the payloads are ordinary RSC requests.

Then redeploy. Pantheon's note is worth repeating for every host: the platform does not update your application dependencies for you. A patched package.json sitting in a branch protects nobody.

4. Self-hosted vs Vercel vs static — how the exposure differs

The practical point for Indian teams running on a Hostinger VPS, a Mumbai EC2 instance or a Proxmox VM: a single-process Next.js server is the worst case for the DoS. One crafted request stream and every user sees a hanging page. Run at least two instances behind Nginx or PM2 cluster mode, set a request timeout at the proxy, and alert on CPU > 80% for five minutes — the same alert that catches a crypto-miner catches this.

5. What else lands this week

Our suggestion: do not open three maintenance windows. Patch Next.js and sharp now (the RCEs are public), hold a second window on 22–23 October for Node.js once the versions are published, and bundle Windows updates for build machines into the same evening.

6. The India angle: cost of patching vs cost of not

A Next.js minor-version bump on a mid-sized app — pull, install, build, smoke test, redeploy — is typically 1–3 engineer-hours. At common Indian contractor rates of ₹800–2,000/hour that is ₹2,000–6,000, and most of it is waiting on CI. An unauthenticated RCE on a server that holds customer PII costs more in a single afternoon: forensic rebuild, credential rotation, and the regulatory clock. CERT-In's 2022 directions require covered entities to report cyber incidents within six hours of noticing them, and the DPDP Act adds breach-notification duties to the Data Protection Board and affected users. Nobody has ever been fined for upgrading next too quickly.

Two local specifics. Many Indian agencies ship client sites as Next.js on shared Hostinger plans using static export — those are fine in production, but the agency's own build server is not. And a lot of founder-run SaaS is on Vercel's hobby or pro tiers billed in USD; the DoS bug turns an attack into an invoice, so patch before someone finds your Server Action.

7. Checklist for Monday morning

1. npm ls next sharp on every repo that ships to production — write the versions down.
2. Upgrade to 16.4.1 or 15.5.28 + sharp ≥ 0.35.5; build; deploy; verify the version in the running container.
3. Grep for dangerouslyAllowSVG. If it is on and you do not need it, turn it off; the attack surface is not worth a logo.
4. Add a version-pin check to CI so next below the patched floor fails the build — npm audit will not do this for you.
5. Subscribe to the low-volume nodejs-sec list and book the 22–23 October window for Node.js.
6. If an MSP reaches your servers through a remote-support appliance, ask them in writing today which version they run.

Patching is boring until the week it is not. We run version-floor checks, patch windows and 24×7 alerting for client servers under Managed IT services — and you can test your public hostnames for free with our Uptime & SSL check.