Fix the libheif AVIF RCE: A CVSS 9.8 Bug in Sharp and Next.js

TL;DR Fix the libheif AVIF RCE (CVE-2026-84383) if your stack decodes user-supplied images: a CVSS 9.8 heap-buffer-overflow in libheif’s AVIF/HEIF decoder reaches Sharp, libvips, ImageMagick, and Next.js Image Optimization, because all four call the same C library to resize AVIF files. Security researchers reported it on August 11, 2026; libheif shipped a fix (v1.23.2) and Next.js shipped a mitigation on August 25. Check whether your dependency versions fall in the affected range below, and patch or disable AVIF resizing until you do.

What is the libheif AVIF RCE (CVE-2026-84383)?

libheif is the C++ library that decodes HEIC, HEIF, and AVIF image files. It doesn’t ship user-facing products — it ships as a dependency inside other people’s, which is exactly why this bug matters more than its GitHub star count suggests.

CVE-2026-84383, disclosed under advisory GHSA-g89c-p67h-r497, is a heap-buffer-overflow in libheif’s scale_nearest_neighbor() function, scored CVSS 9.8 (Critical). A crafted image file with nested identity-derivation (iden) and auxiliary (auxl) item references tricks the decoder into two mistakes at once: it accepts duplicate destination channels without validating them, and it allocates a buffer sized for an 8-bit alpha plane while later writing 16-bit samples into it. The write overruns the allocation and corrupts adjacent heap memory — a textbook out-of-bounds write, and a strong candidate for remote code execution in a network-facing service.

The affected range is libheif v1.22.0 through v1.23.1. The fix ships in v1.23.2, released August 25, 2026.

Why one C library reaches Next.js, WordPress, and ImageMagick

Nobody who runs a Next.js app installed libheif on purpose. They installed Next.js, which resizes images through sharp, which decodes AVIF through libvips, which delegates AVIF decoding to libheif. Four layers, one shared point of failure at the bottom.

The same pattern repeats outside the Node ecosystem. ImageMagick uses libheif directly through a delegate for AVIF and HEIC conversion. WordPress’s media library uses whatever image backend the host’s PHP build links against, which on most managed hosts is ImageMagick — so the exposure reaches a CMS that never mentions libheif in its own changelog. None of these products are careless; they’re all making the same reasonable choice to not re-implement an image codec, and that choice is exactly what turns one memory-safety bug into a cross-stack incident.

How was it found, reported, and patched?

The disclosure moved fast by security-research standards, and the timeline is worth reading as a template for what coordinated disclosure should look like:

1. August 11, 2026 — Security researchers (credited on the advisory as finder rootxharsh, coordinated by hacktronai-research and KarimPwnz) reported what looked like a remote-code-execution path in Next.js Image Optimization.

2. August 12 — Vercel and the researchers independently reproduced the bug with a working proof of concept, confirming it wasn’t a false positive.

3. August 13 — Vercel shipped a platform-level mitigation in its Image Optimization service, cutting off the exploit path in production before a code fix existed.

4. August 19 — The Next.js team met with the libvips maintainer to coordinate a fix at the right layer of the dependency chain, rather than patching around it in application code.

5. August 24 — Downstream security partners were notified ahead of public disclosure, the standard courtesy window before a CVE goes live.

6. August 25 — libheif released v1.23.2 with the real fix, and Next.js shipped a security release disabling AVIF optimization and resizing as a defense-in-depth backstop.

Fourteen days from first report to a shipped fix, with a production mitigation live on day two — that’s what a disclosure looks like when the reporter hands over a reproducible proof of concept instead of a speculative write-up.

The overflow, in one picture

The root cause is a byte-width mismatch that’s easy to state precisely: the decoder allocates a buffer for 8-bit-per-sample data, then a later code path writes 16-bit samples into that same allocation.

That’s the whole bug: allocate for one bit depth, write at another, and let an attacker control which bit depth shows up by nesting iden and auxl item references until the decoder loses track of which alpha plane it’s actually filling.

Are you exposed? Check your stack

Component	Uses libheif for AVIF/HEIF?	Fixed version	What to do
Next.js Image Optimization	Indirectly, via sharp → libvips	Next.js security release, Aug 25 2026	Upgrade Next.js; AVIF resizing is disabled by the patch
sharp (npm)	Indirectly, via libvips	Depends on bundled libvips build	Upgrade to a release bundling libvips linked against libheif ≥ v1.23.2
libvips	Delegates to libheif	Rebuild against libheif ≥ v1.23.2	Rebuild or upgrade your libvips package
ImageMagick (AVIF/HEIC delegate)	Directly	Delegate rebuild against libheif ≥ v1.23.2	Rebuild ImageMagick’s HEIF delegate or disable the format
WordPress media library	Directly, via host’s ImageMagick/PHP-Imagick build	Depends on host	Ask your host whether their ImageMagick build has been rebuilt
Any custom pipeline calling libheif	Directly	v1.23.2	Bump the dependency and rebuild

If you can’t answer “yes, patched” for every row that applies to your stack, treat yourself as exposed until you check.

How to patch or mitigate today

1. Find every place libheif enters your stack. Run npm ls sharp and check whether your sharp version bundles a libvips built against libheif ≥ v1.23.2; for anything running a system ImageMagick, check identify -list delegate | grep heif.

2. Upgrade the direct dependency. For Node projects, bump sharp to a release that vendors the patched libvips/libheif; for system packages, upgrade libheif to v1.23.2 or later and rebuild anything linked against it.

3. Upgrade Next.js if you use Image Optimization. The August 25 release disables the vulnerable AVIF path outright, which covers you even before your other dependencies catch up.

4. If you can’t upgrade today, disable AVIF at the boundary. Remove image/avif from the formats array in next.config.js, or reject AVIF uploads in your own validation layer before they ever reach a decoder.

5. Re-scan anything that stores user-uploaded images long-term. A file uploaded before the patch and decoded again later (thumbnail regeneration, a CDN cache miss, a batch re-encode job) can still trigger the bug on an unpatched decoder, even if new uploads are now safe.

What breaks if you don’t patch?

The direct consequence is remote code execution on whatever process decodes the malicious image — an image-resize worker, a serverless function backing your CDN, a WordPress PHP process. A CVSS 9.8 score means the attack requires no authentication and no user interaction beyond the image reaching a decoder, which describes almost every public upload form, avatar picker, or CMS media library on the internet.

The indirect consequence is scope creep in your own incident response. Because the bug lives four layers down from the framework your team actually reads the changelog for, a team that only tracks next and sharp release notes can miss that the real fix landed in a C library neither package.json mentions by name. Auditing your actual exposure means walking the dependency chain down to libheif, not just up to Next.js.

When is disabling AVIF the safer call than waiting to patch?

Disable AVIF now, patch on your normal schedule, if any of these are true: you can’t rebuild a system ImageMagick or libvips package outside a maintenance window, your image pipeline runs on infrastructure you don’t fully control (a shared host, a third-party CDN’s transform service), or you’re still auditing which of your dependencies actually reach libheif.

Losing AVIF’s smaller file sizes for a few days is a better trade than leaving a CVSS 9.8 decoder reachable from an upload form. Patch to sharp/libheif ≥ v1.23.2 as the permanent fix, and re-enable AVIF once you’ve confirmed the whole chain is current.

How this compares to AI-slop vulnerability reports

Maintainers have spent the last year drowning in fabricated CVE reports generated by AI tools that never reproduce a real bug, and separately fending off AI agents that file low-quality “vulnerabilities” against open-source projects with no working exploit attached. Both are a real tax on maintainer time, and it’s fair to be skeptical of any inbound security report right now.

This disclosure is the counterexample worth naming: a specific function, a specific byte-width mismatch, a proof of concept both sides independently reproduced within a day, and a coordinated timeline that named every party involved. The same standard applies whether the reporter is a person, a team, or an automated pipeline pulled straight into your CI/CD — reproducibility is the whole test, not the label on the reporter.

If you’re building or hardening an image-upload pipeline more broadly, the patch discipline here — validate at the boundary, then re-verify anything already stored before the fix — applies well past this one CVE. And if your app is a Next.js deployment on Vercel or you’re weighing Next.js against other meta-frameworks, image-pipeline dependency depth is a line item worth adding to that comparison.

FAQ

What is CVE-2026-84383?

CVE-2026-84383 is a CVSS 9.8 heap-buffer-overflow in libheif’s scale_nearest_neighbor() function. A crafted HEIC, HEIF, or AVIF file with nested identity-derivation and auxiliary item references makes libheif write 16-bit pixel samples into a buffer sized for 8 bits, corrupting adjacent heap memory. It affects libheif v1.22.0 through v1.23.1 and is fixed in v1.23.2.

Am I affected if my app never touches AVIF files directly?

You can still be exposed. The bug triggers inside libheif’s decoder, which sharp and libvips call any time they decode an AVIF or HEIF image — including ones a user uploads. Next.js Image Optimization decodes AVIF by default when a browser’s Accept header requests it, so a public upload form can reach this code path without your team ever writing AVIF-specific code.

Does upgrading Next.js alone fix this?

It removes the immediate risk, but not by patching libheif. Next.js’s August 25 security release disabled AVIF optimization and resizing entirely, which takes the vulnerable decode path out of the request flow. If you also run sharp or libvips directly — in a custom upload pipeline, a CMS plugin, or a resize worker — you still need libheif v1.23.2 or later there.

What should I do if I can’t upgrade immediately?

Disable AVIF as an accepted input and output format in your image pipeline’s configuration until you can patch. For Next.js, that means removing image/avif from the formats array in next.config.js. For a custom sharp or libvips pipeline, reject AVIF uploads at the boundary and re-encode any AVIF you must accept through a service running the patched libheif.

Is this the same kind of report as the AI-slop CVEs flooding maintainers?

No, and the contrast is the point. This disclosure shipped a reproducible proof of concept that Vercel and the libheif maintainers both verified within a day, named the exact function and byte-width mismatch at fault, and tracked a real timeline to a real patch. Compare that to the fabricated, unreproducible reports maintainers increasingly triage and reject.

Sources

• Vercel, “Reproducing, disclosing, and fixing the libheif vulnerability with Hacktron and the maintainers”, September 18, 2026.
• libheif security advisory, GHSA-g89c-p67h-r497 / CVE-2026-84383.