Blog / 01

Next.js 16.3.3 / 15.5.24 Fix Two Critical RCEs

WebRestart

On August 25, 2026 Vercel shipped 15.5.24 and 16.3.3, seventeen minutes apart, to fix two Critical unauthenticated remote code execution vulnerabilities. Both carry CVSS scores of 9.0 or higher. One of them has no workaround at all. If you are on any Next.js release older than these two, upgrade before you finish reading this.

Unlike the July batch, neither of these is a middleware or Server Action bug. One lives in a native image decoder, the other in Windows path handling. The mitigations you may already have in place for previous advisories do nothing for either.

Critical #1: AVIF decoding in the Image Optimization API

GHSA-2xp9-vwfh-vxw4 scores 9.5 on CVSS 4.0 and has no CVE assigned. The affected range is extraordinarily wide — >= 10.0.0 < 15.5.24 and >= 16.0.0 < 16.3.3.

The bug is not in Next.js. It is in libheif, which sharp uses, which the Next.js image optimizer uses. GHSA-g89c-p67h-r497 describes a heap buffer overflow in scale_nearest_neighbor(): a crafted HEIF/AVIF file using nested iden and auxl item references produces an image with duplicate alpha planes at differing bit depths. The scaler then allocates an 8-bit alpha buffer, casts it to uint16_t*, and writes 16-bit samples into 1-byte allocations. libheif rates it 9.8 and fixed it in 1.23.2; everything up to and including 1.23.1 is vulnerable.

The detail worth internalising: this is the decode path, not the output format. Reading Vercel's fix commit makes that explicit — AVIF was added to the optimizer's BYPASS_TYPES list alongside SVG and ICO, and VipsForeignLoadHeif was removed from sharp's allowed operations. In other words, you do not need images.formats to include image/avif to be in scope. If an AVIF file can reach your optimizer as a source image — a remote URL matched by images.remotePatterns, a user upload, a static import — the vulnerable decoder runs.

The fix is a behaviour change, not just a patch

Because the upstream sharp and libheif chain had not landed everywhere, Vercel's fix disables AVIF optimization outright rather than patching it. After upgrading, three things change:

  • AVIF requests are passed through unoptimized and still return Content-Type: image/avif. No resizing, no format conversion.
  • AVIF is gone from VALID_BLUR_EXT, so statically imported AVIF images fall back to placeholder="empty" unless you supply your own blurDataURL.
  • The upstream test was renamed from "should resize avif" to "should bypass optimization for avif input", which is a fair summary of the new contract.

If your image pipeline leans on AVIF for payload savings, budget for a regression in transfer size and a visual change wherever blur placeholders were doing work. That is the cost of the patch, and it is worth paying.

Critical #2: path traversal on Windows-hosted servers

CVE-2026-75604, CVSS 9.0, classified CWE-22. It affects >= 13.4 < 15.5.24 and >= 16.0 < 16.3.3, and it requires a specific combination: an application using both the Pages Router and the App Router, without Cache Components, running on a Windows filesystem.

The corresponding commit — "Fix ISR misses with backslashes in segments when deployed on Windows" — points at the mechanism. Windows treats the backslash as a path separator where POSIX does not, so route segments carrying backslashes escape the intended directory during ISR path resolution.

The advisory is blunt about remediation: "There is no known workaround for affected windows-hosted applications. You should upgrade immediately if your server is hosted on Windows." Linux and macOS hosts are not affected by this one. Credit to @evolutionstorm and @B0RI for the report.

What to upgrade to

# 16.x line
npm install next@16.3.3

# 15.5 line
npm install next@15.5.24

Note that 16.3.3 is a patch on the 16.3 line, stable since August 3, so upgrading within 16.3 is a low-risk move. If you are still on 16.2.x you are also missing the nine CVEs fixed in July; go to 16.3.3 directly rather than chasing 16.2 patches.

Two follow-ups are worth doing while you are in the dependency tree. First, check whether sharp is resolving to a build with libheif ≥ 1.23.2 — the Next.js fix removes the exposure, but anything else in your stack that decodes user-supplied AVIF or HEIF through libheif still needs the upstream version. Second, if you self-host on Windows, this is the second consecutive quarter where self-hosted deployments carried risk that managed platforms absorbed upstream. That asymmetry is worth factoring into your hosting decision rather than re-discovering it at each advisory.

Primary sources: the Next.js security advisories on GitHub, the libheif advisory, and the v16.3.3 and v15.5.24 release tags.

Self-hosting Next.js and unsure whether the AVIF bypass will hurt your image budget, or whether your Windows deployment is in scope? Get in touch — we audit and upgrade Next.js applications for a living.

All posts