Three researchers walked into OpenAI's help forum with an innocent-looking image file. Under 72 hours later they had taken over the ChatGPT and Codex accounts of several OpenAI employees and reached an internal code repository. They never guessed a password. They never phished anyone. They just chained two flaws that, on their own, looked like somebody else's problem. That is the part every founder and CTO should sit with.
What actually happened
The team at security firm Hacktron reported the chain themselves, proved the access with a harmless pull request, and stopped. OpenAI shipped a fix about 14 hours after the report and paid a $6,500 bounty on September 1. This was good, disciplined research, not a breach in the wild. But the mechanics are a masterclass in how modern intrusion chains work, and the shape of it is something you can test for in your own estate this week.
The chain started in Discourse, the open-source software that runs OpenAI's public forum. Discourse hands uploaded HEIC and HEIF images to ImageMagick, which in turn uses the libheif library to decode them. A flaw in libheif let a crafted image corrupt the forum server's memory. From there, the researchers escalated to code execution on the forum host.
That is act one. Act two is where things get uncomfortable.
A forum bug should not reach staff accounts
The reason a bug in a public forum reached OpenAI staff has nothing to do with the forum software. The forum offers a "Sign in with OpenAI" option, the same single sign-on that staff use everywhere else. Once the researchers controlled the forum server, that shared login let them take over the ChatGPT and Codex accounts of forum members who happened to work at OpenAI. The victims did nothing wrong. They did not need to click anything.
Hacktron's own framing is blunt: this was an identity architecture problem, not a Discourse problem. Any first- or third-party service riding the same sign-on would have handed over the same reach. And because staff connect tools like GitHub, Slack, and email to ChatGPT and Codex, the same access could in theory have spread further. The team says they did not use that wider reach, but the door was open.
That is the lesson worth pasting above your desk: your SSO is not a convenience feature. It is your blast radius.
The patch that existed in May, and the image that did not have it
Here is the part that stings. The libheif flaw was fixed upstream in libheif 1.22.0 back in May 2026. The CVE was public. And yet when the researchers looked in July, the Discourse server image, built on Debian 12, was still shipping libheif 1.19.7. The fix existed; it simply had not made it into the packaged version the platform used.
This is not exotic. It is the quiet, mundane failure mode hiding in thousands of container images right now: your application code is fresh, your base image is not. Rebuilding from the latest image is not the same as running a web-interface update, and for self-hosted Discourse, the fixed releases are 2026.7.0, 2026.6.1, 2026.5.2, and 2026.1.6. Discourse-hosted sites were already patched. If you self-host, rebuild.
The takeaway is not "patch faster." It is "know what is actually inside the artifact you deploy," which is a different question from what your scanner reports against your package manifest.
What AI changed here
The researchers used AI to do the hard part. Claude Opus 4.8 struggled across sessions to build a working exploit once address space layout randomization (ASLR) was enabled. Then Anthropic released Claude Opus 5 on the evening of July 24, and in a fresh session it produced a working exploit within hours.
Opus 5 shipped with safeguards against writing exploit code for real targets. The team worked around them by pointing the model at their own test server, framed as a capture-the-flag practice range, then letting it run in an automated loop. They are careful to say this was not hands-off hacking: skilled human direction still mattered. But the hours-to-working-exploit jump across a single model release is the signal.
The reported cost of the broader campaign, which Hacktron calls HEIF Heist, was under $3,000 in AI usage over roughly two months. That campaign hunted the same class of image-decoding flaws across software used by other large companies, with unconfirmed links to reported bugs in Slack, Meta products, GitHub Enterprise, and frameworks like Next.js. The Next.js flaw is confirmed in Vercel's own advisory, and libheif's maintainers confirmed a working exploit for the bug tied to Meta; the wider claims have not been independently verified. The team also says only one company, Shopify, appears to have noticed the activity, even as its image processors crashed repeatedly under thousands of test uploads.
Three questions to ask this week
- Which third-party services hold sign-on grants into your core accounts? If a marketing forum, a support portal, or a partner tool shares your identity provider, it is inside your trust boundary. Inventory it, and treat anything that can mint a session for a privileged account as Tier-0.
- Do your deployed images carry libraries older than their upstream fixes? Scan the running artifact, not just the manifest. Compare what is actually installed against upstream release notes, and rebuild base images on a schedule that matches the speed of disclosure.
- Would you notice a chained, low-noise campaign? Shopify noticed because its image processors kept falling over. Most teams would see nothing. Detection that only watches for known-bad signatures will not catch a researcher (or an attacker) combining two medium bugs into one very bad day.
None of this requires heroics. It requires treating identity as infrastructure, artifacts as untrusted until proven current, and the gap between disclosure and exploitation as something measured in hours, not quarters. The OpenAI chain took under 72 hours with a handful of people and a modest AI budget. Assume the next one will be faster.