libheif bugs reached OpenAI repos and GitHub Enterprise

Hacktron’s researchers started with a crafted HEIC upload to OpenAI’s community forum and ended with a pull request opened in OpenAI’s internal monorepo. On September 18 they grouped that chain with claimed attack paths into Slack, Meta, GitHub Enterprise and Next.js under one name on the HEIF Heist site. If your backend decodes user-uploaded HEIC, HEIF or AVIF files, the language and framework on top give no protection because the flaws sit in the native libheif and libde265 decoders, and Hacktron’s fix is libheif v1.23.2 or later plus the latest libde265, from your distribution’s security channel or a source build.
That 1.23.2 floor is already behind. Hacktron’s own write-up on the OpenAI hack, dated September 13, says that as of September 14 v1.23.2 had been superseded by further security fixes and the latest upstream security release was v1.23.4. The same post warns that distribution packages may carry backported fixes under an older upstream version number, so the package’s security advisory counts more than the version string. Hacktron says HEIF Heist isn’t tied to one version: it lists the 1.19.x, 1.20.x, 1.22.x and 1.23.x release families as examples, and any deployment missing the latest upstream patches may be exposed.
What to patch, and where
Self-hosted Discourse needs a rebuild. Older Discourse Docker images may contain a vulnerable libheif that allows code execution through an image upload, and an update through the web interface alone may not replace the underlying image. Hacktron’s instructions are to run git pull and then ./launcher rebuild app from /var/discourse. Customers on Discourse’s own hosting have already been patched.
Next.js appears on Hacktron’s list with an unauthenticated RCE (remote code execution) through AVIF Image Optimization. On GitHub Enterprise the RCE requires authentication and carries CVE-2026-19118. For both Discourse and Next.js, Hacktron’s advice is to run the latest release and follow the projects’ security advisories. The post also names Ruby on Rails, Astro and Gatsby among the frameworks where it traced libheif.
Patching covers the known bugs, and Hacktron expects more, given how complex the ISO base media file format is and how fast the decoders change. Its defence-in-depth advice: turn off HEIF/AVIF decoding of untrusted files wherever it isn’t needed, or run image processing in hardened, ephemeral sandboxes. ImageMagick’s security policy can restrict which formats it accepts and how many resources it uses. Discourse started sandboxing ImageMagick right after the report.
How an upload reaches the decoder
Few applications call libheif directly. The library usually arrives bundled inside ImageMagick, libvips or Sharp, in standard distro packages or in prebuilt container base images. Discourse shows how indirect the path is: it checked images with FastImage, and because FastImage didn’t support HEIF, those files went to ImageMagick’s magick command for conversion, which handed attacker-controlled bytes straight to libheif.
The Discourse bug was a heap buffer overflow during HEIC decoding that gave out-of-bounds read and write. Upstream had changed the vulnerable code the year before, but the commit wasn’t labelled as a security fix and got no CVE, which Hacktron suggests may be why Debian 12 and 13 didn’t get the backport in time. Discourse’s image was built on Debian 12 and installed libheif 1.19.7, and Debian 13 still shipped the vulnerable 1.19.8 until its security update on August 8.
The attack itself starts with fingerprinting. Crafted .avif or .heic uploads reveal which libheif version family a service runs, and then the attacker sends an n-day or 0-day payload matched to that version. Where code execution doesn’t land, the same bugs can still leak heap memory, including other users’ data and environment variables. That leak is where the “heist” in the name comes from, and it is behind entries like leaked user tokens and AWS access tokens at a company Hacktron redacts.
The OpenAI chain
Hacktron began reviewing Discourse’s upload pipeline on July 23. An Opus 4.8 session inspecting the Discourse Docker image found the missing backports, and on July 24 it produced a working exploit with ASLR (address randomisation) turned off. Several more sessions failed to make it work with ASLR on. Anthropic released Claude Opus 5 that evening. Within three hours it wrote a working ARM64 exploit for a local Mac, then ported it to the x86-64 and jemalloc setup Discourse uses, and by 6:00 a.m. on July 25 the team had local RCE through an image upload. Opus refused to write exploits for remote instances, so the team proxied its own Discourse Cloud instance to look like a CTF target. By 10:00 a.m. the agent had RCE there, and the same script worked on OpenAI’s forum.
The forum offers “Sign in with OpenAI” through auth.openai.com, and an SSO misconfiguration on OpenAI’s side turned the forum compromise into takeovers of ChatGPT and Codex accounts belonging to active forum members, with no interaction from them. Hacktron stresses that this escalation is an OpenAI SSO problem rather than a Discourse one: compromising any first- or third-party service on OpenAI’s SSO would have given the same access. To prove impact without reading internal code, the team prompted an employee’s Codex, which was connected to OpenAI’s GitHub organisation, to open a PR in openai/openai, then stopped testing. Discovery to repo access took under 72 hours.
OpenAI paid a $6,500 bounty. Discourse got its report on a Saturday, replied on Sunday and had a fix by Monday.
How hard is it to exploit?
These aren’t off-the-shelf exploits. Each target has to be fingerprinted and the payload images tailored, and some of Hacktron’s RCE attempts landed only after thousands of uploads. Speed is the other side: Hacktron says an agentic setup with GPT-5.6 Sol brought exploit development down to roughly 1 to 3 days from first probe to remote RCE, and its post puts adapting the exploit to each new company at one or two days, usually without knowing the exact libheif version, libc version or deployment environment.
The whole campaign took two months, three researchers and less than $3,000 in tokens. When code execution landed inside a sandbox, the models also helped with privilege escalation, lateral movement and getting around existing defences. Hacktron says the hacking wasn’t fully autonomous and skilled human guidance still mattered.
Hacktron says it knows of no company except Shopify that detected the activity, even after thousands of images were sent and image processors crashed again and again.
Up next
OpenAI’s lawyers and recruiters now work through Codex
Codex took over OpenAI’s legal and finance desks Finance, recruiters and lawyers at OpenAI set a goal in Codex and let the thread run for days. Per The Pragmatic Engineer, those teams went from roughly 0% usage to 90% in four months, with no mandate from above.
Related stories
- GhostAction digs deleted API keys out of Git history
- Crafted Brotli data can run code on Node.js, Bun and Envoy
- OpenAI ships a Codex skill that checks sites for php2shell
- OpenAI agents tried a RubyGems bug found only in July
- Patch the kernel bug OpenAI’s agents turned into root
- Verifying OpenAI’s signed agent traffic from Python
Comments
No comments yet. Be the first.
Join the conversation
Sign in to leave a comment. It appears after moderation.

