The bug report said remote code execution in Next.js image optimization. The defect was not in Next.js. It sat three dependencies down, inside libheif β an AVIF decoder that Vercel does not maintain, could not patch, and shares with ImageMagick, WordPress and much of the rest of the web.
So Vercel switched off the feature rather than the flaw, disabling AVIF optimization for every application it hosts within two days of the report.
Key takeaways
- Vercel applied a platform-wide AVIF mitigation on August 13, two days after Hacktron reported the issue, and Next.js shipped a security release on August 25.
- The vulnerable path runs from next/image through sharp to libvips, which calls libheif to decode AVIF β 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 in that month alone.
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.
Switching the feature off was the only fast lever
Correcting the decoder itself required the libheif maintainer. Getting a corrected decoder into production then required sharp and libvips to pick it up, distributions to rebuild their packages, and every downstream application to upgrade. That propagation runs in weeks. A working proof of concept already existed.
So the mitigation had to sit at a layer Vercel could change in hours, and what got switched off was the feature rather than the flaw. Every image optimization request on Vercel passes through one central service, which made the entire hosted fleet a single configuration change.
The cost falls on anyone leaning on AVIF for page weight: the format stops being optimized and resized, and files are served as they arrive. Vercel took that trade against an unauthenticated RCE.
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 the platform mitigation. 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 in one decoder carries an unusually wide blast radius. Builds up to v1.23.1 are affected and the remediation landed in v1.23.2, so the practical question for any self-hosted image pipeline is which libheif version it actually ships β a question many teams cannot answer from their lockfile, because the decoder often arrives as a system library rather than a declared dependency.
The reach was not theoretical. Weeks before the Vercel report, researchers reached OpenAI's internal monorepo through a community forum image upload, working through the same decoder in a completely different product with its own entry point and its own remediation path.
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 disclosure sounds. Platform customers were covered on August 13 without doing anything. Everyone running their own image pipeline has to establish which libheif build is installed on the machines that decode user-supplied images, and whether AVIF needs to be reachable there at all.
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 changed 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 disable the feature instead of shipping a patched decoder?
Because Vercel did not control the decoder. A corrected libheif has to pass through sharp, libvips and distribution packagers before it reaches production, and that propagation takes weeks. Turning off AVIF optimization removed the path to the vulnerable code immediately, and CI pipelines could adopt the upstream fix on their own schedule afterwards.
