Security firm Hacktron AI has disclosed that it used Anthropic's Claude to take over an OpenAI employee account and reach the company's internal code repository. According to a technical report dated September 13, 2026, the test—conducted in July—moved from initial discovery to creating a benign proposed change in an internal repository via an employee's Codex account in under 72 hours. OpenAI says the underlying issue has been fixed. The path, which started from an image-processing flaw and moved through shared authentication into a development environment, highlights both how quickly AI can write exploit code and the question of how permissions are separated between different services.
From an Image to Internal Code: Crossing the Authentication Boundary
The point of entry was an image-upload feature on OpenAI's community forum. The forum runs on third-party software called Discourse, which uses a library called FastImage to check images. Files in the HEIF format, which FastImage doesn't support, are routed to a different process—one that relies on ImageMagick and an image-processing library called libheif.
According to Hacktron, libheif contained a "heap buffer overflow" bug that allows writes beyond the boundaries of allocated memory. By feeding the system a specially crafted image, an attacker could execute code on the server outside the intended image-conversion process. Although the entry point was a posted image, what it ultimately granted access to was the server's own processing permissions.
OpenAI's single sign-on (SSO) system also had a flaw, Hacktron says, which allowed the breach to move from the forum into the ChatGPT and Codex accounts of users who had logged into the forum using their OpenAI credentials. SSO is a mechanism that lets a single login work across multiple services. Hacktron notes that the issue allowing access to spread from the forum into other products was on OpenAI's side, not a flaw specific to Discourse.
The research team took over multiple employee accounts, and using one where Codex was connected to OpenAI's GitHub organization, they demonstrated actual access. They say they instructed Codex to create a benign pull request in the internal "openai/openai" repository. A pull request is merely a proposed code change—it does not indicate that the change was accepted or deployed to production.
The researchers say they did not view internal code or sensitive information and stopped testing once they had demonstrated the exploit. While they note that the access could potentially have extended to other tools such as Slack or email, this needs to be distinguished from any claim that such data was actually retrieved. Nor does this mean that access was granted unconditionally to every ChatGPT user. What the report flags as the core problem is the OpenAI login on the forum and the account permissions it connects to.
How Claude Shortened the Time to Build Working Exploit Code
The image-processing flaw that Hacktron began investigating on July 23 was not an unknown issue lacking any fix. According to the company, the vulnerable code had actually been changed by the upstream developer the previous year—but the change wasn't labeled as a security fix and never received a CVE identifier. As a result, the fix never made it into the package version used by Discourse. Hacktron suggests this classification may have delayed the patch reaching older versions.
Claude's role was to turn that flaw into functioning exploit code. The first model used, Opus 4.8, was able to produce working code only when ASLR—a defense that randomizes memory layout to make it harder to predict—was disabled. In environments where ASLR was enabled, repeated attempts failed to produce a stable exploit. Even after finding the vulnerability, there remained a gap between that discovery and something that would actually work under real operating conditions.
The researchers then switched to Opus 5 on the night of July 24. According to the company, working exploit code for a local Mac environment was produced within three hours, after which the team worked on porting it to Discourse's server environment. They had Claude iterate repeatedly in their own test environment, then used the resulting code against OpenAI's actual forum.
Hacktron summarized the overall timeline this way:
"From initial discovery to access to OpenAI's repository, the entire process took under 72 hours."
However, this is the result of a single case guided by experienced researchers. Hacktron itself states plainly that this was not a fully autonomous intrusion, and it does not prove that anyone using the model could achieve the same result. The observation that outcomes changed before and after switching models should be read separately from any broader benchmark comparing overall attack capability across products.
The cost figures also cover a different scope than people might assume. The publicized figure of under $3,000 refers to the total token cost for the entire "HEIF Heist" project—three researchers investigating multiple companies over two months—not the cost of the OpenAI intrusion alone, and not a total that includes labor costs. Still, the fact that a small team used AI to write exploit code and adapt it to a live environment, and moved the investigation forward on that basis, has implications for how much lead time defenders should assume attackers need.
A Path That Isn't Closed by Fixing the Image Processing Flaw Alone
In an official announcement on July 28, Discourse described the remote-code-execution issue via image upload as CVE-2026-32882 and advised updating to Docker images bundling a fixed version of libheif. Applying the update requires rebuilding the running environment. The latest supported version, running on a compatible kernel, also added an additional sandbox to isolate image processing.
Mapping Hacktron's attack path against what Discourse's advisory addresses helps separate the areas operators need to check.
| Stage of the attack | What the report and advisory confirm | Operational checkpoint |
|---|---|---|
| From a posted image to the forum's server | Exploited a libheif flaw; Discourse advised updating to the fixed image and isolating image processing | Is the fix not just available upstream, but actually deployed to the running image? |
| From the forum to ChatGPT/Codex | Hacktron attributes this to a flaw in OpenAI's SSO | If one service is compromised, can the breach reach permissions in other services? |
| From Codex to the linked GitHub | Demonstrated a proposed change reaching an internal repository via an employee account | How much control does a development environment connected to an AI account actually permit? |
Fixing the image-processing flaw and separating authentication permissions are countermeasures aimed at different stages of the attack. Updating to the patched image closes this particular entry point, but whether permissions can spread between services is a separate design question that needs its own review. Isolating image processing also serves as a safeguard against as-yet-unknown flaws. The checkpoints in the table are operational implications drawn from the disclosed attack path—they do not identify the specifics of OpenAI's non-public authentication implementation.
OpenAI's response was fast. According to Hacktron's timeline, the fix was confirmed roughly 14 hours after the July 25 report, and a $6,500 bounty was paid on September 1. However, the same report notes that OpenAI's own explanation excludes testing against the Discourse-run forum from its bug bounty scope, framing the payment instead as recognition for OpenAI's own discovery. The bounty payment should not be read as prior authorization covering the full scope of testing conducted.
TechCrunch also reported on September 18 that OpenAI had resolved the issue. Matt Fredrikson, CEO of AI security firm Gray Swan, who spoke to the outlet, expressed concern that if this could happen at OpenAI, it could happen elsewhere too. That's an expert's opinion, but the fact that an AI company itself allowed a breach through third-party image-processing libraries and linked authentication underscores the risk of focusing solely on a model's raw capabilities.
If patched images reliably reach production environments, and if the compromise of one service can be prevented from expanding into another service's permissions, defenses can be maintained against attacks at both the image-processing entry point and the authentication links that follow it.