Next.js 16 ImageResponse RCE: Patch to 16.3.6 Now

Next.js published an out-of-band security update on September 22, 2026 for a critical next/og flaw. The affected range is Next.js 16.2.0 through 16.3.5, and the patched release is 16.3.6. GitHub gives CVE-2026-94545 a 9.5 out of 10 CVSS v4 score.

You should patch even though not every Next.js app is exploitable. The vulnerable path needs three things at once: an affected Next.js version, the Node.js ImageResponse implementation, and attacker-controlled data passed into SVG content, attributes, or styles. Check those conditions first, then upgrade, rebuild, redeploy, and verify the version running in production.

Next.js ImageResponse RCE is CVE-2026-94545, a remote code execution path in the Node.js implementation of ImageResponse from next/og. It affects Next.js versions at or above 16.2.0 and below 16.3.6 when untrusted values reach generated SVG markup.

Is your Next.js ImageResponse route affected?

Do not stop at the version in package.json. A range such as ^16.2.0 can resolve differently across lockfiles and environments. Check the installed dependency in the exact build context used for production:

npm ls next
npm ls satori

Then search the application for imports and file conventions that create social images:

rg "ImageResponse|next/og" app src pages
rg "opengraph-image|twitter-image" app src pages

The Next.js advisory says exploitation requires attacker-controlled values in SVG content, attributes, or styles during image generation. Query parameters, route parameters, database fields, user profiles, uploaded metadata, and remote API responses all deserve tracing if they reach ImageResponse.

Table: Scope stated by the Next.js security update and GitHub advisory.

Attacker-controlled input is any value an outside user can influence before it reaches generated SVG, even if that value came through your database or another API rather than directly from the current request.

The distinction matters because generated Open Graph images often combine trusted layout code with untrusted names, titles, search terms, or filenames. The route can look static while one text node or style value still comes from a request.

How to patch the Next.js ImageResponse RCE

The official security update gives the direct fix for the affected major line:

npm install next@16.3.6
npm ls next
npm run build

Commit the package manifest and lockfile together. If your deployment installs with a frozen lockfile, changing only package.json may leave the build broken or preserve an older resolved package. If you build a container, create a new image rather than restarting an old one.

Next, deploy the new artifact. The Next.js deployment documentation separates the build and start stages for a Node.js server, so a local dependency update does not alter an existing production process. Static exports have limited feature support and do not run server-only image generation, but verify the deployed architecture instead of assuming the project stayed static.

After deployment, request every affected Open Graph or social-image route with ordinary values and edge-case values already accepted by the product. Confirm that the route returns an image and that logs show no rendering error. Then inspect the production build or deployment metadata to establish that it contains Next.js 16.3.6 or later.

A complete patch changes the resolved dependency, produces a fresh build, replaces the running artifact, and verifies the deployed version. Editing a manifest completes only the first part.

What if you cannot deploy 16.3.6 today?

The Next.js advisory gives one temporary workaround: do not pass attacker-controlled values into SVG content, attributes, or styles rendered by Node.js ImageResponse. Replace those values with fixed content, remove the dynamic image route, or route image generation away from the Node.js implementation until the patched build is live.

Do not treat escaping code as a complete permanent fix. The related Satori advisory says no complete workaround exists besides upgrading. Satori versions from 0.0.27 up to, but not including, 0.33.5 are affected by improper escaping; 0.33.5 is patched.

The upstream issue is rated 5.3 out of 10, while its Next.js execution path is rated 9.5 out of 10. The difference is a useful warning: dependency severity cannot be read without the way your framework consumes its output.

How should you review the route after patching?

The patch closes the disclosed flaw. You should still reduce unnecessary input paths because dynamic image routes process data at request time.

1. List every ImageResponse call and identify its runtime.
2. Trace each value used inside SVG content, attributes, and styles back to its source.
3. Record whether the source is fixed, authenticated, or open to anyone on the internet.
4. Add tests for the input shapes the route intentionally supports.
5. Verify generated images and deployment logs after the patched build goes live.

The ImageResponse reference says the API uses @vercel/og, Satori, and Resvg to convert HTML and CSS into PNG. It also documents a maximum bundle size of 500KB and default dimensions of 1200 by 630 pixels. Those are operational constraints, not protections against unsafe input.

If this review exposes old framework work beyond the image route, use the Next.js 15 end-of-life checklist to separate the security patch from the larger migration. HeyDev handles broader repairs and production automation through its automation service, but the urgent step here is narrower: get the affected deployment onto 16.3.6.

What we did not test

We did not reproduce CVE-2026-94545, run exploit code, or measure the effect of a particular hosting provider's firewall. We also did not test whether an application-specific sanitizer blocks every crafted value.

This article applies the scope and remediation published by Next.js and the two GitHub advisories. It does not claim that a version match proves exploitation, that an Edge route is vulnerable, or that removing one query parameter finds every attacker-controlled value.