On September 18, 2026, a small independent research team called Hacktron AI publicly disclosed something that would have sounded like science fiction two years ago: they used Anthropic’s Claude model to build a working exploit chain, breach OpenAI’s own infrastructure, take over employee accounts, and reach an internal GitHub repository, all within 72 hours. OpenAI confirmed the incident, patched the underlying flaws, and paid a $6,500 bug bounty. No production systems or sensitive user data were exposed. But the story that matters here is not really about OpenAI’s patch cycle. It is about what happens when an AI model becomes a genuinely capable member of the offensive security team, and what that means for every organization that has not yet stress-tested its own defenses against that reality.
How the Attack Actually Started
The entry point was almost mundane by modern standards: an image upload handler. OpenAI’s community forum, hosted on the Discourse platform, allowed users to upload images in HEIC/HEIF format, but Discourse’s own built-in image validation did not support that format. Uploads in HEIC/HEIF were instead passed through to ImageMagick for processing, and ImageMagick relied on the libheif library, which contained an unpatched heap overflow vulnerability. A malformed image file was enough to trigger memory corruption and, ultimately, remote code execution on the server processing it.
This is the part of the story every web application security team should sit with for a moment: the vulnerable component was not OpenAI’s own code. It was a third-party image library, several layers removed from anything OpenAI’s developers had written or reviewed directly, quietly doing its job inside a dependency chain that almost nobody audits end to end. That is precisely the kind of gap that a routine code review misses and a genuine penetration test of the full application stack, including its dependencies, is built to catch.
Where Claude Came In
Finding a vulnerable library is one thing. Turning a heap overflow in an obscure image codec into a working, reliable exploit is a different level of difficulty, traditionally requiring a specialist with deep memory-corruption experience and days or weeks of iteration. Hacktron’s researchers, Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini, instead fed the raw vulnerability data to Anthropic’s Claude Opus 5 model and asked it to write the exploit. Their first attempts with the earlier Opus 4.8 model reportedly failed. Opus 5 succeeded.
From there the attack chain moved fast: the HEIF-triggered RCE gave the researchers a foothold, which they used to pivot through a flaw in OpenAI’s own single sign-on implementation, ultimately gaining control over ChatGPT and Codex accounts belonging to OpenAI staff. Those compromised accounts were connected to OpenAI’s internal GitHub organization, and the researchers demonstrated real impact by opening what they described as a “harmless” internal pull request, proof that they could write to OpenAI’s own codebase, not just read it.
Why This Story Is Bigger Than One Bug Bounty Payout
OpenAI’s response was measured: the company said the award recognized the OpenAI-side finding specifically, not the researchers’ actions against the separately hosted Discourse community site, and confirmed that no production systems or sensitive user data were compromised. That is a reasonable, calibrated response to a single, resolved report. But it undersells the significance of the method used to get there.
Until very recently, chaining a third-party library heap overflow into working remote code execution was specialist work. It required someone who understood memory layout, calling conventions, and the specific quirks of the vulnerable code well enough to turn a crash into controlled execution. What Hacktron demonstrated is that a frontier AI model, given the right raw material, can now do a meaningful part of that specialist work on request. The skill bottleneck that used to separate “we found a bug” from “we have a working exploit” is measurably lower than it was even a year ago, for at least some classes of vulnerability.
That has a direct, practical consequence for defenders: the population of people capable of turning a disclosed or discovered flaw into real impact is growing, and it is growing faster than most security programs are adjusting their risk models. A vulnerability that used to sit safely in “theoretical, needs a specialist to weaponize” now needs to be treated as “someone with API access to a capable model might weaponize this by next week.”
The Identity and SSO Angle Deserves Its Own Attention
It is worth separating the two halves of this attack chain, because they carry different lessons. The initial RCE via libheif is a supply-chain and input-validation story: audit what your dependencies actually do with untrusted input, not just what your own code does. The second half, pivoting from a compromised server into employee ChatGPT and Codex accounts via an SSO flaw, is an identity and access story, and arguably the more dangerous half for most organizations to ignore.
Single sign-on is supposed to centralize and strengthen authentication. When it is misconfigured, it does the opposite: it turns one flaw into a skeleton key for every connected system. An attacker who compromises an SSO integration does not need to find separate vulnerabilities in each downstream application; they inherit whatever trust that application already placed in the identity provider. As organizations connect more internal tools, including AI coding assistants and agent platforms, to centralized identity systems, the blast radius of a single SSO misconfiguration keeps growing. This is exactly the kind of chained, multi-system weakness that automated scanners routinely miss, because no single component looks broken in isolation. Only an assessment that actively tries to pivot across systems, the way a real attacker does, surfaces it.
What This Means If Your Organization Uses AI Coding Tools or Agents
- Treat every AI-connected account, whether it is a developer’s ChatGPT, Codex, Claude, or Copilot access, as a high-value identity target, because it is often tied directly into source code, internal documentation, and sometimes production credentials.
- Audit third-party libraries in your upload and file-processing pipelines specifically, not just your top-level application code. Image, document, and media parsing libraries are a recurring source of exactly this class of memory-corruption bug.
- Review your SSO and identity provider configuration for any path that lets a compromise of one connected application escalate into access on another, particularly where AI tools are in the mix.
- Assume that the skill required to weaponize a disclosed vulnerability is dropping, and shorten your patch and mitigation timelines accordingly rather than assuming a low-severity finding will stay theoretical.
- Get an independent, adversarial look at how your own AI tooling, developer accounts, and identity systems connect to one another before someone else does it first, ideally through a dedicated AI agent and LLM security assessment rather than a generic vulnerability scan.
A Preview of Where Offensive Security Is Heading
What makes the OpenAI incident worth remembering months from now is not the specific CVE or the specific bounty amount. It is the demonstration that AI-assisted exploit development has crossed from research curiosity into something a three-person independent team could pull off against one of the best-resourced technology companies in the world, in under three days, using a publicly available model. Security teams that are still evaluating whether AI changes their threat model are already behind the researchers who are actively using it as a tool. The organizations that come out ahead will be the ones treating their own AI-adjacent attack surface, from SSO integrations to the code review process for AI-generated pull requests, with the same rigor they apply to any other production system.
Frequently Asked Questions
Did the attackers actually steal OpenAI’s source code or user data?
No. OpenAI confirmed that no production systems and no sensitive user data were compromised. The researchers demonstrated write access to an internal repository by opening a single “harmless” pull request as proof of impact, then reported the full chain responsibly.
Was this attack against ChatGPT itself, or against OpenAI’s own internal systems?
Both, in sequence. The initial vulnerability was in OpenAI’s Discourse-hosted community forum, which OpenAI itself noted was technically outside the formal scope of its bug bounty program. From there, the researchers pivoted through an SSO flaw into internal ChatGPT and Codex accounts belonging to OpenAI employees, which is the part OpenAI did recognize and reward.
Does this mean anyone can now use Claude or a similar model to hack a company?
Not quite. The researchers still needed to find the vulnerable library, understand the application architecture, and chain multiple separate flaws together by hand. What changed is that the hardest single step, turning a raw memory-corruption bug into a working exploit, no longer strictly required a human specialist. That is a meaningful shift in who is capable of weaponizing a given vulnerability, even if the surrounding attack still requires real skill.
What should security teams take away from this beyond “patch libheif”?
The specific library is almost beside the point. The real lesson is that dependency-level vulnerabilities and identity/SSO misconfigurations are now both easier to weaponize and more likely to be chained together by attackers using AI assistance, which argues for testing those two areas together rather than as separate, siloed audits.
Getting Expert Help
If your business relies on AI coding assistants, connected agent platforms, or any system where a single sign-on flaw could cascade across multiple tools, now is the time for an independent assessment rather than after an incident forces the question. AgentOffense specializes specifically in offensive security testing for AI agents, LLM-integrated applications, and the identity systems that connect them. For organizations that need broader infrastructure and web application testing, SecurityLab.Pro’s penetration testing service covers the full stack, and CyprusPentest offers dedicated penetration testing for businesses based in Cyprus and across the EU. The Hacktron researchers proved this kind of chained attack is achievable by a small, well-motivated team in days. The only real defense is finding these paths yourself first.