The short answer
HEIF Heist is a set of memory-corruption bugs in libheif and libde265 — the native C/C++ decoders that read HEIF, HEIC, and AVIF images — that let a single crafted image trigger remote code execution or, at minimum, leak memory. Because those libraries sit beneath ImageMagick, libvips, and Sharp, the flaw reached Slack, Meta, GitHub Enterprise (CVE-2026-19118), Discourse, and Next.js. It was disclosed on September 18, 2026.
The uncomfortable part for engineering teams is that almost nobody lists libheif in their dependency file. It arrives transitively, runs on every uploaded photo, and executes native code below the safety of your application language. If your product accepts image uploads — a profile picture, a support-ticket attachment, an AVIF served by a Next.js image pipeline — you inherited this attack surface without ever choosing it. The fix is available (libheif v1.23.2 and the latest libde265), but the real work is finding every copy you ship.
What Hacktron disclosed
On September 18, 2026, the security research firm Hacktron published HEIF Heist, the result of a months-long investigation into how modern applications decode images. The team — Harsh Jaiswal, Mohan SRK, Rahul Maini, and Sudhanshu Rajbhar — framed it with a nod to a well-known xkcd cartoon: a huge stack of software resting on one small, obscure component that almost no one maintains. In this case the component is libheif (with its HEVC decoder libde265), the de-facto library for reading the HEIF, HEIC, and AVIF formats that phones and browsers now produce by default.
The core defect is a classic low-level bug: when the decoder processes a grid image, one bad calculation on the image’s width or height overflows an integer, which produces an undersized buffer, which the decoder then writes past — a heap buffer overflow. From there the researchers built working exploits, but they were careful to note that full code execution is not even required to cause harm. As Hacktron put it, “even when Remote Code Execution isn’t immediately achievable, the attack primitives may still allow arbitrary heap disclosure” — meaning an attacker can read adjacent memory, which may contain tokens, keys, or other users’ data.
What made the disclosure land hard was the target list. Hacktron demonstrated remote code execution on Slack, remote code execution in Meta’s core product suite via image upload, an authenticated RCE on GitHub Enterprise tracked as CVE-2026-19118, an authenticated RCE in Discourse, and an unauthenticated RCE in Next.js through its AVIF Image Optimization feature. The team also chained the image bug with a single sign-on weakness to compromise employee accounts at OpenAI and reach internal code repositories — an operation they say took under 72 hours. Fixes are shipped in libheif v1.23.2 and the latest libde265, along with product-specific patches from the affected vendors.
Why one image library is everywhere
The reason HEIF Heist touches so many unrelated products is the shape of the modern dependency graph. Almost no application talks to libheif directly. Instead, teams reach for high-level image tools — ImageMagick for conversion, libvips for fast thumbnailing, Sharp for Node.js pipelines — and those tools quietly bundle or link libheif and libde265 to support the newer formats. The native decoder runs several layers below the code a developer actually wrote, and usually below the language whose memory safety they were counting on.
That is why a normal package audit misses it. A JavaScript or Python lockfile will proudly show “sharp” or “imagemagick,” but not the C library doing the risky parsing underneath. The vulnerable code is real, it is reachable from any endpoint that accepts an image, and yet it is invisible to the dependency tooling most teams trust. This is the same transitive-native-dependency blind spot that has burned the industry before with libraries like libwebp and libxml2 — a single obscure parser under a mountain of apps.
The practical consequence is that securing this requires visibility into your build, not just your source. Teams that already run software bill of materials (SBOM) generation and native-dependency scanning as part of their cloud and DevOps pipeline can answer “where do we ship libheif, and what version?” in minutes. Teams that cannot are left guessing which of their services decode an attacker’s image with vulnerable code — exactly the question a 24-hour incident clock will demand.
What it means for US & EU software teams
The first lesson is that image upload is a code-execution boundary, not a storage feature. Any place a user, a partner, or an automated integration can hand your backend an image — avatars, KYC document scans, chat attachments, product photos, email-to-ticket pipelines — is a place where attacker-controlled bytes reach a native parser. That framing changes how you design the feature: images should be decoded in an isolated, least-privilege context, not in the same process that holds your database credentials.
The second lesson is about the speed of exploitation. With AI assistants collapsing exploit development into days, the old assumption that memory bugs are “theoretical” until someone spends a month on them no longer holds. For regulated sectors this compounds an existing obligation: under the EU Cyber Resilience Act’s new reporting duty and GDPR’s 72-hour breach rule, a confirmed exploited flaw in a product sold into the EU starts a fast regulatory clock. FinTech and HealthTech teams in particular should treat “we decode uploaded images” as a line item in their risk register, not an implementation detail.
The third lesson is that this is a supply-chain problem you can only manage with inventory. You cannot patch what you cannot see, and libheif is precisely the kind of component that hides. Whether you build in-house or partner with a team to ship custom software, the durable fix is a process that continuously enumerates native dependencies across every container and build artifact, so the next libheif-shaped disclosure is a same-day patch rather than a week-long scavenger hunt.
What to do now
- Upgrade the decoders everywhere. Move to libheif v1.23.2 or later and the latest libde265 — not just in your OS packages, but inside any bundled or containerized ImageMagick, libvips, or Sharp you ship. Rebuild images and redeploy; a patched host package does not help a container that carries its own copy.
- Apply the product advisories. If you run GitHub Enterprise, Discourse, or self-hosted apps built on Next.js image optimization, patch to the fixed releases named in each vendor’s advisory. The Next.js path is unauthenticated, so prioritize any internet-facing instance.
- Inventory where you decode images. List every endpoint and background job that reads HEIF, HEIC, or AVIF input, and generate an SBOM that surfaces native libraries, not just language packages. You need to know which services are reachable with an attacker-supplied image.
- Disable what you do not need. If a service never needs to accept HEIF or AVIF, turn that decoding off for untrusted uploads. Constraining input formats shrinks the attack surface immediately, before any patch lands.
- Sandbox image processing. Run decoding in a hardened, ephemeral, least-privilege sandbox — a separate process, container, or worker with no secrets and no network — so a decoder crash stays contained instead of becoming code execution in your main application.
Frequently asked questions
What is HEIF Heist?
It is the name security firm Hacktron gave to a class of memory-corruption bugs in the native image decoders libheif and libde265, which read HEIF, HEIC, and AVIF images. A crafted image can trigger an integer overflow that leads to a heap buffer overflow, enabling remote code execution or at least arbitrary memory disclosure. It was disclosed publicly on September 18, 2026.
Which products were affected?
Hacktron demonstrated attack paths against Slack, Meta’s core product suite via image upload, GitHub Enterprise (authenticated RCE, CVE-2026-19118), Discourse, and Next.js (unauthenticated RCE via AVIF Image Optimization). A chained exploit combining the image flaw with an OpenAI single sign-on issue reached internal OpenAI repositories. The list is illustrative — any service decoding untrusted HEIF/HEIC/AVIF may be exposed.
Why does one library affect so many apps?
libheif and libde265 are low-level decoders pulled in transitively through popular tools such as ImageMagick, libvips, and Sharp, which handle resizing, thumbnailing, and image optimization across most web and mobile backends. Because they arrive as a dependency of a dependency, they rarely appear in a normal package audit — even though they run on every uploaded image.
How do we fix and mitigate it?
Upgrade to libheif v1.23.2 or later and the latest libde265, including inside bundled or containerized ImageMagick, libvips, and Sharp. Apply the Next.js, GitHub Enterprise, and Discourse advisories. Disable HEIF/AVIF decoding for untrusted uploads where it is not needed, and isolate image processing in a hardened, ephemeral sandbox so a decoder crash cannot become code execution.
What role did AI play?
Hacktron used AI coding assistants, including Anthropic’s Claude and OpenAI’s Codex, to speed up exploit development — reportedly from weeks to one to three days, with the OpenAI compromise running in under 72 hours for less than $3,000 in tokens. The lesson is that AI is shrinking the gap between a public disclosure and practical exploitation, so patch windows are tighter than they used to be.
Sources
HEIF Heist — Hacktron research disclosure
CyberScoop — Researchers use AI to find widespread software decoder flaw
Tom’s Hardware — Hackers breach OpenAI using Claude tools via image-parser flaw