Next.js Security Update (October 2026): CVE-2026-96889, the use cache RCE, and How to Fix Your App Step by Step

The October 2026 Next.js security update fixes three vulnerabilities: two critical unauthenticated remote code execution flaws (GHSA-673q-mjm6-r5xr in use cache functions, and CVE-2026-96889 in image optimization of SVG files through sharp) and a high-severity denial of service in Server Actions. The fix is to upgrade next to 16.4.1 or 15.5.28, make sure sharp is 0.35.5, then rebuild and redeploy. Whether your app was actually exploitable depends on three things: your Next.js version, whether you process untrusted SVGs, and whether you use Server Actions. This guide checks all three, in order.

I'm Kunal Vohra, a security researcher and cybersecurity advisor with an M.Tech in Cybersecurity, and this site runs on Next.js. So I didn't just read the advisories; I ran this exact checklist on kunalvohra.com this week. It was on Next.js 15.1.11, inside two of the three affected ranges. I'll show what I found and what I changed as we go.

What the October 2026 Next.js vulnerabilities are

Vercel published the fixes on 14 October 2026 as an out-of-band release, outside the normal release cycle. Two of the three issues score 9.5 on CVSS v4.0, and neither needs the attacker to log in.

1. Remote code execution in use cache functions (GHSA-673q-mjm6-r5xr), critical. Affects Next.js 16.0.0 through 16.4.0 apps using the App Router with Cache Components, where a use cache function returns more than one typed array. React calls the exact pattern rare, but the advisory says there is no workaround and recommends upgrading even if you have no such function. The matching React packages (react-server-dom-webpack, -parcel, -turbopack) are fixed in 19.0.9, 19.1.10, 19.2.9 and 19.3.1.

2. Remote code execution in image optimization (CVE-2026-96889, GHSA-2464-fhr4-w9xw), critical. A memory bug in librsvg, the SVG library used underneath sharp, can be triggered when an attacker-supplied SVG is processed on glibc-based Linux. It affects Next.js 10.0.0 through 15.5.27 and 16.0.0 through 16.4.0. Next.js does not optimize SVGs by default, so the image optimizer is exposed only if you turned on dangerouslyAllowSVG. next/og running on the Node.js runtime also renders SVG through sharp, so an ImageResponse that draws untrusted input is a second route in.

3. Denial of service in Server Actions (GHSA-p3m5-59mp-jv5r), high. Crafted requests can pin one server process at full CPU and block everything else it serves. Affects Next.js 13.0.0 through 15.5.27 and 16.0.0 through 16.4.0, but only App Router apps with at least one Server Action. There is no workaround.

Fixed in: Next.js 16.4.1 (which ships sharp 0.35.5) and 15.5.28 (which still needs sharp 0.35.5 forced; see step 4). Singapore's Cyber Security Agency issued an alert on 20 October telling teams to patch immediately. As of mid-October no exploitation had been reported, but the details are public now, and that window closes fast.

The line I'd put in front of any engineering team this week: "npm audit is clean" did not mean "patched" for this release. Two of the three advisories launched without CVE IDs and didn't show up in the npm advisory feed at first, and the sharp fix can be silently held back by your lockfile.

Is your Next.js app affected? A five-minute check

Answer three questions. If every answer is "no", you were not exploitable, though you should still upgrade, because the next bug won't ask permission.

What version is actually installed? Run this in the project, not your memory of package.json:

npm ls next sharp

Anything below 15.5.28 on the 15 line, or 16.0.0 to 16.4.0, is in range for at least one issue. On 14.x and older there is no patched release in that line at all.

Do you process SVGs from anyone but yourself? Search your config and code:

grep -rn "dangerouslyAllowSVG" next.config.*
grep -rln "next/og\|ImageResponse" app src 2>/dev/null

If dangerouslyAllowSVG is on, or an ImageResponse on the Node.js runtime draws user-supplied images or text, you are in scope for CVE-2026-96889 on glibc Linux (most Ubuntu and Debian servers and the default node Docker images; Alpine uses musl and is outside the stated scope).

Do you use Server Actions or use cache?

grep -rln "use server" app src 2>/dev/null
grep -rln "use cache" app src 2>/dev/null

Any Server Action on an affected version means the denial of service applies. Any use cache on 16.0 to 16.4 means upgrade now, full stop.

What I found on this site: Next.js 15.1.11 and sharp 0.33.5, so in range for both the image RCE and the Server Actions DoS. But dangerouslyAllowSVG was off, the Open Graph images only draw my own post titles and JPEG, PNG or GIF covers, and there are no Server Actions. So neither was reachable. One thing did bother me: the image config allowed remote images from any host, which meant anyone could push files from anywhere through my server's image optimizer. Default SVG blocking stopped this bug, but that's one setting between you and the next one.

How to fix the Next.js vulnerabilities, step by step

Seven steps. Do them on a branch, test locally, then deploy.

Step 1: Pick your target version

• On 16.x: upgrade to 16.4.1.
• On 15.x: upgrade to 15.5.28, the patched release on the 15 line. If you are on an early 15 release (I was on 15.1), this is a bigger jump than it sounds, so plan a proper test pass.
• On 14.x or older: there is no patched release in your line. Pin sharp to 0.35.5 now (step 4) and plan the move to 15.5.28 or 16.4.1. If you can't move soon, make sure nothing processes untrusted SVGs and that you have no Server Actions exposed.

Step 2: Upgrade next and its companions

npm install next@15.5.28 eslint-config-next@15.5.28
# or, on the 16 line:
npm install next@16.4.1 eslint-config-next@16.4.1

Keep eslint-config-next on the same version as next. If you use React Server Components outside Next.js, upgrade the react-server-dom-* package instead.

Step 3: Read the upgrade notes for the versions you skipped

On a minor-version jump, check the Next.js release notes between your version and the target for deprecations in config, caching defaults and middleware. Then run your type check:

npx tsc --noEmit

Step 4: Force sharp to 0.35.5 (the step most 15.x apps miss)

sharp 0.35.5 is the only sharp release with the librsvg fix. Next.js 15 accepts older sharp versions, so an existing lockfile can keep a vulnerable sharp even after you upgrade next. Other packages that depend on sharp (favicon generators, image tools) can pull in their own copy too. Force one version for the whole tree with an override in package.json:

{
  "dependencies": {
    "sharp": "0.35.5"
  },
  "overrides": {
    "sharp": "0.35.5"
  }
}

With pnpm, use pnpm.overrides; with Yarn, resolutions. Then reinstall and check that only one sharp is left:

npm install
npm ls sharp

Every line should say 0.35.5. sharp 0.35.5 needs Node.js 20.9 or newer, so check the Node version on your server, not just your laptop.

If you can't upgrade today, the interim mitigation from the write-ups is to update sharp alone, or to block the SVG loader in your own sharp usage:

import sharp from "sharp";
sharp.block({ operation: ["VipsForeignLoadSvg"] });

That only covers code paths that use your sharp instance. Upgrading Next.js is still the fix.

Step 5: Tighten what your image optimizer will fetch

This isn't in the advisory, but it's the change I'd make to every Next.js app this week. Replace wildcard remote patterns with the hosts you actually use:

// next.config.ts
images: {
  remotePatterns: [
    { protocol: "https", hostname: "images.unsplash.com" },
  ],
},

Leave dangerouslyAllowSVG off unless you truly need it, and if you do, only for SVGs you host yourself. On this site, after narrowing the list, a request for an image from any other host gets a 400 instead of being fetched and processed.

Step 6: Build, test, and check the running version

npm run build
npm run start

Click through the pages that use images, Open Graph cards, forms and anything with Server Actions. Then confirm the server is actually running the new build. If you deploy with Docker, rebuild the image from the updated lockfile (npm ci installs exactly what the lockfile says), and if you run PM2 or systemd, restart the process after deploying. On Vercel and Netlify, redeploy; Netlify also suggests deleting old deploy previews and branch deploys, which can stay vulnerable until they expire.

Step 7: Check whether anyone got there first

No exploitation was reported in the first week, so this is a precaution rather than an emergency, unless you had dangerouslyAllowSVG on or user-supplied images in next/og. In that case:

• Look in your access logs for requests to /_next/image with SVG URLs, especially from hosts you don't recognise, and for bursts of worker crashes or restarts.
• For Server Actions, look for CPU spikes with a single request type behind them.
• If anything looks wrong, rotate the secrets the Node.js process could read (environment variables, API keys, database URLs) and redeploy from a clean build.

What I changed on kunalvohra.com

For transparency, here is exactly what the fix looked like on a real production Next.js site this week:

1. next 15.1.11 to 15.5.28, eslint-config-next to match.
2. sharp pinned to 0.35.5 as a direct dependency and an override. Before the override, a favicon generator in the dev dependencies would have kept its own older sharp.
3. Image remote patterns narrowed from any host to images.unsplash.com, the only remote host the site serves through the optimizer.
4. Type check, full production build and a local smoke test (home page, blog posts, About, and a blocked image request from an unlisted host returning 400) before deploying.

Total time, including reading the advisories: under two hours. The longest part was confirming which conditions applied, which is why the five-minute check above comes first.

What this release should change in how you run a Next.js app

The patch is routine. The lessons are about process.

Don't treat npm audit as your only signal. Two of these advisories launched without CVEs and missed the npm feed at first. Subscribe to the Next.js and React security advisories on GitHub directly.

Know your transitive dependencies. The image RCE wasn't in Next.js code at all; it was in librsvg, two layers down, under sharp. Your lockfile is part of your attack surface.

Keep the framework within a minor version or two of current. Teams on 15.5 had a patch-version bump. Teams on 15.1 had a minor-version jump with release notes to read. Teams on 14 had no patch at all. Being far behind turns a one-hour fix into a migration project during an incident.

Allow-list by default. Wildcard image hosts, open CORS and broad Server Action surfaces are fine until the day a bug lands in the code behind them. This sits in my startup security checklist, and it's the kind of thing a technically literate investor asks about in technical due diligence. The same week also brought a critical PHP runtime bug; my PHP2Shell fix guide covers that one.

If nobody on your team owns this, it doesn't need a full-time CTO at $180,000 to $260,000 a year. A technical advisor retainer ($750 a month for 15+ hours, held through December 2026) covers a dependency and exposure review like the one above. If you need someone to own security, architecture and the team, that's a fractional CTO engagement ($2,500 a month for 50+ hours on the same terms); the fractional CTO cost guide shows market rates beside mine.

Frequently asked questions

What is CVE-2026-96889? A critical (CVSS v4.0 9.5) unauthenticated remote code execution flaw in Next.js image optimization, caused by a memory bug in librsvg used through sharp when processing SVG files on glibc-based Linux. It affects Next.js 10.0.0 through 15.5.27 and 16.0.0 through 16.4.0, and is fixed in 15.5.28 and 16.4.1 with sharp 0.35.5.

Which Next.js versions fix the October 2026 vulnerabilities? Next.js 16.4.1 and 15.5.28. On 15.5.28 you also need sharp 0.35.5, which you may have to force with an override. There is no patched release for 14.x or older.

Is my Next.js app vulnerable if I don't use SVGs? Not to CVE-2026-96889 through the image optimizer, which blocks SVGs unless dangerouslyAllowSVG is on. Check next/og image routes that render user-supplied content, and still check Server Actions (denial of service) and, on 16.x, use cache (RCE). Upgrade either way.

Does npm audit detect these Next.js vulnerabilities? Not reliably at first. Two of the three advisories launched without CVE IDs and weren't in the npm advisory feed. Check versions directly with npm ls next sharp and compare them to the fixed versions.

Are Vercel and Netlify apps affected? The use cache RCE affects any host if your app meets the conditions. Netlify says its image CDN doesn't use the vulnerable optimizer path and rates the other two as minimal impact on its platform; self-hosted apps on glibc Linux carry the most risk. Either way, upgrade and redeploy, including old previews.

Is there a workaround if I can't upgrade? For the image flaw, update sharp to 0.35.5 or block its SVG loader. For the use cache RCE and the Server Actions denial of service, there is no workaround; upgrading is the only fix.

If you're running Next.js and aren't sure what your app exposes, book a 30-minute call. Bring your package.json and next.config, and I'll tell you what applies, what to upgrade first, and what to lock down while you're there. Or get in touch if you'd rather write first.

Sources

• GHSA-673q-mjm6-r5xr: unauthenticated RCE in use cache functions (GitHub, vercel/next.js)
• Critical Vulnerabilities in Next.js, AL-2026-148 (Cyber Security Agency of Singapore)
• Next.js and React security release, October 2026 (Netlify)
• Next.js ships out-of-band patch for two critical RCE flaws (The Hacker News)
• Next.js 16.4.1 and 15.5.28 fix two unauthenticated RCEs (HOL)