Hacktron's HEIF Heist: An Unpatched Image Library Opened the Door to OpenAI's Monorepo

On 18 September 2026 the security team Hacktron AI published a multi-stage exploit chain that began with an ordinary image upload and ended inside OpenAI's private source code. The write-up, titled Hacking OpenAI, describes how three researchers reached the company's internal monorepo in under 72 hours, and how a fix that was never labelled a fix left the door open.

Related reading: A Zero-Click Flaw Let Malicious Plugins Run Code in Four Major AI Coding Agents · OpenAI's Agent Swarm Flooded RubyGems With 2,000 Malicious Gems, Researchers Say.

The work was done on 25 July 2026 and disclosed only after the affected projects had shipped their patches. Hacktron says its path never depended on a mistyped password, a phishing email or a cooperative employee. It combined a memory-safety bug in an image decoder with an identity configuration flaw, and used one to amplify the other. The team, Harsh Jaiswal, Mohan Pedhapati and Rahul Maini, later expanded the decoder research into a campaign they call HEIF Heist.

How the chain worked

The documented path has four steps, and each one is ordinary on its own.

Step one: an image reaches a C library. community.openai.com is an OpenAI forum running Discourse. Discourse screens uploads with FastImage, which does not support HEIC or HEIF, the formats an iPhone produces by default. Files in those formats fall through to ImageMagick's magick command, which hands them to libheif, a C/C++ decoder. In the researchers' account, uploading a crafted HEIC file was therefore enough to send attacker-controlled bytes straight into a native parser.

Step two: the parser breaks. libheif contained a heap buffer overflow, reported as CVE-2026-32882 with a CVSS score of 8.8. Triggering it during HEIC decoding gave out-of-bounds read and write primitives, and the team turned those into remote code execution on the forum container. The detail that matters most sits in the history of that code: upstream had changed it roughly a year earlier in a routine cleanup commit that carried no security advisory and no CVE. Debian therefore never backported the change. Debian 12 and Debian 13 both shipped a vulnerable libheif, and the Discourse Docker image, based on Debian 12, inherited it. Debian released DSA-6417-1 for Debian 13 on 8 August 2026.

Step three: the forum grants access to OpenAI accounts. With administrative remote code execution on the forum, the team abused a misconfiguration in OpenAI's single sign-on at auth.openai.com. The forum offered "Sign in with OpenAI", so a session on community.openai.com carried weight across OpenAI's consumer products. Hacktron could hijack the ChatGPT and Codex sessions of logged-in OpenAI employees with no victim action at all. The researchers stress that this step was an OpenAI identity issue rather than a Discourse flaw, and that any first-party or third-party service using the same SSO would have opened the same door.

Step four: proof, not theft. Using one employee's Codex, which was connected to OpenAI's GitHub organisation, the team prompted it to open a harmless pull request, PR #1186742, in the internal openai/openai monorepo, then stopped. Hacktron says it did not read or exfiltrate internal code. A merged pull request from inside the corporate boundary is a cleaner demonstration of write access than a screenshot, and it is the kind of proof a bounty programme can act on.

A forum is a low-value target until it is wired into the identity system that guards everything else. That wiring is what Hacktron rode into OpenAI's accounts.

Why the unlabeled fix is the real story

The headline is that researchers reached an AI company's internal code. The more transferable lesson is what happens when security work ships without a security label.

Vulnerability databases key on identifiers. Distributions decide what to backport based on advisories, CVEs and release notes. When a memory-safety fix arrives as routine maintenance under a neutral title, none of those signals fire. The upstream libheif change was treated as cleanup, so the ecosystem had no reason to look, and the vulnerable version held its place in container images long after the code had been corrected at the source. The State of AI account of the chain puts the exposure in similar terms: the bug was fixed, but nobody knew to say so.

That gap is not rare, and it grows more consequential as stacks deepen. This bug did not live in a forum, a framework or an application. It sat several layers down, inside a decoder that reaches production through wrappers such as ImageMagick, libvips and sharp, and through prebuilt base images that few teams update by hand. A company can track its direct dependencies carefully and still be exposed by a transitive one it never listed.

Version numbers alone are not a reliable check either. A distribution can backport a fix without changing the apparent upstream version, and a container can pin an old system package even after the application on top has been rebuilt. The lilting.ch write-up makes the point directly: what matters is which version actually executes, which means reading the distribution's security advisory alongside the package changelog rather than trusting a string in a lockfile.

Discourse moved quickly once it had the report. It added sandboxing around ImageMagick, shipped a fix on Monday 27 July and published advisory GHSA-vhm9-85gw-x335 on 28 July 2026. Sandboxing is the part worth copying. Memory-safety bugs in image parsers will keep appearing, so the durable defense is to assume a decoder will be compromised and put it where a compromise cannot reach the host, rather than betting on the next patch arriving in time.

The identity layer is where a forum bug became a company problem

A community forum is a low-value target in most threat models. It holds discussions, not secrets. That assumption breaks the moment the forum uses a company's own identity provider for login.

Because community.openai.com allowed "Sign in with OpenAI", a server compromise on the forum became a foothold in the identity flow. Hacktron could hijack the ChatGPT and Codex sessions of employees and other active forum members without tricking anyone. The potential reach was wider than ChatGPT: accounts often connect to other services, and the researchers name GitHub, Slack and email among the integrations a hijacked session might touch.

The lesson generalises well beyond OpenAI. Any organisation that lets third-party or community properties authenticate through its corporate identity system has created a path from the least trusted service to the most trusted accounts. Scoping matters here as much as patching. A sign-in token issued for a discussion forum should not carry the authority of an API credential for the company's flagship products, and the fix OpenAI deployed was on that identity configuration, not on Discourse.

The Cyber Kendra report of the disclosure frames the same split: the forum was the entry point, but the escalation that mattered was the trust handed to a session. Reviewing which applications can mint tokens for which audiences, and shortening the life of those tokens, does more for this class of attack than any single server patch.

AI-written exploits changed the pace

Exploit development used to be a bottleneck that favoured defenders. Turning an out-of-bounds primitive into a reliable payload means defeating address space layout randomisation and matching the target's allocator, work that took a specialist days or weeks.

Hacktron's account shows that bottleneck thinning. The team says Claude Opus 4.8 analysed the Discourse image and found that security fixes had not been backported to its libheif package, but it failed to produce a working exploit with ASLR enabled across several sessions. Hours after Anthropic shipped Claude Opus 5, the same prompt produced a working ARM64 exploit in about three hours. The team then had the model port it to the x86-64 and jemalloc layout that Discourse uses, and by early morning on 25 July it had confirmed code execution through an image upload.

The researchers ran the model in an autonomous loop against an instance they controlled, routed to look like a capture-the-flag target, because the model had refused to write an exploit aimed at a live remote system. The same generated script then worked against OpenAI's forum. The detail to carry away is not which model won. It is that the frontier moved from "no working exploit" to "working exploit in three hours" within a single release cycle, and that the hard, repetitive parts of exploitation are exactly the parts an agent can grind through.

What to watch

Three things will decide how much this story matters. The first is whether the rest of the HEIF Heist findings turn into advisories. Hacktron says the same decoder class reached Slack, Meta's core products, Next.js, and GitHub Enterprise Server, where a related flaw is tracked as CVE-2026-19118 and was fixed in version 3.21.5 on 1 September 2026. Vercel disabled AVIF optimisation on its managed service while the upstream fix propagated. If other vendors confirm similar paths, the lesson shifts from one forum to the whole image-processing supply chain.

The second is how quickly downstream consumers actually move. Upstream libheif users are urged to reach 1.23.2 or later, and the latest security release was 1.23.4 as of mid-September 2026. Where HEIF or AVIF decoding is not needed, it should be disabled at the application layer. Where it is, image processing belongs in a hardened, ephemeral sandbox, which is what Discourse now does.

The third is identity scope. The OpenAI finding was patched about 14 hours after the report, and the company paid a $6,500 bounty while noting that the forum testing itself fell outside its bug-bounty scope. That split is a fair reading of where the fault sat, but it also means the most reusable lesson, that a community forum should not be a master key, is still being absorbed across the industry.

Cover: Wikimedia Commons "Person holding the OpenAI icon.jpg" by FoxTPNL, CC BY 4.0 (cropped 16:9).