Hacktron chained a Claude-written libheif exploit into OpenAI's internal repositories
The libheif bug was fixed upstream a year earlier without a security label or a CVE, so a Discourse image check that ignored HEIC left it reachable, and forum sign-in tokens carried full API access to the accounts behind them.
The Watch · Security desk
What happened
- Hacktron needed several attempts with Claude Opus 4.8 and Opus 5 to build reliable remote code execution for an unpatched libheif flaw, testing it on a Discourse instance before running it on OpenAI's forum.
- Discourse's built-in image checks did not support HEIC/HEIF, so uploads in that format were handed to ImageMagick, which decodes them using libheif.
- Because community.openai.com accepted OpenAI account sign-in, code execution on the forum meant any user or employee who had logged in could have had their ChatGPT and Codex accounts taken over.
- Hacktron took over an OpenAI employee account whose Codex integration was linked to OpenAI's GitHub organization, opened a pull request in an internal repository, and stopped testing there.
- OpenAI confirmed a fix about 14 hours after the Bugcrowd report and paid a $6,500 bounty, while Discourse had a fix ready within two days and added image-processing sandboxing.
Why it matters
- What it limits constraint Catching this required tracking the libheif version in the dependency tree, because a CVE-keyed patch program had no identifier to alert on.
- Who's exposed exposure A community forum wired to production identity puts every employee who signs in, and whatever they have connected to that account, within reach of a file upload.
- What's now possible capability If a few LLM attempts are enough to weaponise an obscure decoder bug, the gap between a quiet upstream fix and a working exploit narrows for anyone reading commit logs.
- What doesn't add up contradiction Hacktron and OpenAI do not agree on reach: OpenAI says the Slack access Hacktron raises was never verified, so how far the intrusion is scoped depends on which account a responder takes.
Next story · Build · Oct 5
OpenAI makes textGrain watermarking opt-in for API customers everywhereConfirmed27 publishers
Hacktron says the libheif bug was corrected upstream a year before this work, was never flagged as a security issue, and so was never assigned a CVE [17]. A patch program that reads CVE feeds has nothing to match. No vulnerability feed would have told community.openai.com that its decoder was behind [18].
When the validator's list of supported formats is shorter than the decoder's, the formats the validator does not recognise still reach the library [16].
OpenAI's half of the chain was permission scope. Sign-in tokens generated for the community forum carried excessive permissions and granted full API access to the associated ChatGPT and Codex accounts, according to SecurityWeek's account of the finding [5].
OpenAI draws a line between the two bugs. It told SecurityWeek that the image-processing flaw lived in the third-party service Discourse, while the account-takeover path was a separate, OpenAI-side issue [4]. Both halves were required. Closing them took two bug bounty programs, Bugcrowd for the token permissions and HackerOne for the decoder [15].
On scope, OpenAI said its own review of the incident found limited reads of private-repository metadata and commits, followed by the researcher-submitted pull request, to a README file [13]. The report does not date the fixes.
In a statement, OpenAI said, "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." [14]
What to watch
- Whether libheif maintainers or distributions retroactively assign a CVE to the silently fixed bug, giving scanners something to match.
- Whether other services that accept OpenAI-account sign-in were issued tokens with the same API permissions OpenAI says it has now narrowed.
- Whether other Discourse-hosted community sites federated to corporate identity check their own HEIC upload handling after the advisory.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence70
- Adoption
- Not scored
- Hype gap+20
- Incentives55
- Confidence66
Perspective Coverage
6 publishers- Builder
- Builder 35%
- Operator
- Operator 55%
- Investor
- Investor 10%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Researchers at security firm Hacktron used Claude to build a working exploit for a vulnerability in an image-processing library, then chained it with a flaw in OpenAI's sign-in system to take over employee ChatGPT and Codex accounts and gain access to internal code repositories.
- [2]
Turning the libheif flaw into a reliable exploit took several attempts and involved Claude Opus 4.8 and Opus 5; the exploit allowed remote code execution, which the researchers first used against a test Discourse instance and then on OpenAI's own forum.
- [3]
The entry point was community.openai.com, which runs on Discourse; Discourse's built-in image checks did not support the HEIC/HEIF format, so uploads in that format were passed to ImageMagick, exposing an unpatched flaw in the libheif library it relies on for decoding.
- [4]
OpenAI 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.
- [5]
The OpenAI weakness was related to sign-in tokens generated for the community forum carrying excessive permissions and granting full API access to associated ChatGPT and Codex accounts.
- [6]
Because the forum let people sign in with their OpenAI account, code execution there opened a path to broader account access; 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.
- [7]
To demonstrate the access without reading internal code, Hacktron says it took over an OpenAI employee's account whose Codex integration was linked to OpenAI's GitHub organization, then used it to open a pull request in an internal repository before stopping further testing.
- [8]
Since people often connect other services to their OpenAI accounts, the theoretical exposure extended to services like GitHub, Slack and email.
- [9]
Hacktron's report raises Slack as a service that could theoretically have been reached through connected accounts; OpenAI says Hacktron did not verify actual access to employee Slack messages.
- [10]
The security firm reported the account-takeover issue to OpenAI through Bugcrowd, and OpenAI confirmed a fix about 14 hours later.
- [11]
Hacktron separately 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 published a security advisory.
- [12]
OpenAI paid Hacktron a $6,500 bounty for the OpenAI-side finding.
- [13]
OpenAI said its own review of the incident found limited reads of private-repository metadata and commits, followed by the researcher-submitted pull request, specifically to a README file.
- [14]
In a statement, OpenAI said, "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."
- [15]
Closing the single attack chain required two separate disclosure programs: Bugcrowd for OpenAI's sign-in token permissions and HackerOne for the libheif exposure in Discourse.
- [16]
The exposure arises wherever an upload validator supports fewer formats than the downstream decoder: unrecognised formats are passed through to the library rather than rejected.
- [17]
Hacktron says the underlying libheif bug had been fixed upstream a year earlier without ever being flagged as a security issue, so it was never assigned a CVE and missed the usual patching cycle.
- [18]
Because the upstream libheif fix was never labeled a security issue and never received a CVE, a patch program that matches on CVE identifiers had no record to match, leaving downstream consumers of the older library version without an upgrade signal.
Sources
6 independent publishers whose own reporting we read for this story.
- cyberscoop.comResearchers use AI to find widespread software decoder flaw
2 articles · September 18, 2026
- github.comRCE via malformed HEIF file · Advisory · discourse/discourse · GitHub
1 article · September 21, 2026
- malwarebytes.comResearchers used Claude to hack OpenAI
1 article · September 22, 2026
- securityaffairs.comAI Helps Hackers Hijack OpenAI Staff Accounts Through a Forum
1 article · September 19, 2026
- securityweek.comAI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code
2 articles · September 18, 2026
- thehackernews.comClaude Opus 5 Helped Researchers Take Over OpenAI Staff Accounts via Chained Flaws
2 articles · September 19, 2026
Topics and entities
Topics
- Image parsing vulnerabilities
- Single sign-on security
- Bug Bounty Programs
- Open-source patch propagation
- AI-Assisted Exploit Development