If you self-host a Next.js app and you have not patched since August 25, 2026, stop what you are doing and upgrade now. Vercel shipped an emergency security release that fixes two critical-severity vulnerabilities, both enabling unauthenticated remote code execution, one through crafted AVIF image files and the other through a path traversal flaw on Windows-hosted servers.
One flaw lives in the image optimization pipeline; the other only bites servers running on a Windows filesystem. Both let an attacker run code without credentials.
The patches landed in Next.js v16.3.3 and v15.5.24, released August 25, 2026. Vercel moved the release forward after discovering the AVIF issue in an upstream dependency during preparation for a scheduled security update. If you are on Vercel, you are already protected. If you self-host, the clock is ticking.
What exactly happened in this Next.js security release?
Vercel disclosed two advisories under the August 2026 Security Release. Both carry critical ratings and both allow unauthenticated RCE, meaning an attacker does not need a session, token, or login to trigger them.
The first, tracked as GHSA-2xp9-vwfh-vxw4, lives in the Image Optimization API. Next.js uses the sharp library to resize and convert images, and sharp depends on libheif to handle AVIF files. A vulnerability in libheif means that when Next.js optimizes an attacker-controlled AVIF image, the attacker can achieve remote code execution on the server. The advisory rates this at a CVSS score of 9.5. The affected versions span from Next.js 10.0.0 through anything below 15.5.24 and 16.3.3.
The second, tracked as CVE-2026-75604 and GHSA-p293-qw3h-jr36, is a path traversal vulnerability. It affects applications using both the Pages Router and App Router without Cache Components, but only when the Next.js server runs on a Windows filesystem. Linux and macOS servers are not affected. The CWE classification is CWE-22, improper limitation of a pathname to a restricted directory. Affected versions start at 13.4. There is no workaround. If your server runs on Windows, you upgrade or you are exposed.
The AVIF vulnerability affects a wide range of versions, from 10.0.0 onward. The Windows path traversal flaw affects versions from 13.4. Both are patched in 15.5.24 and 16.3.3.
Which of my apps are exposed and which are already safe?
Start by splitting your fleet into hosted and self-hosted.
Vercel-hosted applications are protected. Vercel confirmed that once the AVIF vulnerability was identified, it disabled AVIF optimization across its managed Image Optimization service. AVIF inputs are served as-is and do not pass through the affected sharp and libheif processing path. The Windows path traversal flaw does not apply because Vercel's Next.js runtime uses Linux. No upgrades, configuration changes, or redeploys are required for Vercel customers.
Self-hosted applications are the target audience. The exposure surface depends on your operating system and whether you use image optimization.
For the AVIF RCE, the exposure is broad. Any self-hosted Next.js app from version 10.0.0 onward that runs image optimization on user-supplied images is theoretically at risk. If your app accepts image uploads from users, or if it optimizes images from external URLs, an attacker can craft an AVIF file to trigger the flaw. The patched versions disable AVIF optimization entirely until an upstream libheif fix propagates. AVIF images are served as-is in the patched releases.
For the Windows RCE, the exposure is narrower but more severe if it applies to you. The conditions are specific: the server must use a Windows filesystem, and the app must use both the Pages Router and App Router without Cache Components. If you check those boxes, there is no workaround and no configuration toggle to save you. You must upgrade.
How urgent is this patch for my production systems?
Treat this as a same-day patch window. The vulnerabilities are critical, unauthenticated, and RCE-capable. This is the category of flaw where a delay of hours, not days, matters.
For most self-hosted teams, the AVIF RCE is the more urgent of the two because of its breadth. Any version from 10.0.0 is affected, and the attack vector, a malicious image file, is trivial to deliver. If your app has a user upload form, an avatar cropper, or a feature that optimizes images from third party URLs, an attacker can send a crafted AVIF file and get code execution on your server. The CVSS score of 9.5 reflects the severity: network exploitable, no privileges required, no user interaction needed.
The Windows RCE is urgent for a smaller set of deployments, but for those deployments it is arguably worse because there is no workaround. The advisory is explicit: there is no known workaround for affected Windows-hosted applications, and you should upgrade immediately.
If you have been putting off a dependency upgrade from Next.js 14 or earlier, this release is your forcing function. The patched versions, 15.5.24 and 16.3.3, are available now. If you are on 15.x, run:
bash npm install [email protected]
If you are on 16.x, run:
bash npm install [email protected]
If you are on an older major version, this is the moment to move to a supported line. The 15.5 line is Maintenance LTS and 16.3 is Active LTS. Anything older is out of the patch window.
Should I be worried about the libheif dependency chain?
Yes, and this is the part that should give you pause even after you patch. The AVIF RCE is not a bug in Next.js code. It is a bug in libheif, an upstream library that sharp uses. Next.js patched by disabling AVIF optimization, not by fixing libheif. That fix is upstream and has not yet propagated.
This means your exposure does not necessarily end when you upgrade Next.js. If you use sharp directly in other parts of your stack, or if another service processes AVIF files through libheif, you are still exposed. The Next.js patch stops the framework from calling the vulnerable code path, but it does not fix the underlying library.
Audit your dependency tree for sharp and libheif. If you use them outside of Next.js image optimization, you need to track the upstream fix and patch those code paths separately. The vulnerability is in the library, and the library is used by more projects than just Next.js.
This is also a reminder that image processing pipelines are a persistent attack surface. Parsing untrusted binary input is dangerous, and AVIF is a complex format. If your app accepts image uploads, you should treat the processing layer as a security boundary, not just a utility function. For a broader look at how supply chain and dependency risks propagate, see our guide on the arrayref Rust supply chain attack, which targeted build-time code in a similar upstream fashion.
What should I do right now to lock this down?
Here is the action list, in priority order.
- Upgrade immediately. If you self-host, install
[email protected]or[email protected]depending on your major version. Do this before anything else. The patch window opened August 25, 2026, and every hour you wait is an hour an attacker could send a crafted AVIF file or exploit a Windows path traversal. - Verify your hosting platform. If you are on Vercel, confirm your deployment is using the managed Image Optimization service. You are protected. If you self-host on another cloud or on your own infrastructure, you are not. Confirm where each of your Next.js apps runs before assuming you are safe.
- Check for Windows-hosted servers. The Windows path traversal flaw has no workaround. If any of your Next.js apps run on Windows, they are the highest priority. Upgrade them first, before anything else.
- Audit your use of sharp and libheif. The AVIF fix in Next.js disables AVIF processing, but if you use
sharpin other parts of your stack, you are still exposed to thelibheifbug. Check your lockfile for these dependencies and track the upstream fix. - Review your image input paths. Any endpoint that accepts user-supplied images or optimizes images from external URLs is a potential attack vector. If you do not need AVIF support, consider blocking AVIF uploads at the edge until the upstream
libheiffix lands. - Monitor for exploitation. There are no public reports of active exploitation as of the disclosure, but the window between disclosure and active scanning is short. Check your logs for unusual requests to image optimization endpoints and for unexpected process execution on your Next.js servers.
The real cost of a quiet dependency
The AVIF flaw is the more instructive of the two. Your code did not have a bug. Your framework's code did not have a bug. A library you have never heard of, libheif, had a bug, and it gave attackers a path to run code on your servers through an image upload. This is the supply chain risk that keeps platform teams up at night, and it is the reason that dependency pinning and patch SLAs are not optional. The Next.js team did the right thing by moving the release forward and disabling AVIF optimization, but the upstream fix is still pending. Patch your framework, audit your dependency tree, and treat image processing as the security boundary it is.
