Next.js August 2026 Security Release: Two RCE Fixes

Next.js has shipped an out-of-band security release patching two critical-severity vulnerabilities, both of which can lead to unauthenticated remote code execution (RCE) on the server. The fixes landed in v16.3.3 on the Active LTS line and v15.5.24 on the Maintenance LTS line, and the framework’s maintainers are urging every self-hosted deployment to update. As of the disclosure on August 27, 2026, no exploitation of either flaw had been reported in the wild — but with tens of millions of weekly downloads, the window between a public patch and opportunistic scanning is short.

The two bugs are unrelated in mechanism but share the worst-case outcome. One lives in image processing and affects a huge span of releases; the other is specific to Next.js servers running on Windows. Both require no authentication.

Bug one: the AVIF image RCE

The more broadly applicable flaw sits in Next.js’s image optimization pipeline. When the framework optimizes an attacker-controlled AVIF image, it hands the file to the sharp library, which in turn relies on libheif to decode the format. A memory-safety defect in libheif — a heap buffer overflow in its AVIF decoding path — means a specially crafted image can trigger code execution on the server doing the optimizing.

The attack surface is exactly what makes this dangerous. Image optimization endpoints are, by design, reachable and fed with external image data; an attacker who can get a malicious AVIF file processed by a vulnerable endpoint may be able to run code without ever authenticating. The advisory (tracked as GHSA-2xp9-vwfh-vxw4) rates the issue at the top of the critical band, with a CVSS score of 9.5.

The affected range is unusually wide: the AVIF flaw touches Next.js versions from 10.0.0 up to the patched 15.5.24 and 16.3.3 builds. Because the root cause is in the upstream libheif library rather than in Next.js itself, the maintainers took a blunt but effective mitigation — the patched releases disable AVIF optimization entirely until a fixed libheif propagates through the dependency chain. Applications that relied on serving optimized AVIF will fall back to other formats until that upstream fix ships.

Bug two: the Windows path traversal RCE

The second vulnerability, CVE-2026-75604 (CVSS 9.0), is narrower in scope but just as severe where it applies. It affects applications that use both the Pages Router and the App Router together without Cache Components, and only when the Next.js server runs on a Windows filesystem. Under those conditions, a path traversal weakness can be leveraged into unauthenticated remote code execution.

The combination of conditions is what limits the blast radius — Linux and container-based deployments, which make up the bulk of production Next.js hosting, are not affected by this particular bug. But mixed-router applications on Windows are common enough in enterprise and intranet settings that the maintainers treated it as critical rather than a footnote. If you self-host Next.js on Windows, this is the one to check first.

What you need to do

The action is the same for both flaws: upgrade. Move to 16.3.3 if you’re on the 16.x Active LTS line, or 15.5.24 if you’re on the 15.x Maintenance LTS line. Because the AVIF fix reaches all the way back to 10.0.0, teams running older major versions should plan an upgrade path rather than assume they’re out of range — a four-year-old release is squarely in scope.

There is an important carve-out for managed hosting. Applications deployed on Vercel and similar managed platforms are, per those providers, protected at the infrastructure layer: their image optimization and routing run through hardened, centrally patched services rather than the raw framework code on each customer’s server. The audience that must act is self-hosted Next.js — teams running the framework on their own servers, containers, or Windows hosts, where the vulnerable code paths execute directly. If you deploy to an edge or serverless platform, confirm with your provider whether the mitigation is applied for you or whether you still own the upgrade.

Why image parsers keep showing up

It is worth noting the pattern: the highest-scoring of the two bugs did not originate in Next.js at all. It came from libheif, a native image-decoding library several dependencies deep, surfaced through sharp, and reached the internet because Next.js exposes an image-optimization endpoint that accepts external files. Media parsers — image, video, and font decoders written in memory-unsafe languages — are a perennial source of RCE precisely because they do complex work on untrusted input, and a single overflow in a transitive dependency can turn a convenience feature into a code-execution surface.

That is a recurring theme across the ecosystem, from framework image pipelines to supply-chain incidents in package registries. The defensive lesson is not new but bears repeating: treat any endpoint that decodes user-supplied media as a high-risk boundary, keep transitive dependencies patched, and be ready to disable a feature — as Next.js did with AVIF — when the fix lives upstream and hasn’t shipped yet. Input validation alone doesn’t help when the parser itself is the vulnerability, which is also why classic web-layer defenses against bugs like cross-site scripting don’t address this class at all.

What it means

For the millions of applications built on Next.js, this is a drop-everything patch for self-hosted deployments and a non-event for most managed ones — a split that neatly illustrates where the security responsibility line falls in modern web hosting. Teams on Vercel-style platforms inherit the fix; teams running their own servers own it.

Who’s exposed: any self-hosted Next.js app that optimizes AVIF images (a range spanning 10.0.0 through the patched builds), plus the narrower set of mixed-router applications self-hosted on Windows. Who’s covered: applications on managed platforms that have applied the mitigation centrally, and deployments that don’t use image optimization at all.

What to watch next. First, whether proof-of-concept exploits for the AVIF flaw appear now that the patch is public — the disclosure window is the dangerous phase, and internet-facing image endpoints are easy to enumerate. Second, when a fixed libheif propagates so that AVIF optimization can be safely re-enabled rather than left disabled. And third, whether this prompts framework teams to sandbox or isolate media-decoding paths more aggressively, given how reliably native image parsers turn into the highest-severity bug in a release. Until the upstream fix lands, the pragmatic move is the one Next.js already made for you: leave AVIF optimization off and revisit it when libheif is patched.