Critical Next.js RCE (CVE-2026-75604 + AVIF): upgrade now

Short answer: On August 25, 2026, Vercel disclosed two critical, unauthenticated remote code execution flaws in Next.js. CVE-2026-75604 (GHSA-p293-qw3h-jr36, CVSS 9.0) is a path traversal that gives RCE on Windows-hosted servers running both the Pages Router and App Router without Cache Components. GHSA-2xp9-vwfh-vxw4 (CVSS v4 9.5) is a heap overflow in libheif, reached through sharp, that gives RCE when the Image Optimization API processes an attacker-supplied AVIF file. Both are fixed in next@15.5.24 and next@16.3.3. Vercel-hosted apps are already protected; everyone self-hosting should upgrade now.

This post is a defensive checklist for teams that ship Next.js: which versions are affected, how to tell in five minutes whether you are exposed, what to do if you cannot upgrade today, and where a registry firewall fits in. Facts below are taken from the Next.js August 2026 security release, the two GitHub advisories, and the upstream libheif advisory. No exploitation in the wild had been reported as of August 27, 2026, but a public proof-of-concept exists for the libheif bug, so treat this as time-sensitive.

What was disclosed in the Next.js August 2026 security release?

Vercel runs a monthly security release cadence for Next.js. The August release was scheduled for August 26 but was pulled forward one day after the team found an additional critical bug in an upstream dependency. Two advisories shipped together:

Two details matter for triage. First, the Windows bug has no workaround; the only fix is upgrading. Second, the AVIF fix in Next.js is a mitigation, not a root-cause fix: the patched releases simply stop optimizing AVIF input until libheif ships a corrected version. As of August 27, every libheif release through v1.23.1 is affected and v1.23.2 had not been published.

How does the Windows path traversal (CVE-2026-75604) work?

Vercel has not published exploit details, which is normal for a critical bug days after disclosure. What the advisory does state is precise about preconditions. You are affected only if all of these are true:

• Your app uses both the Pages Router (pages/) and the App Router (app/). Pure App Router or pure Pages Router apps are not in scope.
• You are not using Cache Components (cacheComponents: true in next.config).
• The Next.js server runs on a Windows filesystem. Linux and macOS hosts are not affected.

The CVSS vector is Network / no privileges / no user interaction / scope changed, with high impact on confidentiality, integrity and availability. "Attack complexity: High" is the only thing keeping the score below 9.8, and you should not rely on that. Windows hosting is less common for Next.js in production, but it is very common for internal tools, IIS-fronted corporate apps, Azure App Service on Windows plans, and developer machines that expose a dev server on a shared network.

How does the AVIF image optimization RCE work?

Next.js optimizes images through sharp, which links the C library libheif to decode AVIF and HEIF. The libheif advisory describes a chain of four individually harmless behaviors: a crafted file with nested identity-derivation (iden) and auxiliary (auxl) item references causes the decoder to attach two Alpha planes at different bit depths, the scaler allocates a buffer for the 8-bit plane, then writes 16-bit samples from the second plane into it. The result is a heap overflow of roughly 16 KB with attacker-controlled contents. The researchers (credited as rootxharsh and KarimPwnz on the libheif side, and the Hacktron team in Vercel's changelog) state they achieved RCE against multiple applications and released a Python proof-of-concept alongside the disclosure.

For Next.js the exposure condition is narrower than the version range suggests. The Image Optimization endpoint (/_next/image) only hands AVIF to sharp when your config opts in:

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'], // AVIF opted in here
  },
}

If images.formats does not include 'image/avif', the vulnerable path is not reachable through Next.js. Note two caveats: any code that calls sharp directly on untrusted AVIF or HEIF input (upload pipelines, thumbnailers, CMS integrations) is exposed to the same libheif bug regardless of your Next.js config, and Next.js versions before 15 do not bundle sharp but will use it if it is installed.

How do I check if my project is exposed?

1. Check where you host. If the app is deployed on Vercel, you are protected and need no action; Vercel disabled AVIF optimization across its managed image service and its runtime is Linux. If you self-host, note the OS: Windows Server, IIS, Azure App Service (Windows), or Windows containers put you in scope for CVE-2026-75604.
2. Check for the router combination. Do both pages/ and app/ directories exist, and is cacheComponents unset or false? If yes and you are on Windows, you are exposed with no mitigation other than upgrading.
3. Check for direct sharp usage. grep -rn "from 'sharp'\|require('sharp')" --include=*.ts --include=*.js . and review whether any of those call sites accept user-uploaded HEIF or AVIF.
4. Run a dependency scan. The free InstallSafe scan reads your lockfile and lists every next and sharp version in the tree, including nested copies pulled in by monorepo packages or templates that pin an older Next.js.

Check for AVIF opt-in. Grep your config:

grep -rn "image/avif" next.config.*

A match means the Image Optimization endpoint will pass attacker-controlled AVIF to libheif.

Find your installed version. In each Next.js project run:

npm ls next
# or check the resolved version in package-lock.json / pnpm-lock.yaml / yarn.lock

Anything from 10.0.0 up to 15.5.23, or 16.0.0 up to 16.3.2, is in the AVIF range. Anything from 13.4 up to 15.5.23, or 16.0 up to 16.3.2, is in the Windows range. If you patched in July (16.2.11 / 15.5.21), you still need this update.

What is the fix?

Upgrade. The patched releases were published to npm on August 25, 2026 (16.3.3 at 15:32 UTC, 15.5.24 at 16:14 UTC):

npm install next@15.5.24   # Maintenance LTS, 15.x line
npm install next@16.3.3    # Active LTS, 16.x line

Then rebuild and redeploy. Confirm with npm ls next that no other copy of an older version remains in the tree. If you are on an end-of-life line (13.x, 14.x), there is no backport; plan the jump to 15.5.24.

If you cannot upgrade today

• AVIF bug: remove 'image/avif' from images.formats (WebP is the default and is unaffected), or set images.unoptimized: true to bypass the optimizer entirely. Redeploy. This closes the Next.js path but not direct sharp usage.
• Windows bug: there is no configuration workaround. The only alternatives to upgrading are moving the runtime to a Linux container, or removing one of the two routers so the vulnerable combination no longer exists. In practice, upgrading is faster than either.
• Reduce blast radius: run the Node process as a low-privilege user, keep the app behind a WAF that can block /_next/image requests with AVIF url parameters, and review access logs for unusual requests to /_next/image since August 25.

How does a registry firewall help with an advisory like this?

A vulnerability advisory is a different problem from a compromised package, and it is worth being honest about which parts a registry firewall solves.

What it does not do: nothing at the install boundary fixes code that is already deployed. Upgrading is still on you. And an advisory-driven firewall is only as current as its advisory feed. InstallSafe blocks on OSV.dev data; as of the afternoon of August 27, neither GHSA had been ingested into OSV yet, so no OSV-backed tool, ours included, was blocking these versions at that moment. We will not claim otherwise.

What it does do, and why it matters here:

• It stops the regression. The most common way a patched vulnerability comes back is a fresh npm install somewhere that resolves an old range: a stale template, a monorepo package pinned to 15.5.21, a CI job with a cached lockfile, or an AI coding agent that "fixes" a build by downgrading. Once the advisory lands in OSV, a firewall at the registry (npm config set registry https://r.installsafe.io) refuses to serve next@15.5.23 or next@16.3.2 to any client, human or agent, in dev or CI.
• It gives you the inventory. Every install flows through one choke point, so "which projects still have a vulnerable next or a direct sharp dependency?" is a query, not a company-wide Slack thread.
• It covers the transitive case. The libheif bug affects anything that pulls in sharp with a vulnerable prebuilt libheif, not only Next.js. When that upstream advisory is published for the npm binaries, the same rule applies without anyone editing a per-repo config.

Tools that do behavioral or static analysis of package contents (Socket, Snyk, Aikido) will not flag this class of bug either; it is a memory-safety issue in a native library, found by fuzzing and manual research, not by looking at install scripts. For vulnerability advisories, speed of ingestion plus an enforced install boundary is what shortens the window.

Timeline

• August 18, 2026: Vercel pre-announces an upcoming security release for August 26.
• August 25, 2026: Release pulled forward after the libheif finding. next@16.3.3 (15:32 UTC) and next@15.5.24 (16:14 UTC) published; both GHSAs and the Vercel changelog go live.
• August 27, 2026: No in-the-wild exploitation reported. libheif v1.23.2 not yet released; AVIF optimization remains disabled in patched Next.js.

If you have not already, run npm ls next across your projects today, and use the free scan to catch the nested copies you forgot about. Related reading: our checklist for the JSONata RCE from last week, and how to stop AI agents from reinstalling vulnerable packages.

FAQ

Is my Next.js app affected if it is hosted on Vercel?

No action is required. Vercel disabled AVIF optimization in its managed Image Optimization service and its Next.js runtime is Linux, so neither vulnerability is reachable on Vercel-hosted deployments.

Which Next.js versions are affected by CVE-2026-75604?

Versions 13.4 through 15.5.23 and 16.0 through 16.3.2, but only when the server runs on a Windows filesystem and the app uses both the Pages Router and App Router without Cache Components. Fixed in 15.5.24 and 16.3.3.

Am I exposed to the AVIF RCE if I never enabled AVIF?

Not through Next.js. The Image Optimization API only sends AVIF to sharp when images.formats includes 'image/avif'. You should still upgrade, and still check any code that calls sharp directly on user-uploaded AVIF or HEIF files, because the underlying libheif bug is unpatched upstream.

Is there a workaround for the Windows RCE?

No. Vercel's advisory states there is no known workaround for Windows-hosted applications. Upgrade to next@15.5.24 or next@16.3.3 immediately.

I installed the July 2026 Next.js security patches. Am I covered?

No. The July release (16.2.11 / 15.5.21) fixed different issues. You need the August release, 16.3.3 or 15.5.24, on top of it.

Will a registry firewall block these vulnerable versions?

Only once the advisories are in its data source. InstallSafe uses OSV.dev, which had not ingested these GHSAs as of August 27, 2026. Once it does, installs of affected next versions are refused at the registry for every developer, CI job and AI agent pointed at it, which prevents the patch from being silently undone.