The Critical Next.js Security Patch You Shouldn't Skip

This Next.js security patch is not a routine bump. On 25 August 2026 the team shipped an emergency cross-LTS release, 16.3.3 and 15.5.24, after finding a second critical bug in an upstream dependency and pulling the date forward. Both are unauthenticated remote code execution. If you self-host, patch today.

What the patch actually closes

Two critical-severity issues, both leading to unauthenticated RCE.

The first is in the Image Optimization API. A flaw in the libheif library that sharp uses can lead to remote code execution when Next.js optimizes an attacker-controlled AVIF image (GHSA-2xp9-vwfh-vxw4). The patched releases disable AVIF optimization outright until the upstream fix lands. You did not have to choose AVIF for this to matter. If your optimizer will accept and decode an AVIF someone else supplies, you are in scope.

The second is a Windows-specific path traversal (CVE-2026-75604). Apps using both the Pages Router and the App Router without Cache Components can hit RCE when the server runs on a Windows filesystem. Linux and macOS are not affected, and Vercel notes there is no known workaround for affected Windows hosts other than upgrading.

How to audit your own app for the same class

Patching is step one. The more useful exercise is checking whether your app hands untrusted bytes to a native decoder, because that is the bug class here.

Start with your image surface. Anything that pipes remote or user-supplied images through the optimizer is a candidate:

# Where does next/image point at external hosts?
grep -rn "remotePatterns\|domains" next.config.*

If remotePatterns is wide open, the optimizer will fetch and decode whatever a URL resolves to. Narrow it to hosts you actually serve. Treat the optimizer as code that runs a C image library on input you do not control, because that is exactly what it is.

Then check your hosting. If you deploy to Windows, the second bug is live until you upgrade, full stop. Confirm the runtime:

node -e "console.log(process.platform)"  # 'win32' means audit now

Middleware will not save you from either of these. People reach for middleware as a security boundary, but the image optimizer and the static route resolution both run outside the request paths most middleware guards. Middleware is good for auth and redirects. It is the wrong tool for blocking a decoder exploit, and treating it as a shield here gives false comfort.

The pattern worth internalising

Both bugs come from the same shape: a framework feature quietly shells out to native code that parses a hostile file format. That is not unique to Next.js. Any framework that optimizes images, parses uploads, or generates thumbnails is one bad upstream libheif, libwebp, or ImageMagick away from the same headline.

So the durable takeaway is not “patch Next.js”, though you should. It is: know every place your app feeds untrusted input to a native library, keep those libraries on a fast patch cadence, and stop pretending middleware is a wall. Upgrade to 16.3.3 or 15.5.24, then go find the next decoder you forgot you were running.