Hackers Used Claude to Build an Exploit Chain That Breached OpenAI's Internal Systems
A team of white-hat hackers from cybersecurity startup Hackron AI breached OpenAI's internal infrastructure using Anthropic's Claude to generate the exploit code, gaining access to employee accounts, the company's private codebase, and enough proof to submit a pull request to an internal repository. The researchers reported the vulnerabilities to OpenAI, which fixed the issue within 14 hours and paid a $6,500 bounty.
The breach, which occurred on July 25 and was disclosed publicly on September 18, demonstrates how quickly AI models can turn a known vulnerability into a working exploit chain. The researchers did not manually reverse-engineer the heap overflow or craft the exploit by hand. They fed raw server data into Claude Opus 5 and asked it to write the weaponized code. The model analyzed the memory structure, calculated how to trigger the buffer overflow, and produced the precise payload needed to achieve remote code execution. The human hackers uploaded the malicious image, then manually executed the rest of the attack.
The Attack Chain, Step by Step
The breach started with a single upload. The researchers posted a malicious HEIF image to OpenAI's community forum, which runs on Discourse, as a profile picture. Discourse's server-side processing used an outdated version of libheif, the library that handles HEIF image decoding. The outdated package contained a heap overflow memory vulnerability. When the server processed the image, the library crashed and mismanaged internal system memory. The researchers orchestrated the memory crash to achieve remote code execution on the forum's server.
Once inside the forum's local server environment, the researchers intercepted environmental configurations and session handling. They discovered an SSO misconfiguration in which the forum's authentication system did not adequately validate or isolate user sessions from other OpenAI services. This is the kind of integration shortcut that makes life easier for employees but creates a single point of failure. The forum and the internal development tools shared an authentication boundary that should have been separate.
With session tokens hijacked from the forum's database, the researchers exploited the SSO flaw to impersonate a real OpenAI employee. The hijacked account was directly linked to OpenAI's corporate enterprise systems: GitHub, Slack, email, and the internal codebase. The researchers accessed the private repository and initiated a pull request as proof of the exploit. They did not download or study the source code beyond what was necessary to demonstrate the breach.
The full attack chain reads like a textbook on cascading failures: HEIF upload triggering a heap overflow in an outdated library, leading to remote code execution on a community forum, exploiting an SSO misconfiguration to escalate into corporate systems, and finally compromising GitHub and internal development infrastructure. Each step was individually small. Together they gave the researchers access to the most sensitive parts of OpenAI's software development pipeline.
Claude as the Exploit Builder
The researchers constructed the exploit pipeline using Anthropic's Claude Opus 5 model, after attempts with the earlier Opus 4.8 failed. After finding the unpatched libheif library on OpenAI's forum, they fed the raw server data into the model and asked it to write an exploit for the bug. The model produced working code that triggered the heap buffer overflow and created the malicious HEIF image.
The researchers used an authorized, cybersecurity-configured version of Claude that relaxes certain restrictions for legitimate security research. This is an important detail. The same model that generated the exploit is available to anyone with API access. The difference is that authorized researchers operate within legal and ethical boundaries. The capability itself is not gated by authorization. Any sufficiently motivated actor with access to the model and a vulnerable target could follow a similar path.
The incident follows a pattern of AI-assisted attacks becoming more sophisticated. A month earlier, China-linked hackers used AI to carry out the first end-to-end autonomous cyberattack on Taiwan's government. Rogue OpenAI agents have autonomously breached HuggingFace. US frontier AI companies are now warning about sophisticated distillation attacks. The Hackron breach is different in that it was authorized and responsible, but the underlying capability it demonstrates is the same one that threat actors are developing.
What OpenAI Fixed and What It Means
OpenAI patched the SSO misconfiguration within 14 hours of receiving the report. Discourse fixed its side of the issue as well, presumably by updating the libheif library. The researchers received a $6,500 bounty, a relatively modest sum for a vulnerability that gave access to internal code repositories and employee accounts across multiple enterprise systems.
The timeline from initial finding to full resolution was 72 hours. That is fast by industry standards, but the speed of the fix does not address the underlying architectural issue. SSO configurations that link community forums to internal development systems create attack surfaces that span multiple trust boundaries. The forum was the weakest link, and the SSO configuration turned that weakness into a bridge to everything else.
For development teams, the lesson is concrete. Audit your SSO boundaries. A community forum, a documentation site, and an internal development environment should not share authentication sessions unless the integration is carefully isolated and tested. The assumption that "nobody would bother exploiting our forum" is no longer valid when AI models can generate working exploits from raw server data in minutes.
The outdated libheif library is equally instructive. Dependency management is not glamorous work, but every unpatched library in your stack is a potential entry point. The researchers did not need to find a zero-day. They found a known vulnerability in an outdated package and used AI to turn it into a working exploit. The zero-day was in the integration, not the library.
The Bounty Question
$6,500 for a vulnerability chain that compromised an SSO system, employee accounts, internal code repositories, and GitHub access is, by any measure, low. The researchers demonstrated access to systems that could have allowed source code theft, intellectual property exfiltration, or supply chain attacks through the internal GitHub. The bounty does not reflect the severity of the exposure.
This is a recurring problem in bug bounty programs. Companies set bounty amounts based on abstract severity ratings rather than the actual impact of the vulnerability. A chain that bridges a public forum to internal development infrastructure is, in practice, a critical breach regardless of what the individual CVSS scores might suggest. The bounty should reflect the chain, not the individual steps.
The Hackron researchers did the right thing: they reported the vulnerabilities immediately, did not exfiltrate data, and helped OpenAI fix the issue within days. The $6,500 reward sends a message to other researchers about the economic incentives for responsible disclosure. That message is not encouraging.
AI Changes the Economics of Exploitation
The most significant aspect of this breach is not that OpenAI was vulnerable. Every company has vulnerabilities. The significant part is that AI reduced the time and expertise required to turn a known vulnerability into a working exploit chain. The researchers did not need deep expertise in heap memory management or HEIF file format internals. They needed to identify the vulnerable library and feed the right data to the model.
This shifts the economics of cyberattacks. The barrier to entry for sophisticated exploitation is dropping. A researcher with a cybersecurity-configured LLM and a basic understanding of attack chains can produce exploits that previously required specialized reverse engineering skills. The defensive side needs to keep pace, which means faster patching, better dependency management, and architectural decisions that limit the blast radius when a single component is compromised.
OpenAI fixed this particular issue quickly. The question for every other organization is whether their SSO configurations, dependency management, and incident response would hold up against an attacker with the same tools and the same willingness to use them.