Vercel has patched two critical vulnerabilities in Next.js, both giving unauthenticated remote code execution.
Before anything else: this site runs Next.js 16.3.0, with AVIF enabled. It is inside the affected range for both. More on that below, because reporting on a flaw in your own stack while pretending to stand outside it would be silly.
The two flaws
| Windows path traversal | AVIF heap overflow | |
|---|---|---|
| Identifier | CVE-2026-75604 | GHSA-2xp9-vwfh-vxw4 |
| Severity | 9.0 | 9.5 (CVSS v4) |
| Affected | 13.4–15.5.23, 16.0–16.3.2 | 10.0.0–15.5.23, all 16.x to 16.3.2 |
| Fixed in | 15.5.24 and 16.3.3 | 15.5.24 and 16.3.3 |
| Condition | Windows-hosted servers only | AVIF explicitly enabled |
The first was found by evolutionstorm and B0RI. Vercel's guidance is blunt: there is no known workaround for affected Windows-hosted applications, and you should upgrade immediately if your server is hosted on Windows. Linux and macOS deployments are unaffected.
The second was found by rootxharsh and coordinated by KarimPwnz, credited to the Hacktron team. The bug is not really in Next.js — it is a heap buffer overflow in libheif, through version 1.23.1, in the image scaling code. Next.js is where it becomes reachable by a stranger.
The precondition is the story
The AVIF flaw only triggers if AVIF is explicitly enabled in your config. That sounds like a narrow condition. It is not.
Enabling AVIF is one line. It is recommended for performance almost everywhere, because AVIF files are substantially smaller than the alternatives and image weight is most sites' largest cost. A great many people added that line on a Tuesday afternoon to make Lighthouse happier, and in doing so connected an unauthenticated request path to a decoder with a heap overflow in it.
That is the general shape worth taking away. The vulnerability is in a decoding library nobody chose directly, reached through a feature enabled for speed, exposed on an endpoint designed to accept arbitrary input from the internet. Nobody made a bad decision at any single step.
The fix reflects how bad it is: the patched releases disable AVIF optimisation entirely, pending libheif 1.23.2. Removing the feature rather than fixing the call is what a vendor does when it cannot wait for the upstream fix.
What this site is doing
Root Notes runs Next.js 16.3.0. The config sets image formats to AVIF and WebP, so the precondition is met, not hypothetical.
Production is on Vercel, and Vercel says Vercel-hosted applications are protected automatically with no upgrade required. That is the platform's own statement, and this site is taking it at face value while also upgrading, because "the platform mitigates it" and "the code we ship is not vulnerable" are different claims and only the second is under our control.
Local development happens on Windows, which is the condition for the other flaw. A dev server bound to localhost is not internet-facing, so the practical exposure there is low — but it is the affected class, and the upgrade closes both.
What to do
- Upgrade to 15.5.24 or 16.3.3. It closes both.
- If you self-host, do it now. Only Vercel-hosted applications are described as automatically protected.
- If your server runs Windows, treat it as urgent regardless of AVIF. Vercel says there is no workaround.
- Check whether you enabled AVIF. It is in the images block of your Next config, and most people who added it do not remember doing so.
- Do not assume a managed platform covers you. Ask what specifically is mitigated, and upgrade anyway.
What is not established
- Whether either is being exploited. No known exploitation of the Windows flaw as of 27 August; the AVIF one has a demonstrated proof-of-concept with no independent verification of the RCE claim.
- How many deployments have AVIF enabled. No figure exists.
- Exactly what Vercel's automatic protection does, beyond the statement that it applies.
- When libheif 1.23.2 lands, and therefore when AVIF optimisation comes back.
