Next.js August Release: Two Unauthenticated RCEs

Two critical, unauthenticated remote code execution bugs, patched in the same release, reachable through completely different code paths. One needs a Windows filesystem. The other needs nothing but a site that turned on AVIF images. Next.js shipped fixes for both on August 25.

What shipped, and why a day early

Vercel had already pre-announced an August security release for August 26. Then a second critical issue turned up during that window, and the team folded it into the same patch rather than shipping twice. Next.js 16.3.3 (Active LTS) and 15.5.24 (Maintenance LTS) went out August 25 with fixes for both.

This is the second time in four months a Next.js release has needed this kind of urgency. A 13-CVE emergency release in May pushed Vercel to announce a formal monthly security program, and the first scheduled release under that program shipped in July with nine advisories. August’s release is smaller in count, two issues instead of nine, but both are critical severity and both are unauthenticated RCE, which is a worse combination than a pile of moderate-severity fixes.

The AVIF bug: libheif, not Next.js’s own code

GHSA-2xp9-vwfh-vxw4 sits in libheif, a dependency pulled in through sharp for image decoding, not in code Vercel wrote. The underlying flaw, disclosed by libheif’s own maintainers as GHSA-g89c-p67h-r497, is a heap buffer overflow with a CVSS v4 score of 9.5.

The mechanics are specific enough to be worth walking through, because they explain why the exposure is narrower than the CVSS score suggests. A crafted AVIF file can contain nested identity-derivation and auxiliary item references that cause libheif to build a decoded image with two Alpha plane entries at different bit depths. The scaler allocates a destination buffer sized for the first entry, which is 8-bit, then writes 16-bit sample values from the second entry into that same buffer. That overwrites roughly 16,384 bytes past the allocation boundary. It’s the classic shape of a memory-corruption bug: a size assumption made once, at allocation time, that a later code path silently invalidates.

Here’s the part that matters for triage: Next.js only routes images through AVIF optimization when a project has explicitly opted in.

// next.config.js
module.exports = {
  images: {
    formats: ["image/avif", "image/webp"], // this line is what exposes you
  },
};

If your next.config.js doesn’t list image/avif in images.formats, the vulnerable path was never reachable through Image Optimization, regardless of which Next.js version you’re running. Grep your config before you decide how urgently to move. If it’s there, this was reachable by anyone who could get Next.js to optimize an image they controlled, which for most sites means anyone on the public internet, and you should patch now rather than on your normal cadence.

The patched releases disable AVIF optimization outright until the fix propagates upstream through libheif and sharp. That’s a real, if temporary, feature regression for sites that depend on serving AVIF: your images will fall back to whatever other format is configured. It’s the right tradeoff. A missing image format is an inconvenience; unauthenticated RCE is not.

Affected range: Next.js 10.0.0 through 15.5.23, and all 16.x releases through 16.3.2. That’s most of the framework’s shipping history.

The Windows bug: path traversal into RCE, no workaround

CVE-2026-75604 is a different animal. It’s a path traversal, CWE-22, with a CVSS score of 9.0, and it only affects Windows-hosted deployments. The vulnerability requires an application to be using both Pages Router and App Router simultaneously, without Cache Components enabled, on a server whose filesystem is Windows.

CWE-22 bugs happen when an application builds a file path from attacker-controlled input and fails to fully restrict special path elements like ../. Combined with how Windows and POSIX filesystems handle path separators and reserved characters differently, that class of bug shows up disproportionately on Windows precisely because the traversal primitives that work there don’t always work identically elsewhere. That’s the whole reason this is a Windows-only advisory: the same request pattern that reaches arbitrary files on a Windows filesystem doesn’t necessarily reach them on Linux or macOS, where Vercel’s own infrastructure runs. If you deploy on Vercel, or on any Linux or macOS host, this specific issue does not apply to you.

If you’re running Next.js on Windows Server or IIS, the calculus is different, and there is no workaround. Vercel’s advisory doesn’t offer a config flag or a middleware pattern that closes this short of upgrading. A public proof-of-concept already exists, which is the detail that should move this from “patch this sprint” to “patch today” for anyone in the affected configuration.

Affected range: Next.js 13.4 through 15.5.23, and 16.0 through 16.3.2.

Who actually needs to move fast

Your situation	Urgency
AVIF enabled in next.config.js, any host	High: patch now
Windows-hosted, Pages + App Router mixed, no Cache Components	High: patch today, no workaround exists
Windows-hosted, App Router only with Cache Components	Lower: still upgrade, but the mixed-router precondition doesn’t apply
Vercel, Linux, or macOS, AVIF never enabled	Lower: upgrade on your normal cycle

Almost every real deployment falls into at least one row worth acting on, which is the point of walking through both bugs instead of just saying “upgrade.” A generic “critical CVE, patch immediately” alert doesn’t tell you whether you’re in the blast radius. Checking your image config and your host OS takes two minutes and tells you exactly how urgent this is for your specific app.

The upgrade

# Active LTS line
npm install next@16.3.3

# Maintenance LTS line
npm install next@15.5.24

Both are drop-in patch releases; the AVIF format regression is the only behavior change, and it only affects sites that had AVIF explicitly turned on. There’s no migration step beyond bumping the dependency and redeploying.

The pattern worth noticing

Two of the last three Next.js security releases have needed to move faster than their own announced schedule. That’s not evidence the monthly program is failing. It’s what a young disclosure and patch cadence looks like while it’s still absorbing the backlog of issues that accumulated before anyone was looking systematically. What it does mean practically: don’t treat “scheduled security release” as synonymous with “low urgency.” Read the advisory, check whether your config and host match the affected precondition, and patch on the timeline the specific bug earns, not the timeline its calendar slot implies.

If your team is still deciding how to structure that triage step into a release process, that’s the same discipline we walk through when we help clients set up ongoing maintenance and support contracts after launch, rather than leaving security patching as a thing that happens whenever someone notices the CVE.