A maintainer corrected a memory bug, pushed the commit, and moved on. No advisory. No security label. No CVE identifier. That single omission is why Vercel spent two weeks in August coordinating patches across four open source projects and ultimately switched off AVIF image optimization for every application it hosts.
Key takeaways
- Vercel disabled AVIF optimization platform-wide on August 13 and shipped a Next.js security release on August 25 after tracing a reported RCE to libheif rather than its own code.
- The vulnerable path runs from next/image through sharp to libvips, which calls libheif for AVIF decoding β a chain shared with ImageMagick, WordPress and much of the web.
- Vercel reported that private vulnerability submissions on GitHub grew from 500 per week in January to 3,000 per week in May 2026, with 1,560 reviewed advisories that month.
The labeling gap is the actual failure
Without a security label, nothing downstream fires. Distribution packagers get no signal to backport. Dependency scanners have no identifier to match against. Debian 12 and 13 kept shipping affected versions, and Debian's own update did not arrive until August 8. Every consumer of those packages inherited the exposure while the correction sat in public git history, visible to anyone who read the diff carefully enough.
For years that was a tolerable failure mode. Reading a year of upstream commits across a decoder to find an unlabeled memory fix was expensive expertise. It is not expensive anymore. A three-researcher survey of exposure across Slack, Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro and Gatsby ran two months and cost under $3,000 in tokens.
Why the report landed on the wrong project
Hacktron AI brought the issue to Vercel in August, framed as an RCE in Next.js image optimization. The investigation moved the blame upstream fast. Next.js applications that use the Image component can resize and optimize AVIF files. Doing so invokes sharp, sharp invokes libvips, and libvips calls libheif to decode.
That meant a hostile AVIF image sent to the optimization endpoint could reach vulnerable decoder code without touching a line of Next.js. The framework was a conduit, not the defect. It was also the only layer Vercel directly controlled at that moment.
The disclosure timeline
Vercel's engineering write-up dates each step. Hacktron reported on August 11 and 12, and the two teams reproduced the RCE against a current Next.js build with a working proof of concept.
On August 13 Vercel applied a platform mitigation. Every image optimization request on Vercel passes through one central service, so disabling AVIF optimization and resizing there cut the path for all hosted customers at once. Incoming AVIF files simply stopped reaching libheif.
Self-hosted deployments were a different problem, and the reason the rest of the timeline exists. Vercel emailed the maintainers of sharp and libvips, and opened coordination with libheif through a GitHub Security Advisory. Hacktron submitted its exploit details to libheif separately. On August 19 the Next.js team met the libvips maintainer to align the remediation path. Security partners were notified on August 24.
August 25 closed it. Next.js folded an AVIF mitigation into a security release originally scheduled for an unrelated issue and shipped it a day early, disabling AVIF optimization and resizing outright. The libheif maintainer released v1.23.2 remediating the RCE on the same day, six days after that coordination meeting.
How far the same decoder reaches
libheif is a dependency of ImageMagick, WordPress and sharp, which is why an obscure flaw here has an unusually wide blast radius. The decoder had been corrected upstream the previous year, but because the commit carried no security marking, the correction never propagated as one.
The reach was not theoretical. Weeks before the Vercel report, researchers chained the same class of libheif overflow with an SSO weakness to reach OpenAI's internal monorepo through a community forum image upload β a completely different product, entry point and remediation path, built on the identical unlabeled defect.
Outlook
Vercel framed the volume problem directly, noting the CVE program has published more than 35,000 identifiers in 2026 and that it expects more upstream flaws like this one to surface as language models accelerate vulnerability research. It also warned that recent Next.js security releases have been more frequent and that the trend should continue.
The practical consequence for teams is narrower than the headline suggests. Platform customers were covered on August 13 without doing anything. Everyone running their own image pipeline has to confirm which libheif build they actually ship, which is precisely the question an unlabeled fix makes hard to answer.
FAQ
Was the vulnerability in Next.js itself?
No. The defect was in libheif, an AVIF decoder reached through sharp and libvips when Next.js optimizes AVIF images. Next.js disabled AVIF optimization as a mitigation because it was the layer that could be patched quickly, not because it contained the flaw.
Do I need to do anything if I deploy on Vercel?
No action is required. Vercel disabled AVIF optimization and resizing in its central Image Optimization Service on August 13, which blocked the path for all hosted applications. Self-hosted deployments need the August 25 Next.js security release or a libheif build at v1.23.2 or later.
Why does an unlabeled upstream fix matter so much?
Security tooling keys off identifiers. A commit that silently corrects a memory bug never enters the advisory database, so distributions do not backport it and CI scanners cannot flag affected versions. The fix exists in public code while every downstream consumer stays vulnerable.
