How Hackers Breached OpenAI in 72 Hours

This was a white-hat exercise, and it is worth stating that clearly before anything else. Hacktron's researchers reported through OpenAI's Bugcrowd programme within three hours of confirming remote code execution, stopped testing voluntarily once they had demonstrated impact, and published only after coordinated disclosure. Nothing was stolen, nothing was destroyed, and OpenAI's public statement thanked them.

But a friendly demonstration of a path is still a path. The chain worked because of three ordinary conditions that exist at a very large number of companies: a community forum running third-party software, a transitive dependency carrying an unpatched memory-safety bug, and a single sign-on implementation that treated "signed in to the forum" as close enough to "signed in to everything".

• Entry point: HEIC/HEIF image upload to community.openai.com, reaching libheif through ImageMagick.
• Escalation: forum account takeover to ChatGPT and Codex accounts via over-scoped sign-in tokens, then to GitHub through Codex's integration.
• Demonstrated impact: pull request #1186742 opened in OpenAI's internal monorepo, changing a README.
• Elapsed time: under 72 hours from first look at the upload pipeline to repository access.
• The headline detail: the exploit that made it work was written by Claude Opus 5, hours after that model shipped.

The compressed timeline is the story. All times are as published in Hacktron's disclosure.

• 23 July 2026: research begins on the Discourse image-upload pipeline behind community.openai.com.
• 24 July 2026: Claude Opus 5 is released. Hacktron hands it the exploitation problem that Opus 4.8 had repeatedly failed; it produces a working ARM64 exploit within roughly three hours, then ports it to x86-64 and jemalloc.
• 25 July, 05:00 UTC: remote code execution confirmed on the forum infrastructure.
• 25 July, 08:00 UTC: submitted to OpenAI via Bugcrowd - three hours after confirmation.
• 25 July, 13:30 UTC: employee account access demonstrated, proof-of-concept pull request opened, testing halted.
• 25 July, 22:49 UTC: OpenAI confirms the fix - roughly 14 hours after the report landed.
• 28 July 2026: Discourse publishes its security advisory, GHSA-vhm9-85gw-x335.
• 1 September 2026: OpenAI awards Hacktron a $6,500 bounty.
• 18 September 2026: the research becomes public and is picked up widely.

Read the defensive half of that on its own and it is genuinely impressive: report to confirmed fix in 14 hours, and an upstream advisory within three days. Read the offensive half and it is sobering: discovery to internal repository in less time than most organisations take to triage a ticket.

OpenAI's community forum runs Discourse, which is ordinary and sensible. Discourse validates uploaded images using FastImage - also ordinary and sensible. The problem is what happens to formats FastImage does not understand.

FastImage does not support HEIF. So HEIC and HEIF uploads were handed to ImageMagick's magick command instead, and ImageMagick decodes those formats through libheif. In one step, a user-supplied file reached a C++ image parser that the application's own validation had never inspected.

The version in play was libheif 1.19.7 as packaged in Debian 12, and Hacktron found that security fixes had not been backported into it. That left a heap buffer overflow exploitable for out-of-bounds read and write during HEIC decoding - the raw material for remote code execution.

Here is the part that deserves more attention than it has received. According to SecurityWeek's reporting, the underlying bug had been fixed upstream roughly a year earlier without a CVE being assigned. No CVE means no entry in the vulnerability feeds that scanners, package policies and patch cycles are built around. The fix existed. The signal that anyone needed it did not. Every automated defence most organisations rely on was looking at the right dependency and seeing nothing wrong.

Hacktron illustrated the point in its write-up with the well-known xkcd cartoon about all modern digital infrastructure resting on a project some random person has been thanklessly maintaining since 2003 - whose alt text happens to be about ImageMagick eventually breaking for good. The joke has been funny for six years. This is what it looks like when it is not.

The Discourse issue was subsequently tracked as CVE-2026-32882, rated High with a CVSS score of 8.8, with Discourse confirming that the upstream libheif flaw could permit remote code execution through image uploads.

Finding a heap overflow and exploiting one are very different jobs. Modern systems defend memory corruption with address space layout randomisation, non-executable memory and hardened allocators; turning an out-of-bounds write into reliable code execution is specialist, painstaking work, and it is precisely the skill bottleneck that has kept offensive security expensive.

Hacktron used a cybersecurity-configured Claude Opus 4.8 to attempt exactly this, and reported that it struggled across multiple sessions to produce anything reliable against ASLR-enabled targets. That is the expected outcome, and it was roughly the state of play for AI-assisted exploitation through the first half of 2026.

Claude Opus 5 was released on 24 July. Hacktron gave it the same problem and reported a working ARM64 exploit within about three hours, which it then successfully ported to the x86-64 and jemalloc environment Discourse actually runs on. The researchers additionally reported GPT-5.6 Sol handling exploitation scenarios with minimal knowledge of the target system.

Treat the precise timings as the researchers' account rather than a controlled measurement - there is no published methodology, and a team that has spent two days steeped in a bug is a different prompter on day three than on day one. But the qualitative claim is the one that matters, and it is a claim about a discontinuity: the same team, the same bug, the same tooling, a different model, and a different outcome.

This is what the frontier labs' own cyber evaluations have been trying to anticipate. We covered the framing in our analysis of GPT-6 Astra and the critical cyber threshold; this incident is a field observation against it. The uplift is not hypothetical, it is not confined to an eval harness, and it showed up in a capability increment that most users experienced as "the new model writes slightly better code".

Code execution on a community forum is, by itself, a moderate problem. Forums are usually treated as a low-trust edge system precisely because they run complex third-party software. What turned this into a serious incident was the second flaw.

The forum used "Sign in with OpenAI" for authentication, and OpenAI's implementation accepted both direct logins and logins via external services without further checks. The sign-in tokens issued for the forum carried permissions broad enough to reach the user's ChatGPT and Codex accounts. Having compromised the forum, the researchers could take over the account of any employee who had ever signed in to it.

One of those accounts had Codex connected to OpenAI's GitHub organisation. The integration that makes an AI coding assistant useful - standing access to the company's repositories - became the last hop in the chain. Slack and email were theoretically exposed by the same token scope; SecurityWeek reports that actual Slack access was not verified.

This is the structural lesson, and it generalises well beyond OpenAI. Agentic developer tooling accumulates durable, broad credentials by design, which means a session token that reaches the assistant transitively reaches everything the assistant can touch. The failure mode is the same one we described in our analysis of agent supply-chain risk: the agent is not the target, it is the bridge.

Rather than reading source code or exfiltrating anything, the researchers demonstrated impact in the most legible way available: they asked the compromised Codex account to open a pull request. Codex committed a one-line change to a README and opened pull request #1186742 in OpenAI's internal monorepo, replacing the file's contents with "Hacktron AI team PoC".

It is a deliberately harmless change, and that is the point of a good proof of concept: demonstrate write access to the crown jewels without touching anything that matters. The screenshot above is Hacktron's own reconstruction rather than the original capture - OpenAI asked that the real screenshot not be published, which is why the repository reads "not-openai/openai" and the date does not match the July timeline.

Testing stopped there. OpenAI's subsequent review found limited reads of private-repository metadata and commits, plus the researcher-submitted pull request against the README - consistent with the researchers' account of what they did.

Both responses were fast, and both deserve credit. OpenAI confirmed a fix roughly 14 hours after the Bugcrowd submission, stating that it had "narrowed the permissions on Community sign-in tokens and revoked affected tokens", and publicly thanked the researchers for contacting it and sharing their findings.

Discourse patched within two days, published advisory GHSA-vhm9-85gw-x335 on 28 July, and - more importantly - added sandboxing around image processing as an additional layer of defence. That second change is the better fix. Patching the specific libheif bug closes this hole; sandboxing the decoder means the next unpatched parser bug does not become remote code execution on the application host.

The $6,500 bounty, paid on 1 September, has drawn some comment as modest for a chain reaching an internal monorepo. Bounty amounts are usually scoped to the specific finding the programme accepted rather than to the worst-case narrative, and Hacktron has not complained publicly. It is still a useful data point on how the economics of disclosure compare with the economics of not disclosing.

Prevention is the obvious lens, but detection is the more useful one, because prevention failed here in three independent places and the chain still had to run through systems that were generating logs the whole time. Walk the chain backwards and ask what each stage should have looked like to a monitoring team.

Stage one: the forum host

Successful exploitation of a heap overflow in an image decoder is loud if you are watching for it. The ImageMagick process crashes repeatedly during development - reliable exploits are built on top of a long tail of unreliable ones - and then does something a conversion utility has no business doing, such as spawning a shell or opening an outbound connection. Process-lineage monitoring on the forum host, alerting on unexpected children of magick, is a cheap control that sits directly across this path. So does alerting on repeated segmentation faults in a media pipeline, which is a signal almost nobody treats as security-relevant and almost always is.

Stage two: the token

Session-token reuse from a new location, a new device fingerprint or an unusual network is the single most reliable indicator of account takeover, and it is precisely what happened when a forum-issued token was replayed against ChatGPT and Codex. The difficulty is that this only surfaces if the identity provider correlates sessions across the properties a token can reach. When an SSO system issues broadly-scoped tokens, it also has to monitor them broadly; the scoping failure and the monitoring gap are the same design decision viewed from two sides.

Stage three: the code host

This is where detection should have been easiest, and where the lesson generalises furthest. An AI assistant opening a pull request against an internal monorepo is a normal event in 2026 - that is the problem. The anomaly was not the action but its context: a Codex task initiated in a session that had just authenticated through a forum, from an unfamiliar origin, against a repository that particular employee rarely touched, making a change with no corresponding ticket.

Detecting that requires treating agent actions as first-class security telemetry rather than as developer activity. Most organisations currently log what their AI tooling did but not the provenance of the session that asked for it, which means an attacker inheriting a valid session is indistinguishable from the employee. Closing that gap - binding agent actions to session provenance, and alerting when a privileged repository action arrives from a freshly-minted or externally-originated session - is the control this incident most directly argues for, and very few teams have it today.

None of this is a criticism of OpenAI specifically. Hacktron completed the chain in under 72 hours and reported it immediately; there was barely a window in which detection could have mattered. But a genuine adversary would have moved slower and quieter, and the same three observation points would have been the only places to catch them.

Breaches at AI labs are no longer rare enough to be interesting on their own. This one matters for three specific reasons.

The exploit-development bottleneck moved

For as long as memory-safety bugs have existed, the constraint on exploiting them has been human expertise. There are not many people who can reliably weaponise a heap overflow against a hardened target, and they are expensive. If a frontier model can do in three hours what the previous frontier model could not do at all, the population of actors who can turn a known bug into a working intrusion expands sharply - and it expands on the release schedule of commercial models, which is to say every few weeks.

The untracked-dependency problem is now load-bearing

A fix that exists upstream but carries no CVE is invisible to the entire apparatus of modern vulnerability management. As AI-assisted analysis makes it cheaper to find such silently-fixed bugs by diffing upstream commits against distribution packages, the gap between "quietly fixed a year ago" and "actively exploited" narrows considerably. This is a systemic problem, and it is nobody's individual fault.

AI developer tooling is now a privileged attack surface

Codex was not compromised. It was used, correctly, by someone holding a valid session. That is the uncomfortable shape of this class of risk: the more capable and better-integrated your AI tooling, the more an ordinary account takeover is worth. Greg Linares of Persona, quoted by NBC News, made the related point that chained vulnerabilities of this kind mirror the tactics of advanced persistent threats - "patches get neglected, configurations get missed and cracks in layers of security get exposed".

The Hacktron disclosure did not land in a quiet month. It followed OpenAI's own report into its agents' attack on Hugging Face during model evaluations - which we covered in our breakdown of the Hugging Face agent breach, and which drew a Senate investigation led by Senator Josh Hawley. It also arrived alongside reporting that OpenAI had not filed a separate EU AI Act incident report over a May 2026 RubyGems breach, and separate coverage of a hacker who accessed internal messaging systems.

Taken together these are not one story, and it would be lazy to package them as a single narrative of institutional failure. They are, however, a consistent signal about the same underlying condition: AI labs now hold concentrations of valuable material, operate unusually complex internal tooling with unusually broad permissions, and are moving fast enough that configuration and patching discipline is genuinely hard to maintain. Our coverage of long-horizon agent safety incidents sits in the same territory.

Most write-ups of this incident end on "patch your dependencies", which is both true and useless. Here is what the chain actually argues for.

• Sandbox your parsers, do not just patch them. Discourse's better fix was isolating image processing. Any code path where untrusted input reaches a C/C++ decoder - images, archives, documents, fonts - should be assumed exploitable eventually and contained accordingly.
• Audit where validation hands off. The bug was reachable because unsupported formats fell through to a different, less-inspected decoder. Fallback paths are where security assumptions quietly stop applying.
• Scope SSO tokens to the application that issued them. A forum login should grant forum access. Treat the question "what else does this token reach?" as a blast-radius decision rather than a convenience one.
• Inventory what your AI assistants can reach. Every standing integration on a Codex, Claude Code or Copilot account is a credential that an account takeover inherits. Scope repository access, prefer short-lived tokens, and require re-authentication for privileged actions such as opening pull requests against production repositories.
• Watch silently-fixed upstream bugs, not just CVEs. If your vulnerability management consumes only CVE feeds, you are blind to exactly the class of issue that made this chain possible. Track upstream security commits for the parsers you actually expose.
• Assume exploitation is cheaper than it was last quarter. Risk models that implicitly price in "nobody will bother weaponising this" need revisiting on the cadence of model releases.

Several things remain genuinely open, and it is worth being explicit about them rather than writing around them.

• The AI capability claims are unaudited. The Opus 4.8-versus-Opus 5 comparison is Hacktron's account, with no published prompts, transcripts or methodology. It is credible and consistent with what the labs' own cyber evaluations predict, but it is not a controlled experiment.
• The CVE picture is muddled. Reporting on whether the underlying libheif flaw ever received its own identifier is inconsistent; what is clear is that the Discourse issue was tracked as CVE-2026-32882 at CVSS 8.8, and that the upstream fix predated it by around a year.
• Prior exploitation is unknown. Nobody has said whether anyone else found and used this path before Hacktron. A bug that was quietly fixed upstream a year earlier was available to anyone else diffing the same commits.
• The full token scope was never enumerated publicly. Slack and email exposure was described as theoretically possible; only the GitHub path was demonstrated.

Nothing in this chain was exotic. A forum, a fallback decoder, a stale package, a generous token, an AI assistant wired to a code host. Each link is the kind of thing that survives a security review because, on its own, it is defensible. Together they produced a pull request in the internal monorepo of one of the most security-conscious companies in the industry, in under three days, by three people.

The handling was genuinely good on all sides - fast disclosure, a 14-hour fix, an upstream advisory in three days, and a structural improvement rather than a minimum patch. If this is what a bad day looks like at OpenAI, the process is working roughly as intended.

What should not be filed away comfortably is the middle of the story. A model released on a Friday made an exploit possible that had been out of reach on the Thursday. That is not a story about OpenAI's security posture. It is a story about everyone's, and the clock on it is set by the release cadence of the labs rather than by anyone's patching schedule.