Optimizing an image became remote code execution: the critical Next.js alert

What shipped

On August 25, 2026, the Next.js team pulled its monthly security release forward and published versions 16.3.3 and 15.5.24, fixing two critical-severity vulnerabilities. The package sees roughly 45 million weekly downloads — this is not a niche-scale problem.

Flaw 1 — AVIF image optimization. A vulnerability in the libheif library, used underneath sharp, can lead to unauthenticated remote code execution when Next.js optimizes an attacker-controlled AVIF image. Because the real fix depends on upstream propagation, the patched release disables AVIF optimization until then.

Flaw 2 — CVE-2026-75604. A path traversal leading to unauthenticated remote code execution on Windows-hosted Next.js servers, affecting applications using the Pages Router and the App Router without Cache Components.

If you run Next.js in production, today's action is to update. The rest of this piece is about why this will happen again.

Nobody on your team wrote an AVIF decoder

Follow the path of the flaw: you wrote <Image src=... />. Next.js optimizes it. To optimize, it calls sharp. sharp delegates AVIF decoding to libheif. libheif is C code parsing a complex media container format.

Three levels below the line you wrote, a binary parser is reading bytes that came from outside. That is the single most fertile category of remote code execution there is — not because the maintainers of those libraries are careless, but because decoding arbitrary media formats is intrinsically hostile: thousands of fields, sizes declared by the file itself, pointer arithmetic, and an enormous surface.

The uncomfortable conclusion: your attack surface is what your dependencies do, not what you wrote. Auditing your own code will not find this. No code review catches a flaw three node_modules away.

Immediate action, in order

1. Update to 16.3.3 or 15.5.24, depending on your line. That is the fix, not a workaround.
2. If you cannot ship today, disable AVIF optimization and tighten remotePatterns in next.config to domains you control — no wildcards.
3. If you run on Windows, treat it as top priority: the second flaw is specific to that environment and requires no authentication.
4. Run an inventory, not just a patch. npm ls sharp and npm ls libheif show where else this entered the project — there is often a second copy pulled in by another dependency.

The pattern that solves the next one, not just this one

Bumping the version closes this door. The architectural work is reducing what happens when the next one opens:

• Never optimize images from arbitrary origins. If a user can point the URL, they choose the bytes your parser will eat. An allowlist of domains is the cheapest defense available.
• Move media processing out of the server process. Separate container, unprivileged user, no internal network access, memory limit and timeout. If the parser falls, it falls alone and does not take your credentials with it.
• Prefer a CDN or a dedicated service for resizing and converting images. You trade responsibility for a vendor contract — and that vendor patches before you do.
• Watch what your web server is allowed to do. A rendering process should not be able to open sockets anywhere or read outside the application directory. When that is true, RCE becomes a contained incident rather than a full compromise.

The part that stings

This is not a Next.js problem. It is a problem with any modern stack: you import capability and you import, along with it, the attack surface of everything that capability uses internally.

The question separating a prepared team from a lucky one is not "do my dependencies have vulnerabilities?" — they all do, all the time. It is "when one of them is exploited, what exactly can the attacker reach from there?" Teams that can answer that update calmly. Teams that cannot find out on the worst possible day.