- The Mess: Vercel patched two critical unauthenticated remote code execution vulnerabilities in Next.js. One abuses AVIF image processing through the
libheifdependency, while the other is a Windows-specific path traversal flaw tracked as CVE-2026-75604. - The Damage: A vulnerable Next.js server can potentially be pushed from a normal web request to arbitrary code execution without an attacker having an account or requiring user interaction. The Windows vulnerability already has a public proof of concept.
- The Fix: Upgrade to Next.js 16.3.3 or 15.5.24 immediately and audit deployments for AVIF optimization and Windows filesystem usage.
Next.js just got the kind of security release developers don’t want to see on a Friday afternoon.
Two critical vulnerabilities.
Two different attack paths.
Both capable of ending in remote code execution without authentication.
And one of them already has a working public PoC.
The patched versions are Next.js 16.3.3 and 15.5.24. Vercel accelerated the August security release after the second critical issue was identified in an upstream dependency.
The Windows Bug Is CVE-2026-75604
The first vulnerability is CVE-2026-75604, rated CVSS 9.0 Critical.
It is a path traversal vulnerability.
But calling it “just path traversal” would be a mistake.
The affected applications use both the Pages Router and App Router, do not use Cache Components, and run on a server using a Windows filesystem.
Under those conditions, an attacker can abuse the filesystem cache handling to escape the intended directory boundaries.
That can become much more than arbitrary file access.
It can become code execution.
The official advisory confirms that the vulnerability requires no privileges and no user interaction. The attack is performed remotely, although the attack complexity is rated high.
And there is another problem.
The PoC Is Already Public
A public proof-of-concept for CVE-2026-75604 is already available.
The PoC targets vulnerable Windows-hosted Next.js applications and demonstrates the conditions required to reach remote command execution. It has been validated against a vulnerable Next.js 16.x installation.
That changes the situation.
A vulnerability disclosure gives defenders information.
A public PoC gives everyone else a much more useful starting point.
Security teams can reproduce the issue.
Researchers can test detection.
Attackers can do the same.
The important limitation is that this isn’t a generic “every Next.js installation is instantly vulnerable” situation.
The deployment needs the specific Windows filesystem and router configuration described by the advisory.
Linux and macOS deployments are not affected by this particular vulnerability.
But if the application matches the vulnerable configuration, Vercel says there is no known workaround.
The answer is simple:
Patch.
The Second Bug Comes Through AVIF
The other vulnerability is even nastier on paper.
It carries a CVSS 4.0 score of 9.5 and affects the Next.js Image Optimization API when AVIF images are processed.
And this one is interesting because the vulnerable code isn’t actually in Next.js itself.
The chain looks like this:
Next.js uses sharp.
sharp uses libheif for HEIF/AVIF processing.
A vulnerability in libheif can trigger a heap buffer overflow when a malicious AVIF file is decoded.
Next.js then inherits the problem through its image optimization pipeline.
That makes this a classic dependency problem.
The framework doesn’t need to contain the vulnerable code to become part of the attack surface.
One Malicious Image Can Be Enough
Image processing is usually treated as harmless infrastructure.
Upload an image.
Resize it.
Convert it.
Return the optimized version.
Done.
Except image decoders are complicated native software.
They parse hostile binary formats.
They allocate memory.
They process compression structures.
They handle malformed input.
And when that code runs on the server, an image upload is no longer just a file upload.
It becomes input to native code.
The Next.js advisory rates the AVIF issue Critical with a 9.5 CVSS score and states that exploitation can result in remote code execution when AVIF files are optimized.
There is one important distinction.
AVIF optimization isn’t necessarily enabled in every application.
The exposure depends on whether the application is actually configured to use AVIF optimization.
So this isn’t a reason to assume every Next.js deployment is equally exposed.
It is a reason to check the configuration instead of guessing.
Vercel Already Disabled AVIF Optimization
The response from Vercel was aggressive.
Until the upstream fix propagates, AVIF optimization has been disabled in the patched releases.
That is a sensible move.
If a dependency can turn attacker-controlled image data into server-side code execution, temporarily removing the dangerous processing path is better than pretending a partial mitigation is enough.
The upstream dependency is libheif.
That is where the underlying memory corruption lives.
Next.js is the application framework sitting on top of it.
This distinction matters when defenders investigate their software inventory.
Searching only for “Next.js vulnerability” isn’t enough.
Teams should also know which image-processing libraries their applications actually load.
Which Next.js Versions Are Vulnerable?
The affected ranges are broad.
For the Windows RCE, the vulnerable versions are:
>= 13.4 < 15.5.24
and
>= 16.0 < 16.3.3
The patched versions are:
15.5.24
and
16.3.3.
The AVIF issue affects:
>= 10.0.0 < 15.5.24
and
< 16.3.3.
So upgrading only because you’re running Next.js 16 isn’t enough.
A deployment sitting on an older 15.x release can still be vulnerable.
So can an older supported-looking application that nobody has touched for months.
That’s exactly the kind of forgotten deployment attackers like.
This Is a Supply-Chain Problem Too
The AVIF vulnerability is a useful reminder that application security doesn’t stop at the top-level package.
Your application might be:
Next.js.
Next.js might depend on:
sharp.
sharp might depend on:
libheif.
The vulnerable memory operation might happen several layers below the package your developers think they installed.
That’s normal in modern software.
It’s also why dependency inventories matter.
A vulnerability in a native codec can suddenly become a remote-code-execution problem in a web framework.
No malicious JavaScript required.
No compromised npm account required.
No administrator password required.
Just a server processing data it was designed to accept.
What Administrators Should Check
First, check the actual installed Next.js version.
Not the version written in documentation.
Not the version in the development branch.
The version running in production.
Then check whether the application is hosted on Windows.
If it is, determine whether it uses both Pages Router and App Router without Cache Components.
That is the configuration that matters for CVE-2026-75604.
Then check image configuration.
Look for AVIF support and the Image Optimization API.
If the application processes attacker-controlled AVIF files, the second vulnerability deserves immediate attention.
Finally, check your deployment pipeline.
A patched package sitting in package.json means nothing if production is still running an older lockfile or an old container image.
Security patches have to reach the machine actually serving requests.
What About Vercel-Hosted Applications?
There is some good news for applications hosted directly on Vercel.
Vercel stated that applications hosted on its platform are protected from these vulnerabilities and don’t require manual upgrading for this specific incident.
That does not mean developers should ignore the advisory.
Self-hosted deployments are different.
Docker images are different.
Windows servers are different.
Private infrastructure is different.
A Next.js application that happens to use Vercel during development but gets deployed to a Windows server in production has a completely different risk profile.
Know where the application actually runs.
The Real Problem Is the Gap Between “Patched” and “Running Patched”
This is where another security release becomes another security release.
Developers see:
next@16.3.3
in the changelog.
Operations sees:
“We’ll deploy it with the next release.”
Security sees:
“Critical RCE.”
Attackers see:
“Public PoC.”
Those four perspectives don’t move at the same speed.
The vulnerable Windows flaw already has public exploitation code.
That means defenders don’t have the luxury of waiting for some theoretical future attack.
The technical recipe is already circulating.
And the AVIF vulnerability shows another uncomfortable truth: even if your operating system isn’t Windows, you can still have exposure through the image-processing stack.
Bugstoday Opinion
Two critical RCE vulnerabilities in one Next.js security release would already be enough to justify an emergency patch cycle.
The public PoC makes the Windows issue considerably more uncomfortable.
And the AVIF bug is a different kind of warning.
The dangerous code doesn’t always live in the framework.
Sometimes it lives three dependencies down.
Sometimes it’s an image decoder.
Sometimes it’s a cache implementation.
Sometimes it’s a tiny piece of native code nobody on the application team has ever looked at.
That’s the reality of modern web stacks.
The application may be written in TypeScript.
The attack may end inside native C code.
Bugstoday verdict: if you’re running a vulnerable Next.js release, stop treating this as routine dependency maintenance. Patch it. Then verify what actually changed in production.
Because “fixed in Git” isn’t a security control.
Running the fixed version is.
Today’s Bugs. Tomorrow’s Breaches.
