SURIQ
The fix for this one lands very differently depending on where your app runs. If you host on Vercel, the two critical Next.js flaws were patched centrally and you have nothing to do. If you run Next.js on your own servers, you inherit both the fix and the clock: the code is identical, but your exposure window only closes when you notice and update. That split is the whole story here, and it is why a self-hosting operator should treat the August 25 release as today's work, not this quarter's.
Next.js moved its scheduled security release forward by a day after finding a second critical bug in an upstream dependency, and published fixes in v15.5.24 (the Maintenance long-term-support line) and v16.3.3 (the Active long-term-support line). Both flaws lead to unauthenticated remote code execution, meaning an attacker who can reach your app can run commands on the host without any login.
| Flaw | AVIF image optimization | Windows path traversal |
|---|---|---|
| Identifier | GHSA-2xp9-vwfh-vxw4 (upstream libheif GHSA-g89c-p67h-r497) | CVE-2026-75604 |
| Severity | Critical (CVSS 9.5, as publicly scored) | Critical (CVSS 9.0, as publicly scored) |
| Trigger | Server optimizes an attacker-supplied AVIF image | Windows host with the Pages Router and App Router both active and Cache Components off |
| Affected | 10.0.0 to 15.5.23; 16.0 to 16.3.2 | 13.4 to 15.5.23; 16.0 to 16.3.2 |
| Fixed in | 15.5.24, 16.3.3 (AVIF optimization disabled) | 15.5.24, 16.3.3 (no workaround) |
The AVIF fix is a feature switched off, not a bug closed
Read the patch note carefully and you will see something unusual. Next.js did not fix the image flaw. It turned the feature off. The critical bug lives in libheif, the library that the sharp image processor uses under the hood, so the patched releases disable AVIF optimization entirely until the upstream fix propagates. The Next.js team cannot repair code it does not own, so it removed the attack surface instead.
Two consequences follow that no advisory spelled out. First, if your site relied on serving AVIF through Next.js image optimization, that capability is now gone until a later release restores it, so budget for the visual and performance change rather than being surprised by it. Second, and more important for defenders, the root cause is not a Next.js problem at all. Anything else in your fleet that decodes AVIF through libheif or sharp, an upload pipeline, a thumbnail service, a separate Node app, is exposed to the same class of bug and will not be fixed by upgrading Next.js. Inventory where sharp and libheif run across your stack, not just inside this one framework.
The Windows flaw quietly targets teams mid-migration
The path traversal that leads to code execution on Windows, CVE-2026-75604, has a precondition that reads like fine print but is actually the interesting part. It hits a Windows host where the Pages Router and the App Router are both active and Cache Components is switched off. Linux and macOS are not affected, and there is no workaround for Windows deployments.
That specific combination is not a rare edge case. It is the signature of a codebase in the middle of moving from the older Pages Router to the newer App Router, running both at once during the transition. In other words, the population most exposed to this bug is the one actively modernizing its Next.js app on Windows. If that describes a service you run, the update is not optional and there is nothing to fall back on but the patch itself.
Self-hosting means you own the detection window too
There is no confirmed in-the-wild exploitation as of this writing, but the window is not comfortable. A full proof-of-concept was released alongside the libheif disclosure, and on August 26 Cloudflare pushed an emergency web application firewall release that updated a rule for the Windows flaw and added a new rule for the image optimizer flaw. When a content delivery network ships emergency rules the day after a disclosure, it is telling you the exploitation path is understood and considered reachable.
For a self-hoster, a public exploit is the attacker's head start, and if your app is not behind a firewall that already carries those rules, you are relying on the patch alone. Patching closes the door. It does not tell you whether anyone walked through it during the days the flaw was live. On a self-hosted Next.js box the signals worth checking are the same shape as any code-execution hunt: the Node or Next.js server process spawning unexpected child processes, and unusual activity on the image optimization route (/_next/image) carrying AVIF payloads. This is the case for treating internet-facing app servers as tracked exposure you monitor, not fire-and-forget infrastructure.
We have watched this pattern before with self-hosted software: a flaw whose real fix depends on a dependency you do not control, so the patch you install is a stopgap while the upstream one propagates. It played out with a Node package flaw whose patch never reached most apps, and with a self-hosted server that took three patches to close. The common thread is ownership: when you run the software yourself, the propagation problem is yours to manage.
Update to 15.5.24 or 16.3.3, then check your image pipeline
Do three things. Update self-hosted Next.js to 15.5.24 or 16.3.3 today, prioritizing any Windows-hosted app that runs both routers. Confirm AVIF optimization is off after the update, and find every other place sharp or libheif decodes untrusted images, because those stay exposed until the upstream fix lands. And if you have logs from before the patch, look back through the exposure window rather than assuming a clean install means a clean history. Applications on Vercel need none of this, which is precisely the point: self-hosting buys you control, and control is another word for the work you now have to do.