Three researchers reached a pull request inside OpenAI's private code repository in under 72 hours. They did it with Anthropic's Claude, a rival lab's model, and OpenAI paid them $6,500.
The rival-lab framing is the headline. The detail that matters is quieter. The attack chain had nine links, and only one of them belonged to OpenAI. The other eight were third-party software, an image library, a forum, a conversion pipeline. The one that was OpenAI's own was an authentication flaw, and it was reviewable code.
This article walks the full chain, separates the part OpenAI could have caught from the part it inherited.
And explains why the single link that was reviewable is the one that turned a forum bug into internal code access.
It is written for engineers, and every technical claim is sourced.
Why this is on a code-review company's blog: eight of the nine links were somebody else's code. The ninth, the one that made the breach reach OpenAI's monorepo, was a session token that stayed valid where it should not have. CodeAnt AI reads authentication flows and dependency risk in the pull request, which is where that one reviewable link would have surfaced.
Meanwhile, check out our complete guide to using CodeAnt AI for pull request reviews.
How Claude Helped Researchers Reach OpenAI's Internal Code
The research, published by Hacktron AI in September 2026 and first reported by the Wall Street Journal, documents a nine-step chain. Here it is in order.
The entry point was an image upload. OpenAI's community forum at community.openai.com runs on Discourse, a widely used third-party forum platform. When a user uploaded a HEIC or HEIF image, the format iPhones use by default, Discourse routed it through a conversion pipeline to turn it into a standard JPEG.
The pipeline reached a vulnerable library. The first tool in that pipeline was ImageMagick, a decades-old image utility. Because ImageMagick cannot decode Apple's format itself, it handed the file to libheif, a native decoding library. libheif version 1.19.7 contained a heap buffer overflow, tracked as CVE-2026-32882, that was exploitable for remote code execution.
Claude wrote the exploit, on the second attempt. The researchers first tried Claude Opus 4.8 to develop a working exploit. Address space layout randomisation, a standard memory protection, defeated it, and the model could only succeed with that protection disabled. Anthropic shipped Claude Opus 5 on the evening of July 24, 2026. The team switched models, and the newer version produced a working exploit within hours.
A malicious image became code execution. A crafted HEIC image, uploaded to the forum, now ran the attacker's code on OpenAI's Discourse instance. That is remote code execution on a public-facing forum, which on its own is a forum problem.
This is where it became OpenAI's problem. The researchers found that a session token issued by the forum remained valid for ChatGPT and Codex. A login scoped to a help forum was being honoured by unrelated production applications.
The token led to an employee's Codex. Using that token reuse, the team reached an OpenAI employee's Codex account. Codex was connected to OpenAI's GitHub organisation.
Codex led to the monorepo. From the compromised Codex account, they had a path into OpenAI's internal code repository.
They proved it and stopped. Rather than read any internal code, they had Codex open a harmless pull request in OpenAI's internal monorepo, as proof of access, and then halted testing.
The whole path, from first look at the forum's image pipeline to a pull request in the monorepo, took under 72 hours.
Only One of the Nine Links Was OpenAI's Own Code
This is the point the rival-lab headline buries, and it is the one that matters for defenders. Walk the chain again and sort each link by owner. The forum software was Discourse. The conversion utility was ImageMagick.
The vulnerable decoder was libheif. The image format was Apple's. The exploit tooling was Anthropic's. None of those is OpenAI's code. The link that was OpenAI's own is the session token that stayed valid across applications. A token issued for the community forum should never have been accepted by ChatGPT and Codex.
That is a broken authentication and session management flaw, it lives in OpenAI's own auth configuration, and it is the hinge the entire breach turned on. Remove that one link and the chain stops at a compromised forum. Serious, but contained.
It was the token reuse that carried remote code execution on a third-party forum all the way into internal developer infrastructure. That asymmetry is the lesson. You cannot patch libheif's bugs, or Discourse's, or ImageMagick's, on your own schedule.
You can review your own authentication boundaries, and OpenAI's own boundary is precisely what turned an inherited third-party bug into an incident with OpenAI's name on it. OpenAI's own framing supports this reading.
When it paid the bounty, it clarified that testing against the Discourse-hosted forum was explicitly excluded from its bug bounty program, and that the award recognised the finding on OpenAI's side. OpenAI has since narrowed its SSO token permissions.
The Session Token Flaw That Turned a Forum Bug Into Internal Access
A session token is a claim about who you are and what you may access. When the forum issued a token, that token should have carried a scope that said, in effect, this is a forum session and nothing more. Instead the token was honoured by ChatGPT and Codex, which means the scope was either too broad or not checked at the boundary of those applications.
Either way, it is a design decision visible in code and configuration. This is the OWASP category of broken authentication, and specifically a session management failure. The questions it raises are the questions a review asks.
Does a token issued by one service carry a scope that limits it to that service?
Do downstream applications validate that scope before honouring the token?
Is the trust between a low-value property like a help forum and a high-value property like a code assistant made explicit, and is it minimal?
Every one of those is answerable by reading the authentication flow. None of them requires waiting for an attacker, or a rival's model, to demonstrate the gap.
The Part Nobody Wants to Hear: Offense is Now Compute
The reason this story travelled is the model detail, and it deserves an honest treatment rather than a dismissal. Claude Opus 4.8 could not land the exploit against standard memory protections. Opus 5 shipped that evening and produced a working exploit within hours.
Same researchers, same bug, one model version apart. The whole two-month research campaign across multiple platforms cost the team under $3,000 in model tokens. Memory-corruption exploitation has traditionally required specialised expertise and substantial manual effort. That is precisely the barrier that just moved.
The incremental, tedious work of exploit development is the kind of task frontier coding agents increasingly perform under human direction. The uncomfortable framing is that an exploit is becoming less a rare skill and more a function of which model you can run.
Offense did not get smarter in some abstract sense. It got cheaper, faster, and more available, and it will keep doing so with each model release.
For a defender, that changes the arithmetic. The reviewable weaknesses in your own code, the ones that were technically exploitable but tedious enough that nobody bothered, are now worth an automated attacker's time. The bar the attacker has to clear just dropped, which means the bar you have to clear on your own reviewable code just rose.
What This Means for Anything that Accepts an Image
There is a concrete, immediate takeaway separate from the OpenAI specifics. If your product accepts a user-uploaded HEIC, HEIF, or AVIF file and processes it through ImageMagick, libvips, or sharp, you share the attack surface this research targeted.
The libheif project published dozens of security advisories during 2026, and its later releases included additional high-severity fixes. The direct action is to upgrade libheif to a current version and to sandbox image processing, which is the additional defense Discourse itself added in response.
But the deeper point is about the dependency, not the one library. libheif is a native decoder almost nobody installs deliberately. It arrives transitively, pulled in by an image tool, pulled in by a framework, several layers below anything a developer chose.
That is the dependency supply chain, and a vulnerable component several layers deep is invisible unless something is specifically looking for it.
How CodeAnt AI Would Have Read this Chain
Being precise is more useful than being expansive, so this is stated by link. CodeAnt does not patch libheif, and it is not an image sandbox. The third-party links in this chain are upstream problems with upstream fixes.
What CodeAnt covers is the two links that were reviewable in code, which are the ones that determined whether the breach reached OpenAI at all.
The authentication flaw, at the pull request. AI code review reads each change with the context of the surrounding code, which is where a session scope that is too broad, or a downstream application that fails to validate token scope, becomes visible. The token-reuse flaw was a design decision in OpenAI's own code, and design decisions in auth flows are exactly what a review is positioned to question before they ship.
The dependency risk, continuously. The vulnerable libheif version was a known-bad component sitting transitively in a dependency tree. Software composition analysis that reads the full tree, not just the top-level manifest, is what surfaces a decoder several layers deep. Correlated against the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS scoring, a transitively included CVE with a public exploit is exactly the kind of finding that should be ranked to the top.
The chain itself, proven not guessed. The reason this breach is instructive is that no single finding looked alarming alone. A forum bug, a broad token, a connected Codex. The AI penetration testing pipeline exists to chain findings into a proven path rather than rate them in isolation, on the principle that a detected vulnerability is not a confirmed leak. Severity lived in the chain here, not in any one link.
The track record is the relevant credential.
CodeAnt has found 150+ CVEs, including a CVSS 10.0 vulnerability in pac4j that went undetected for six years, across projects representing 2B+ monthly downloads protected.
That pac4j finding is the same shape as this incident. Every component behaved correctly on its own, and the vulnerability lived where they met.
Why Penetration Testing Needs to Chain Findings
This incident is the clearest recent argument for testing that chains rather than scores. A traditional scan of OpenAI's forum would have found a Discourse instance. A separate scan of the auth configuration might have noted a broad token.
A dependency scan would have listed libheif. Three findings, three tickets, three different severities, and no indication that together they reach an internal monorepo. A penetration test built to chain asks the question the scans cannot. Starting from the external surface, where does this actually lead?
That is the question that connects a forum image upload to internal developer infrastructure, and it is the question Hacktron answered on OpenAI's behalf, for free, in under 72 hours. The two halves compose. Review catches the reviewable link, the broad token, before it ships.
Chaining pentest finds how an inherited third-party bug reaches something that matters, so the transitive dependency and the auth boundary are tested as one path rather than three unrelated findings. The framing worth keeping. Hacktron ran the attacker's playbook against OpenAI and proved the chain.
The rational response for any team is to run that same chaining analysis against yourself first, before a research group, or a less friendly party with the next model, runs it against you.
How to Defend Against AI-Assisted Attack Chains
Six actions, ordered by how directly they address this chain.
Review session and token scope explicitly. A token issued by one service should not be honoured by another. Make the trust between properties minimal and explicit, and validate scope at every boundary that accepts a token.
Read your full dependency tree, not just the manifest. The library that gets you is the one four layers down that nobody chose. Native decoders and media libraries are a recurring source of memory-corruption bugs.
Upgrade and sandbox image processing. If you accept HEIC, HEIF, or AVIF, upgrade libheif and isolate the processing, as Discourse did.
Test for chains, not just findings. A list of unrelated findings hides the path that connects them. Prioritise reachability over isolated severity.
Assume exploit development is cheap now. The tedious weaknesses you deprioritised because exploiting them was hard are back in scope, because the cost of exploiting them just fell.
Run the attacker's chaining analysis on yourself. Find the path from your external surface to your crown jewels before someone with the next model does.
FAQ
How did researchers hack OpenAI with Claude?
Hacktron AI chained a heap buffer overflow in the libheif image library, tracked as CVE-2026-32882, into remote code execution on OpenAI's Discourse-based community forum. Claude Opus 5 wrote the working exploit after Claude Opus 4.8 could not defeat standard memory protections.
They then found that the forum's session token remained valid for ChatGPT and Codex, used it to reach an employee's Codex account connected to OpenAI's GitHub.
And opened a harmless pull request in the internal monorepo as proof.
OpenAI paid a $6,500 bounty.
Was the vulnerability in OpenAI's code?
Mostly not. Eight of the nine links in the chain were third-party software, including Discourse, ImageMagick, and libheif.
The one link that was OpenAI's own was an authentication flaw, a session token issued by the forum that stayed valid for ChatGPT and Codex.
That single reviewable link is what carried a third-party forum compromise into OpenAI's internal infrastructure. OpenAI has since narrowed its SSO token permissions.
Why did Claude Opus 5 succeed where Opus 4.8 failed?
According to the researchers, Opus 4.8 could not produce a reliable exploit against address space layout randomisation, a standard memory protection, and could only succeed with that protection disabled.
Opus 5, released the same evening, produced a working exploit within hours.
The significance is that memory-corruption exploitation has traditionally required specialised human expertise, and a single model release moved that capability.
The entire multi-platform research campaign cost under $3,000 in model tokens.
What is a session token reuse vulnerability?
It is a session management flaw where a token issued by one application is accepted by another that should not trust it.
In this case, a login to OpenAI's help forum produced a token that ChatGPT and Codex honoured, so compromising the low-value forum granted access to high-value production applications.
The fix is to scope tokens to the service that issued them and to validate that scope at every application boundary. It is a reviewable design decision, catchable in code before it ships.
How do you defend against AI-written exploits?
You cannot lower the attacker's capability, so you raise the cost of the weaknesses they target. Since exploit development is now cheap, the reviewable weaknesses in your own code carry more risk than before.
The practical response is to review authentication and session boundaries closely, read your full dependency tree for transitively included vulnerable libraries.
And test for chains that connect your external surface to critical systems, rather than rating findings in isolation.
Where This Leaves You?
This story will be remembered as the time a rival's AI hacked OpenAI. That framing is fun and it misses the operational lesson. Nine links, eight of them somebody else's code, one of them OpenAI's own reviewable authentication flaw. The inherited bugs made the entry. The reviewable one made it reach the monorepo.
You cannot fix the world's libraries, but you can review your own auth boundaries and your own dependency tree, which is exactly where the decisive link lived.
The next model will not raise your bar. It lowers the attacker's. The question is whether the one reviewable link in your own chain would survive a pull request, because the attacker no longer has to be talented. It only has to be recent.
Sources
TechCrunch, Researchers used Anthropic's Claude to hack into OpenAI, September 18, 2026
The Register, Researchers used Claude to hack OpenAI employees' ChatGPT accounts, September 18, 2026
VentureBeat, OpenAI hacked by small team of white hat security researchers using Anthropic's Claude Opus 5, September 18, 2026
Quartz, Hackers used Claude to break into OpenAI's internal code repo, September 19, 2026
