Skip to content

Security Reports disagree6 publishers 2 min read Published Updated

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

Send a correction

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 everywhere

Confirmed27 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%
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [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.

    Reported SupportedView cited source
  2. [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.

    Reported SupportedView cited source
  3. [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.

    Reported SupportedView cited source
  4. [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.

    Reported SupportedView cited source
  5. [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.

    Reported SupportedView cited source
  6. [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.

    Reported SupportedView cited source
  7. [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.

    Reported SupportedView cited source
  8. [8]

    Since people often connect other services to their OpenAI accounts, the theoretical exposure extended to services like GitHub, Slack and email.

    Reported SupportedView cited source
  9. [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.

    Reported SupportedView cited source
  10. [10]

    The security firm reported the account-takeover issue to OpenAI through Bugcrowd, and OpenAI confirmed a fix about 14 hours later.

    Reported SupportedView cited source
  11. [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.

    Reported SupportedView cited source
  12. [12]

    OpenAI paid Hacktron a $6,500 bounty for the OpenAI-side finding.

    Reported SupportedView cited source
  13. [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.

    Reported SupportedView cited source
  14. [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."

    Reported SupportedView cited source
  15. [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.

    Derived Supported
  16. [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.

    Derived Supported
  17. [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.

    Reported ContestedView cited source
  18. [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.

    Derived Contested

Sources

6 independent publishers whose own reporting we read for this story.

  1. cyberscoop.com

    2 articles · September 18, 2026

    Researchers use AI to find widespread software decoder flaw
  2. github.com

    1 article · September 21, 2026

    RCE via malformed HEIF file · Advisory · discourse/discourse · GitHub
  3. malwarebytes.com

    1 article · September 22, 2026

    Researchers used Claude to hack OpenAI
  4. securityaffairs.com

    1 article · September 19, 2026

    AI Helps Hackers Hijack OpenAI Staff Accounts Through a Forum
  5. securityweek.com

    2 articles · September 18, 2026

    AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code
  6. thehackernews.com

    2 articles · September 19, 2026

    Claude Opus 5 Helped Researchers Take Over OpenAI Staff Accounts via Chained Flaws

Topics and entities

Topics