AI-Crafted Exploit Chain Hit OpenAI Code

An attacker who never sat at an OpenAI keyboard still managed to reach the company's internal repositories. According to a report from security firm Hacktron, the route ran through an image decoder, a sign-in oversight, and an AI model used to weaponize a bug that had gone unpatched for a year. The chain ended with a researcher-submitted pull request inside OpenAI's own codebase — and a fix rolled out within hours.

A Forum Built on Discourse

Hacktron's entry point was community.openai.com, the company's public forum, which runs on the Discourse platform. Discourse's built-in image checks did not support the HEIC/HEIF photo format, so any upload in that format was handed off to ImageMagick for processing. That handoff, according to Hacktron, exposed an unpatched flaw in the libheif library ImageMagick relies on to decode HEIC/HEIF files.

The bug itself was not a fresh discovery. Hacktron says the underlying issue had been fixed upstream a year earlier but was never flagged as a security problem, so it was never assigned a CVE and slipped past the usual patching cycle. The result was a decoder with a known-corrected defect still live in production.

Because the forum allowed users to sign in with their OpenAI account, code execution on that server was not an isolated event. It opened a path to broader account access — a detail that turned a library bug into an identity problem.

Claude Opus Built the Exploit

Hacktron used Claude to build a working exploit for the image-processing flaw. Turning the bug into something reliable took several attempts and involved Claude Opus 4.8 and Opus 5, according to the firm's account. The exploit achieved remote code execution, which the researchers first tested against a test Discourse instance before aiming it at OpenAI's own forum.

The progression is notable: a model was used not to find a vulnerability in the abstract, but to construct a functional exploit for a specific target and iterate until it worked. Hacktron has published its findings in a report on the firm's blog.

The researchers did not stop at remote code execution. With a foothold on the forum server, they moved toward the accounts that the forum's sign-in flow touched.

Sign-In Tokens Carried Too Much Power

OpenAI draws a distinction between the two flaws. It told SecurityWeek that the image-processing bug lived in the third-party service Discourse, while the account-takeover path was a separate, OpenAI-side issue.

The OpenAI weakness, as described, related to sign-in tokens generated for the community forum. Those tokens carried excessive permissions and granted full API access to the associated ChatGPT and Codex accounts. In practice, that meant a token minted for a forum login could be used to reach far more than the forum.

Hacktron says that until the issue was fixed, any user or employee who logged into the forum could have had their ChatGPT and Codex accounts taken over. Because people commonly connect other services to those accounts, the theoretical exposure extended to services such as GitHub, Slack and email.

An Employee Account, a Pull Request

To demonstrate the access without reading any internal code, Hacktron says it took over an OpenAI employee's account whose Codex integration was linked to OpenAI's GitHub organization. From there, the researchers used the account to open a pull request in an internal repository before stopping further testing.

OpenAI's own review of the incident found limited reads of private-repository metadata and commits, followed by the researcher-submitted pull request. That pull request, the company said, was specifically to a README file.

The Slack angle drew a similar split in accounts. Hacktron's report raises Slack as a service that could theoretically have been reached through connected accounts, but OpenAI says Hacktron did not verify actual access to employee Slack messages.

A 14-Hour Fix and a Two-Day Patch

The disclosure process moved quickly on both fronts. Hacktron reported the account-takeover issue to OpenAI through Bugcrowd, and the company confirmed a fix about 14 hours later. Separately, the firm reported the libheif flaw to Discourse through HackerOne. Discourse had a fix ready within two days, added image-processing sandboxing as an extra layer of defense, and then published a security advisory.

OpenAI issued a statement on the engagement: “We thank the researchers for contacting us and sharing their findings. We narrowed the permissions on Community sign-in tokens and revoked affected tokens and sessions.”

The company paid Hacktron a bounty for the OpenAI-side finding.

The timeline, in the sequence the source provides:

• 1 year before the incident: the underlying libheif bug is fixed upstream but never flagged as a security issue, so it is never assigned a CVE.
• 14 hours after Hacktron reported the account-takeover issue through Bugcrowd: OpenAI confirms a fix.
• 2 days after the libheif flaw was reported through HackerOne: Discourse has a fix ready, adds image-processing sandboxing, and publishes an advisory.

Two Flaws, One Chain

The shape of this incident matters more than any single component. Neither flaw, on its own, would have delivered the outcome. The ImageMagick/libheif issue provided code execution on a server; the OpenAI token issue converted that foothold into account access with enough reach to touch internal repositories. The forum's decision to accept OpenAI credentials for sign-in is what joined the two.

That joining is the part likely to draw attention from defenders. A public, low-stakes community forum became a bridge into the accounts that developers and staff use to reach source code. The permissions attached to a forum sign-in token were not scoped to the forum's needs — and that gap was the difference between a bug on a discussion board and a path into a codebase.

Hacktron's use of Claude to construct the exploit adds a second dimension. The firm says the working exploit required several attempts across two model versions. That account does not describe a model independently discovering a vulnerability, but it does describe a model being used to build and refine attack tooling against a named target — a workflow that compresses the time between finding a flaw and weaponizing it.

OpenAI's own framing keeps the two issues separate and points the image-processing defect at third-party infrastructure. Its statement describes narrowing the permissions on Community sign-in tokens and revoking affected tokens and sessions. Discourse's response added sandboxing around image processing, a change aimed at limiting what a decoder flaw can reach even if a similar bug surfaces again.

The scope of confirmed access, per OpenAI's review, stayed narrow: limited reads of private-repository metadata and commits, plus the pull request to a README. Hacktron says it stopped testing after that pull request. The firm did not, according to OpenAI, verify access to employee Slack messages.

Two details stand out for anyone reading the incident as a template. First, the libheif bug had been corrected upstream for a year without a CVE or a patch reaching the affected deployment — a reminder that "fixed upstream" and "fixed here" are different things. Second, the account-takeover path depended on token permissions that exceeded the purpose of the service issuing them, a pattern that shows up wherever single sign-on joins a peripheral application to a core identity.

What This Could Mean for Sign-In Design

For security teams, the most transferable lesson is about token scope. A sign-in token issued for a community forum should not carry API access to a company's primary developer products. This incident suggests that when a peripheral service accepts a central account for authentication, the permissions bound to that session deserve the same scrutiny as the core product's own access controls. Auditing what a forum or support-portal login can actually reach is a concrete step teams can take now, without waiting for a vendor advisory.

For developers and employees who use one account across many connected services, the chain illustrates compounding exposure. In this case, a single forum login could, in theory, have extended to GitHub, Slack and email through connected accounts. Individuals may want to review which integrations are linked to their work accounts and whether every one of them needs the access it has.

For the broader industry, the disclosure and remediation timeline offers a working model: report through a bug bounty platform, get a fix confirmed within hours, patch the upstream library within days, and add a defense layer beyond the immediate fix. The gaps in that model are equally visible. A vulnerability that never receives a CVE can sit unpatched for a year in the systems that depend on it, and an over-permissioned sign-in token can turn a discussion board into an entry point. This account suggests that the distance between a low-severity library bug and a company's internal code is often one overly broad credential.