Next.js SVG image optimization RCE: check and fix

Next.js out-of-band release: the SVG image RCE and three checks

Node.js · 4 min read · October 22, 2026

If you deploy a Next.js app, check its version today. GitHub advisory GHSA-2464-fhr4-w9xw, rated critical with a CVSS v4 score of 9.5, describes unauthenticated remote code execution in the Image Optimization API when SVG files are used and Next.js runs on glibc-based Linux. No account and no user interaction are needed. The fixed releases are 15.5.28 and 16.4.1. Plenty of PHP and Node freelancers maintain a Next.js front end next to their backend, so this one is worth ten minutes even if Next is not your main stack.

What the advisory says

According to the advisory, a memory-related bug in an upstream library that Next.js uses for image optimization can lead to remote code execution. The affected ranges of the next package are 10.0.0 through 15.5.27 and 16.0.0 through 16.4.0. The workaround, if you cannot upgrade at once, is to make sure the sharp version Next.js uses is 0.35.5 or later; a fresh install gets a fixed sharp, and upgrading Next.js to a patched release makes the package manager pull one in. The advisory references CVE-2026-96889 and credits randomguy6407 and rafabd1.

The pwn.watch tracker adds context I could not check against the other advisories myself. It reports that Vercel shipped 16.4.1 and 15.5.28 on 14 October 2026 as an out-of-band release, that the SVG bug is a use-after-free in librsvg reached through sharp, and that the same release fixed a second critical RCE (GHSA-673q-mjm6-r5xr, App Router apps with Cache Components) and a high-severity Server Actions denial of service (GHSA-p3m5-59mp-jv5r). Out-of-band means the vendor chose not to wait for the regular release schedule. Treat that as a signal about urgency.

The SVG never leaves your process: the parser that reads it runs with the same rights as your app.

Why an image parser can run code

This is general knowledge, not a detail from the advisory. Image processing in Node is usually native code: sharp is a JavaScript layer over C libraries such as libvips and librsvg, and they run inside your Node process. A memory bug there is not contained by JavaScript's safety; it is a bug in your application, with your environment variables and your file system. SVG makes the surface bigger, because it is a document format with a full parser behind it, not a grid of pixels.

The advisory names glibc-based Linux. It does not say other platforms are safe, so if your image is Alpine or anything else, upgrade anyway rather than reasoning your way out of it.

Three checks

npm ls next sharp
grep -n '"version"' node_modules/sharp/package.json
docker exec my-next-app id -u

Run the first two inside the project and the third against the running container, because the lockfile on your laptop and the image in production can disagree. Then fix whatever the checks turn up:

npm install next@16.4.1   # or next@15.5.28 on the 15 line
npm ls sharp              # expect 0.35.5 or later
docker build --pull -t my-next-app .

Two checks close the hole; the third decides how much a future hole like it could reach.

Upgrading next is the fix; checking that sharp is 0.35.5 or later inside the deployed image is how you know the fix arrived.

Two habits, as general practice rather than anything the advisory requires: restrict what the optimizer will fetch with images.remotePatterns in your Next config, so it only processes images from hosts you name, and run the app as a non-root user in its container. Neither replaces the upgrade. Next step: run the three checks on every Next.js app you deploy, including the client project you have not touched since spring.

Source: GitHub Advisory Database, GHSA-2464-fhr4-w9xw.

Notes from readers

No notes yet. The first one is the bravest.