One Image Library Sits Under OpenAI, Slack, Meta and GitHub. Breaking It Took Three Hours of Model Time

Three researchers at Hacktron spent the summer pulling on one thread: libheif, the open-source C library that turns HEIC, HEIF and AVIF files into pixels. This week they published what it unravelled. A heap buffer overflow in the library's decoding path gave them remote code execution on OpenAI's community forum, and from there the ChatGPT and Codex accounts of OpenAI employees, and from there the GitHub repositories those accounts were connected to. The same flaw class reached Slack, Meta, GitHub Enterprise Server, Discourse and Next.js.

Everything is patched. The bug is not the story.

The dependency nobody writes down

Almost every platform that accepts a user-uploaded photo has to decode it, and almost none of them decode it themselves. They hand the bytes to a native library, and for HEIC and AVIF that library is usually libheif, which in turn leans on libde265 for the actual HEVC decoding. It is not listed on a marketing page, it is rarely in a threat model, and on most stacks it is pulled in three or four layers deep by an image-processing gem or a thumbnail service.

The upstream advisory, GHSA-g89c-p67h-r497, rates the flaw 9.8 and describes the conditions plainly: a crafted HEIC, HEIF or AVIF file triggers a heap buffer overflow during an ordinary decode call. No authentication, no user interaction, no unusual API configuration. Any application that decodes an untrusted image is in scope. The advisory carries no CVE of its own — a reminder that "has a CVE" is a poor proxy for "is being tracked."

That is why the affected list reads like a directory of the modern web rather than a list of one vendor's customers.

What to patch

If you run anything self-hosted on that list, the version number is the whole job. If you run your own image pipeline, the question is which of your services calls into libheif without your knowing, and whether that decode happens inside a sandbox or inside the application process.

Fourteen hours, and $6,500

The OpenAI timeline in the researchers' write-up is unusually specific. They identified the overflow in the copy of libheif reachable through Discourse on 23–24 July. On the morning of 25 July they had code execution on community.openai.com. They reported it through OpenAI's Bugcrowd programme within a few hours, then demonstrated impact by taking over employee accounts and opening a pull request inside OpenAI's internal codebase. OpenAI confirmed a fix at 22:49 UTC the same day — under fourteen hours from report — coordinated with Discourse upstream, and paid a $6,500 bounty on 1 September.

That response is the part of this story that worked. A forum is exactly the kind of low-prestige adjacent property that accumulates real access precisely because nobody thinks of it as production, and OpenAI treated it as production.

The three hours that matter

Memory-corruption bugs in image parsers are not new; fuzzing has been turning them up for two decades. What has historically limited them is that finding a crash is cheap while turning that crash into a reliable exploit against a hardened modern target is expensive, scarce, specialist work. That gap is the reason most such bugs are patched quietly and never weaponised.

The researchers say the gap has closed. In their account, Claude Opus 4.8 failed across several sessions to produce a working exploit with standard memory protections enabled; Opus 5, given the same problem within hours of its release, produced one in about three hours, which they then ported to the architecture their target ran on. Their project page describes an agentic workflow with a frontier model compressing exploit development to roughly one to three days from first probe to remote code execution.

They draw the conclusion themselves:

AI is removing that protection by turning more of this scarce expertise into compute. Work that once required a well-resourced team and months of effort can now be compressed into days.

These are the researchers' claims about their own tooling, and they should be read as such. But the corroborating evidence is not rhetorical: seven platforms patched, a CVE at GitHub, a paid bounty, and a fix landing in under a day because the report arrived with working impact attached.

What defenders should take from this

The practical lesson is not about AI at all. It is that the economics of your unpatched dependencies have changed. A memory-safety bug in a parser you did not know you shipped used to be a theoretical risk on a long list. The assumption that nobody will bother to weaponise it is now the weakest link in that reasoning, and it is the assumption most backlog triage quietly depends on.

Patch libheif to 1.23.2. Then find out what else in your stack parses untrusted bytes in C, and whether it does so somewhere it can be contained.

Sources: Hacktron: Hacking OpenAI · HEIF Heist · libheif advisory GHSA-g89c-p67h-r497 · Forbes: Security Researchers Hacked Into OpenAI Using Anthropic's Claude