How Researchers Hacked OpenAI Using Anthropic's Claude Opus 5

A three-person security shop called Hacktron chained an image-parsing bug on OpenAI's community forum to an SSO flaw and ended up with a working proof-of-concept pull request inside OpenAI's private GitHub monorepo, using Anthropic's Claude to build the exploit. The team disclosed the details publicly this morning, describing a path from "upload one photo" to "control of an OpenAI employee's Codex account" that took under 72 hours from first look to remote code execution.

• Hacktron found a heap buffer overflow in libheif, the library Discourse (OpenAI's forum software) uses to convert iPhone HEIC photos into JPEGs.
• Claude Opus 4.8 couldn't turn the bug into a working exploit across several attempts; Claude Opus 5, released the same week, built a working ARM64 exploit in about three hours and ported it to Discourse's actual x86-64 setup shortly after.
• The exploit gave the team code execution on OpenAI's forum server, then account takeover on OpenAI employees who had linked their ChatGPT and Codex logins to the forum.
• OpenAI confirmed the fix 14 hours after the report landed and paid a $6,500 bounty; Discourse patched the underlying library two days later.

What did Hacktron actually break into?

The entry point was mundane: a photo upload. OpenAI's public support forum runs on Discourse, and when someone uploads an iPhone photo in Apple's HEIC format, Discourse hands it to ImageMagick and libheif to convert it into a normal JPEG before displaying it. Hacktron found a heap overflow in that conversion path, one that had technically been fixed upstream in libheif over a year earlier, just never flagged as a security fix and never assigned a CVE number. Discourse's Docker image was still running the vulnerable version because nothing told anyone it needed updating.

RelatedOne GitHub issue, RCE on Claude Code and Gemini CLI runners

Getting code execution on a forum server isn't nothing, but it's also not "we're inside OpenAI." The second half of the chain did that: a misconfigured single sign-on setup on OpenAI's identity infrastructure let the researchers pivot from server access to actually taking over the accounts of OpenAI employees who used the forum, including their linked ChatGPT and Codex logins. From there, one compromised employee's GitHub-connected Codex account gave them a path into openai/openai, the company's internal monorepo.

Why couldn't Opus 4.8 do this, but Opus 5 could?

This is the detail Hacktron leads with, and it's the real story underneath the OpenAI headline. The team had the vulnerable code path identified before Opus 5 existed. They pointed Claude Opus 4.8 at it and it kept failing, unable to reliably build a working exploit against a target with ASLR (address space layout randomization, a standard defense that randomizes where code sits in memory) turned on. Address-space randomization is exactly the kind of thing that used to require a human exploit developer's intuition to defeat.

Then Anthropic shipped Opus 5. Hacktron gave it the identical problem, and within about three hours it had a working ARM64 proof-of-concept, memory corruption bug turned into reliable code execution. The team then used the model again to port that exploit to the actual production environment, Discourse's x86-64 servers running jemalloc instead of the default allocator, a nontrivial retargeting job on its own. Later in what Hacktron describes as a broader research campaign, they saw a comparable jump with another frontier model, needing to build a working exploit with zero knowledge of the target system beyond "it's vulnerable somewhere." That's a different category of task than writing code from a spec.

What did OpenAI and Discourse actually lose?

Nothing sensitive, by Hacktron's account and OpenAI's own statement, but the access was real. The team demonstrated their reach by opening pull request #1186742 in openai/openai using the compromised employee's Codex-linked GitHub credentials, a deliberately harmless change meant purely as proof they were inside, which OpenAI has since had redacted. They say they stopped short of reading anything sensitive in the codebase. OpenAI's own comment, framing the $6,500 payout, was that it covered "the OpenAI-side finding, not the actions against Discourse," since testing Discourse itself falls outside OpenAI's bug bounty scope, a distinction that matters more to a bounty program's terms than to anyone assessing how bad this could have been in less careful hands.

The libheif fix shipped from Discourse on July 27, two days after the report, and OpenAI's own confirmation came back in 14 hours, both genuinely fast turnarounds for a chain that started with a server-side RCE. Discourse's security advisory for the bug is GHSA-vhm9-85gw-x335.

RelatedOpenAI Agents Quietly Attacked RubyGems Before Hugging Face Hack

1. Jul 23Hacktron starts reviewing Discourse's HEIC-to-JPEG image pipeline.
2. Jul 24Claude Opus 5 ships; within hours it builds a working ARM64 exploit for the libheif bug.
3. Jul 25, ~05:00-06:00 UTCRemote code execution achieved on community.openai.com.
4. Jul 25, ~08:00-10:00 UTCVulnerability reported to OpenAI via Bugcrowd.
5. Jul 25, ~13:30-15:30 UTCProof-of-concept pull request opened in OpenAI's internal monorepo.
6. Jul 25, 22:49 UTCOpenAI confirms the fix, 14 hours after the report.
7. Jul 27Discourse ships a patch for the libheif dependency.
8. Jul 28Discourse publishes advisory GHSA-vhm9-85gw-x335.
9. Sep 1OpenAI pays Hacktron a $6,500 bounty.
10. Sep 18Hacktron publishes the full write-up, nearly two months later.

Why does an AI lab's own forum software matter this much?

Because it's a pattern, not a one-off. Support forums, community boards and internal wikis are the software equivalent of a side door: rarely audited as carefully as the core product, frequently running third-party packages like Discourse that quietly depend on libraries like libheif, and often connected to real employee identity via SSO for convenience. Hacktron says the same libheif research line extended well beyond OpenAI, into Slack, Meta, Zoom, Shopify and GitHub Enterprise, which suggests this specific memory bug had been sitting unassigned and unpatched across a meaningful slice of the software everyone's forums and support tools quietly run on.

The part that should worry security teams more than the bug itself is what changed the outcome: not a new finding by the humans, but a new model release landing mid-engagement. The vulnerability was identical before and after Opus 5 shipped. What changed was whether an AI system could turn "we found a heap overflow" into "we have RCE" without a human exploit developer doing the hard part. That capability jump happened in a single week, publicly, for anyone with API access to a frontier model.

Our take

The headline write-ups are going to lead with "hackers breached OpenAI," and that's technically accurate but misses what's actually new here. This was authorized, disclosed research from a paid bug bounty program, resolved inside a week, with a redacted harmless PR as the only proof of access. Nobody's data leaked. The genuinely notable part is buried in the timeline: a security team hit a wall with one Claude model, waited a few hours for the next one to ship, and cleared the wall. That's not a story about OpenAI's forum software being sloppy, plenty of companies run outdated Discourse images. It's a story about how much of an exploit chain's difficulty now sits inside the model rather than inside the researcher, and how fast that difficulty can drop to zero when a lab ships an upgrade.

Original analysis by GenZTech Team, based on Hacktron's published research.