If a process decodes an untrusted image, that process is also holding every secret it was started with. Hacktron has published “HEIF Heist,” an investigation into memory-safety flaws in the native image decoders that sit underneath an enormous amount of web software. The headline demonstration is striking—a single HEIC image uploaded to a public forum, ending days later at write access to an internal source repository—but the part worth internalising is quieter: heap disclosure in a decoder is a credential-disclosure primitive.
Nobody threat-models the thumbnail generator. It runs as an ordinary service, with ordinary environment variables, holding ordinary API keys, and it accepts input from anyone on the internet by design.
What is confirmed
The research, by Harsh Jaiswal, Mohan SRK, Rahul Maini and Sudhanshu Rajbhar of Hacktron, concerns libheif and libde265—C and C++ libraries that parse HEIF, HEIC and AVIF images. The published root cause is an arithmetic error on a grid image's dimensions: an integer overflow produces an undersized buffer, and writing decompressed pixel data into it produces a heap buffer overflow. The researchers describe the resulting impact as memory corruption, data exposure and remote code execution, with out-of-bounds read and write primitives.
Because the flaw lives below the application layer, it is language- and framework-agnostic. The research names downstream exposure across Slack, Meta, GitHub Enterprise, Discourse, ImageMagick, Ruby on Rails and JavaScript frameworks including Next.js, Astro and Gatsby. Associated identifiers include CVE-2026-19118 for a GitHub Enterprise authenticated RCE, plus GitHub Security Advisories GHSA-g89c-p67h-r497 for libheif itself, GHSA-2jg2-4ch7-h545 and GHSA-vhm9-85gw-x335 for affected products.
The OpenAI chain is documented with timestamps. A HEIC file uploaded to the Discourse-powered community forum was routed through ImageMagick; the researchers confirmed remote code execution and administrative access on the forum instance on July 25, 2026. From there an SSO misconfiguration allowed escalation to employee accounts, and an employee's AI coding assistant that was connected to the GitHub organisation allowed a proof-of-concept pull request to be opened against an internal monorepo. They submitted to the bug bounty programme the same morning; OpenAI deployed a fix roughly fourteen hours later, at 22:49:45 UTC on July 25, and the report was resolved on September 1 with a $6,500 award.
The researchers state they demonstrated access without reading internal code and ceased testing once impact was established. The recommended remediation is to upgrade tolibheif v1.23.2 or later along with the latest libde265, disable HEIF and AVIF decoding where it is not needed, and isolate image processing in hardened, ephemeral sandboxes. Check the current upstream release rather than treating that version as final—later security releases have followed.
What remains unknown
No in-the-wild exploitation is claimed. This is researcher proof-of-concept work with coordinated disclosure and vendor fixes, not an incident report. Nobody has published evidence that any of the named organisations were attacked by anyone else through this path, and the absence of a CVE list for every downstream product does not mean every deployment was vulnerable—exposure depends on which version you run and whether you decode these formats at all.
One detail that will get repeated loosely: the researchers describe using AI coding models to develop the exploit, and say a newer model produced a working ARM64 exploit in about three hours where earlier ones had failed against ASLR. That is their account of their own tooling. It is not evidence that attackers generally have this capability, and it should not be used to argue either that the sky is falling or that nothing changed.
Why this is a secrets story
Read the impact list again: out-of-bounds read, arbitrary heap disclosure, access to in-memory data and environment variables. In most deployments, the process that resizes uploaded avatars was started with a set of environment variables that includes a database password, an object-storage key, a mail-provider token and whatever else the service needs. Memory disclosure in that process does not require code execution to be valuable. Reading the heap is enough.
The second lesson is about blast radius, and it is the more uncomfortable one. The initial foothold in the OpenAI chain was a community forum—about as low-value a system as exists. What turned it into repository access was the chain of identities attached to it: a single sign-on misconfiguration, then employee accounts, then an AI assistant holding an integration to the source-control organisation. None of those links were vulnerabilities in the image decoder. They were scope decisions.
What to do
- Patch the libraries, not just the app. Find every deployment that ships
libheiforlibde265—including inside container base images, inside ImageMagick, and inside framework dependencies you did not choose directly—and update them. - Turn off formats you do not need. If your product does not require HEIF or AVIF, refusing those inputs removes the attack surface entirely and costs nothing.
- Stop giving decoders secrets to hold. This is the change with the longest payoff: the process that parses untrusted input should not have production credentials in its environment. Split media processing into its own service with no secrets in its environment, fetch what it needs at the point of use, and give it a short-lived, narrowly scoped token instead of the platform key.
- Sandbox the decode step. The researchers' own recommendation—hardened, ephemeral, isolated processing—is the durable structural fix for a class of bug that will recur in the next parser.
- Audit integration scope, especially for AI assistants. Inventory what your coding assistants, bots and CI integrations can reach. An assistant connected to an entire source-control organisation converts any account compromise into a repository compromise. Prefer per-repository access and short-lived tokens.
- Treat community and marketing systems as production-adjacent. A forum, a support portal or a status page that shares an identity provider with staff accounts is part of your production trust boundary, whether or not it is on the same architecture diagram.
If you think you were exposed
There is no evidence of exploitation in the wild, so this is not a call to declare an incident. But if you ran a vulnerable version with an internet-facing upload path, the proportionate response is to patch, then rotate the credentials that were in that service's environment—on the assumption that memory disclosure is cheap and quiet and would not necessarily have left a trace in your logs. Rotate, and explicitly revoke the old values at the systems that honour them rather than simply issuing new ones.
Where Secretus fits—and where it does not
Secretus can reduce plaintext exposure when an authorized person must hand over a small, temporary value—a replacement API key, a rotated service credential—during exactly the kind of rotation described above, through a channel that does not retain it the way chat and ticketing do.
It does nothing about the underlying problem here. It is not a secrets manager, will not keep credentials out of a process's environment, cannot sandbox your image pipeline, and cannot tell you whether a decoder leaked memory. The architectural fixes above are the ones that matter; a one-time channel only helps with the human step at the end.