Next.js 16.3.3 shipped on August 25, 2026 with fixes for two critical severity remote code execution bugs, one day earlier than the pre-announced date and with twice the vulnerability count. For a headless commerce storefront the patch itself is a version bump you can do before lunch. The part that costs something is what one of the two fixes switches off, and it lands directly on image weight.
What shipped on August 25
Two critical severity remote code execution vulnerabilities, patched in 16.3.3 on the Active LTS line and 15.5.24 on Maintenance LTS. Vercel's August advisory says the release was pulled forward after a second critical issue turned up in an upstream dependency, which is why the patch version reads 16.3.3 rather than the 16.3.2 named in the August 20 notice.
We covered that notice when it published, working from what it stated at the time: one critical vulnerability, arriving August 26. Both the count and the date moved. That is not a complaint about the process, and the reason it matters comes below.
The AVIF image RCE vs the Windows filesystem RCE
One is a configuration question and the other is an operating system question, so most teams can triage both in under ten minutes. The two share a severity label and very little else.
The first, tracked as GHSA-2xp9-vwfh-vxw4, sits in the Image Optimization API. When Next.js optimizes an attacker controlled AVIF file, a flaw in libheif, reached through the sharp image library, can lead to unauthenticated remote code execution. No login, no privileged endpoint. The underlying libheif advisory rates the flaw 9.8, describes a heap buffer overflow triggered by a crafted file, and lists every version up to and including 1.23.1 as affected, fixed in 1.23.2.
The second, CVE-2026-75604, needs three conditions at once: the Next.js server running on a Windows filesystem, an application using both the Pages Router and the App Router, and Cache Components not enabled. Linux and macOS are not affected. The advisory is explicit that there is no known workaround for affected Windows hosts, which leaves the upgrade as the only move.
For commerce, the Windows condition rules out almost everybody. Storefront hosting is overwhelmingly Linux. Confirm your runtime is not Windows and half the advisory closes with no further work. The AVIF half is where the actual decision sits.
Why the AVIF fix costs you image payload
Because the patched releases do not fix the decoder, they disable AVIF optimization outright until an upstream fix propagates. That is a reasonable call and a revealing one. The vulnerable code is in libheif, which sits under sharp, which sits under next/image, and a corrected libheif has to travel through sharp's bundled binaries before the format can be safely switched back on. Next.js could wait on a dependency it does not own, or it could turn off the feature. It turned off the feature.
Whether that costs you anything comes down to one line of configuration. The Next.js image component documentation gives the default as formats set to image/webp only, with AVIF strictly opt-in. If nobody on your team ever added image/avif to that array, this fix changes nothing about your output and you can bump the version without a second thought.
If AVIF was enabled, the picture changes. The same documentation puts AVIF at roughly 20 percent smaller than WebP, at the cost of about 50 percent longer encode time, and still recommends WebP for most use cases. So the practical effect of patching is that every browser previously being served AVIF now falls back to WebP, and image payload rises by something close to that 20 percent. On a listing page carrying thirty product shots, or a brand storefront where the largest contentful paint element is a full bleed photograph, that is a measurable regression in a metric Google reports on.
One useful exclusion. If your images config sets unoptimized to true, the optimizer never transcodes anything, it serves the source file as it is. That path does not reach libheif at all.
What the moved pre-announcement is actually worth
Pre-announced scope is a forecast, not a commitment, and this cycle is the proof. The August 20 notice named one critical issue and a patch version of 16.3.2 for August 26. What shipped was two critical issues in 16.3.3, a day early.
That is the disclosure model working rather than failing. A second critical vulnerability was found in a dependency during the notice window, and the sensible response was to ship sooner instead of holding a published date. But it changes what you plan against. Treat a pre-announcement as the signal to staff a patch window and get a rehearsal build green. Do not treat the stated version number or the stated date as fixed, and do not pre-write the assessment. The assessment only exists once the advisory does.
There is a second order lesson for anyone running a headless stack. The more severe of these two bugs was not in Next.js. It was three layers down, in a C library that decodes image containers. Your storefront's unauthenticated attack surface is as deep as its image pipeline, and an optimizer that accepts bytes influenced by a URL parameter deserves the review attention you already give a checkout endpoint. That is a discipline Magento and Hyva teams learned through years of Adobe bulletins on platform commerce builds, and headless teams are now learning on framework cadence.
What we would change this week
Bump the version, then grep your config for image/avif before assuming the patch was free. Four moves, in order.
First, patch. 16.3.3 if you are on 16.3, 15.5.24 if you are on 15.5. If you are on 16.2 or older you are not on a line that receives this, and you now have a minor upgrade sitting in front of a security fix.
Second, check the operating system your server actually runs rather than the one you assume it runs. If it is Windows, and the app mixes Pages Router and App Router without Cache Components, this is today's priority and there is nothing to configure your way out of.
Third, if AVIF was enabled, measure rather than guess. Pull largest contentful paint on your three highest traffic templates, patch, pull it again. If the regression is real on a storefront where imagery is the product, that is the case for moving transformation to a CDN image service, which isolates the decoder from your application runtime and takes this whole class of bug out of your dependency tree. For a headless storefront that is an architecture decision worth making with numbers rather than as a reflex.
Fourth, write down who re-enables AVIF and on what evidence. The advisory says the format returns when the upstream fix propagates. Somebody has to notice that, verify sharp is carrying libheif 1.23.2 or later, and flip the config back. With no owner, the likely outcome is that AVIF stays off for a year and nobody remembers why the images got heavier.