It Took Three People 72 Hours to Break Into OpenAI. The Hard Part Was Waiting for Claude to Get an Upgrade.

For two days in late July, the hardest part of breaking into OpenAI was waiting for a better model to come out.

That is not a joke, and it is close to a direct reading of the timeline. A three-person team at Hacktron AI had a memory-corruption bug, a plausible path from a public forum into OpenAI employee accounts, and a version of Claude that kept failing to turn the first into a working attack. Then Anthropic shipped Claude Opus 5 that evening. They handed it the same problem. By the next morning they had code execution running through an uploaded photo, and within hours they were inside OpenAI.

The whole thing, from first look to a pull request sitting in OpenAI's internal repository, took under 72 hours.

The way in was a photo, and the door was never really OpenAI's

The entry point was community.openai.com, OpenAI's help forum. It runs on Discourse, the same open-source software thousands of companies use for their community sites. Nothing exotic.

Hacktron's Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini noticed that the forum treated Apple's HEIC and HEIF image formats differently from everything else. The usual image checker did not support them, so those uploads got quietly routed to ImageMagick, which handed them to a decoding library called libheif. That library carried a heap buffer overflow, the kind of bug that lets carefully shaped input run off the end of its buffer and start rewriting memory it should never touch.

Here is the detail that should make every security team uncomfortable. The bug had already been fixed upstream about a year earlier. But the fix was filed as a routine cleanup commit, not flagged as a security patch, and never got a CVE. Without that label, the fix did not flow through the normal security channels. Debian 12 shipped the vulnerable version. Debian 13 shipped a vulnerable version too, and Debian did not publish its update until August 8. Discourse's Docker image was built on Debian 12, so it inherited the hole and did not know it.

So the first foothold was not a flaw in an OpenAI product at all. It was a stale dependency that a large slice of the internet was also running.

The flaw that actually belonged to OpenAI was the boring one

Code execution on a forum is embarrassing. It is not a breach of OpenAI. The second bug is the one that turned a forum compromise into an OpenAI compromise, and it is far less flashy than the first.

The forum offered "Sign in with OpenAI." Because OpenAI's single sign-on setup accepted logins without enough additional checking, Hacktron could take over the OpenAI account of essentially anyone who had ever logged into the forum. No action required from the victim.

Once you hold someone's ChatGPT or Codex account, you hold whatever they connected to it. GitHub. Slack. Gmail. Google Drive. One compromised employee had wired Codex into OpenAI's GitHub organization. To prove the access was real without reading a line of internal code, the team told that employee's Codex to open a pull request in OpenAI's private monorepo, then stopped.

Hacktron is careful, and correct, to underline that the escalation was not a Discourse problem. It was OpenAI's identity configuration. The forum was just a convenient thing to break in order to demonstrate it. Any first-party or third-party service behind that same login would have worked as the entry point.

Name the pattern: expertise is turning into compute

This is where the story stops being about OpenAI and starts being about everyone.

The team began with Claude Opus 4.8. They pointed it at the Discourse Docker image and asked it to look for security problems in the installed libheif package. It found the missing backport and built a working exploit, but only with ASLR turned off. ASLR is a standard defense that randomizes where things sit in memory. With it on, the way real servers run, Opus 4.8 stalled across multiple sessions.

Then Opus 5 landed. A fresh session produced a working exploit for a local Mac in about three hours, then ported it to the environment Discourse actually uses. Within hours of a model's public release, a bug that had resisted the previous model became a reliable weapon.

There is a revealing wrinkle. Opus refused to write an exploit aimed at a remote server. So the team dressed up their own test instance to look like a capture-the-flag challenge and pointed the model at that instead. The guardrail fired. A relabeling exercise walked around it.

Zoom out and the economics are the actual headline. Hacktron says the broader campaign, which turned the same technique loose on Slack, Meta, and others under a project they call HEIF Heist, ran two months, cost under $3,000 in tokens, and was done by three people. Adapting the attack to each new target usually took a day or two. Across thousands of malformed images sent at major companies, they say only one, Shopify, seems to have noticed.

Security researchers have long relied on something like security through scarcity. A bug could be public, the vulnerability could be understood, and it still did not matter much, because turning it into a reliable exploit demanded rare skill, real time, and knowledge of the target. That friction is not a real boundary. It just priced most attackers out. AI is converting that scarce skill into something you can buy by the token, and the friction is collapsing.

The $6,500 number is going to start an argument

The disclosure itself was clean, and worth crediting. OpenAI patched its side of the flaw roughly 14 hours after the report. Discourse got its separate report on a Saturday, replied Sunday, shipped a fix Monday, and published an advisory that added sandboxing around ImageMagick as a second layer of defense. This is coordinated disclosure working the way it is supposed to.

Then comes the payout. OpenAI awarded Hacktron $6,500, and pointed out that testing the Discourse-hosted forum was explicitly out of scope for its program. The money was for the OpenAI-side SSO finding, not for popping the Discourse host.

By the letter of the program, that is defensible. Sitting next to the phrase "opened a pull request in the internal monorepo," it looks like pocket change. And it exposes a real gap in how bounty programs are built. These programs assume a bug lives inside one company's clearly bounded product. This attack lived in the seams: a third-party library, a third-party platform, and an identity flaw that only became catastrophic once the other two were chained to it. No single party owned the whole path, so no single scope priced it correctly.

What defenders should take from this

The fixes Hacktron lands on are unglamorous, which is the point.

Stop trusting that upstream package updates will reach you in time. This entire chain existed because a real security fix was never labeled as one. Isolate untrusted image decoding inside hardened, disposable sandboxes, or turn off HEIF and AVIF parsing where you do not need it. And treat your identity provider as a single point of catastrophic failure, because it is. If a compromise of any one service behind your SSO becomes a compromise of all of them, you do not have a login system, you have a blast radius.

The uncomfortable part is that none of the underlying flaws here were sophisticated. A stale library. A permissive login. The sophistication was rented, released on a Tuesday, and pointed at the problem overnight.