Next.js August 2026 Security Release: An Image Codec Became an RCE

Next.js published its August 2026 security release today, a day earlier than planned. It fixes two critical, unauthenticated remote code execution bugs. One goes through sharp and the libheif library when Next.js optimizes an attacker-controlled AVIF image. The other hits apps on a Windows filesystem that mix the Pages Router and the App Router. The fixed versions are 16.3.3 (Active LTS) and 15.5.24 (Maintenance LTS). If you run Next.js, patch this week, and do not wait on the image bug.

What was fixed#

• AVIF through libheif (GHSA-2xp9-vwfh-vxw4, upstream GHSA-g89c-p67h-r497). A flaw in libheif, which sharp relies on, can lead to RCE when an attacker-controlled AVIF image is optimized. The GitHub advisory gives it a CVSS v4 score of 9.5 and lists everything from 10.0.0 up to the patched versions as vulnerable. The patched releases do not fix libheif. They disable AVIF optimization until an upstream fix propagates.
• Windows-hosted servers (CVE-2026-75604 / GHSA-p293-qw3h-jr36). Apps using both the Pages Router and the App Router without Cache Components can be exploited when the server runs on a Windows filesystem. Linux and macOS are not affected, and there is no known workaround.

npm install [email protected]   # 16.3 line
npm install [email protected]  # 15.5 line

A codec several layers down#

Nobody on a typical Next.js team picked libheif. They picked Next.js, Next.js picked sharp for image optimization, and sharp relies on libheif. A bug in a native image library becomes an unauthenticated RCE in your web framework, through an image endpoint most teams never list as attack surface.

What I take from it:

• Your package.json is not your attack surface. The native code inside your dependencies is. This time the advisory is filed against next itself, so dependency alerts have something to match. The next one may sit in a bundled binary nobody on the team has heard of.
• Any path that parses untrusted files deserves its own threat model: image optimization, PDF rendering, document previews, avatar uploads.
• The useful question is not "do we use AVIF?" but "can anyone outside our team put an image in front of the optimizer?" Check images.remotePatterns, and check whether user uploads can become optimizer sources.

One trap to avoid. The images.formats option controls the output format, and the image docs list its default as ['image/webp']. But the dangerous step is decoding an AVIF source, not producing AVIF output: the 16.3.x fix commit blocks sharp's HEIF loader and makes AVIF inputs bypass the optimizer. So do not assume you are safe because you never opted into AVIF output. Patch instead of reasoning your way out of it.

Turning a feature off is a real fix#

The Next.js team did not wait for a libheif fix to flow through sharp into a framework release. They switched AVIF optimization off. That is the right call, and worth copying in your own playbook: when the vulnerable code lives in someone else's release cycle, removing the path that reaches it beats waiting.

In that commit, an AVIF source image requested through the optimizer comes back as the original file: same bytes, no resizing, still AVIF. Static AVIF imports that ask for placeholder="blur" fall back to an empty placeholder. Your formats setting is not what got turned off. If users upload AVIF files or you pull AVIF from remote hosts, expect full-size files where you used to get resized ones, and look at those pages in staging before someone files a performance ticket.

Scheduled releases, and why the date moved#

On August 20, Next.js posted advance notice under the scheduled security release process it announced in July: one critical vulnerability, with 16.3.3 and 15.5.24 due on August 26. Today the release moved up after the team found an additional critical issue in an upstream dependency.

I like the scheduled model. A known date lets a lead book a patch window, warn whoever is on call, and get the deploy pipeline green before the advisory goes public. But the date is a planning target, not a contract. Read it as "no later than" and be ready early.

The Windows bug is a migration trap#

The second bug needs a specific combination: both routers, no Cache Components, a Windows filesystem. That sounds narrow until you ask who runs both routers: usually a team partway through an incremental Pages-to-App Router migration. If that describes an app you own, there is no workaround. Patch it, or move it to a Linux host.

What I'm doing about it#

The Next.js apps I self-host run on a Linux VPS behind nginx and systemd, so the Windows bug does not reach them. The AVIF one is the one I am treating as urgent. For any team, the list is short:

1. Inventory every Next.js app and its version. Run npm ls next in each repo, including the ones nobody has touched in months.
2. Upgrade to 16.3.3 or 15.5.24. The advisory lists patched versions only on those two lines, so anything older needs an upgrade plan, not a patch bump.
3. Find every Windows-hosted Next.js server and check whether it mixes routers.
4. Review what feeds the image optimizer: remote hosts, user uploads, anything you do not control.
5. After the upgrade, check pages that serve AVIF sources in staging.