BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Hacktron chained an unflagged libheif overflow to write access on OpenAI's monorepo
Hacktron chained a heap overflow in libheif to an OpenAI SSO flaw and opened a pull request in OpenAI's internal monorepo in under 72 hours. The bug had been fixed upstream a year earlier, but the fix never reached Debian's packages.
The Engineer · Build desk
What happened
- The forum sits behind Sign in with OpenAI, so running code on it gave a no-interaction takeover of the ChatGPT and Codex accounts of any logged-in member.
- The script the model generated against the researchers' own Discourse Cloud worked unchanged on OpenAI's instance, handing them an employee's Codex that was wired into OpenAI's GitHub organization.
- OpenAI, notified through Bugcrowd, confirmed a fix about 14 hours later and paid a $6,500 bounty scoped to the SSO finding, not the actions against Discourse.
- Discourse, reported separately through HackerOne, had a fix out within a weekend, added ImageMagick sandboxing as defense in depth, and published advisory GHSA-vhm9-85gw-x335.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A fix that ships without a CVE or a security label never enters a distro's backport queue, so a team relying on Debian's security feed to know when to patch never hears that the bug exists.
- capability Turning a public memory-corruption bug into a working exploit used to take rare skill and months of effort; folding it into days of model compute widens the pool of people who can do it.
- exposure Hacktron says the escalation is an OpenAI SSO flaw, not a Discourse one, so any first- or third-party service behind Sign in with OpenAI is a path to the same accounts once it is compromised.
- decision Teams whose code hands user-supplied HEIC, HEIF or AVIF files to libheif should assume exposure across the 1.19.x to 1.23.x range and track the library themselves.
Discourse does not decode HEIC itself. It screens uploads with FastImage, and FastImage has no HEIF support, so the forum hands .heic and .heif files to ImageMagick's magick command for conversion. That drops an attacker-controlled file straight into libheif. The community.openai.com image ran on a Debian 12 base with libheif 1.19.7, and a heap buffer overflow during HEIC decoding returned out-of-bounds read and write primitives. [5][6][7]
The Debian base image still carried the bug a year after it was fixed. Hacktron's explanation is that the upstream patch landed as an ordinary commit, with no security label and no CVE, so nothing triggered a backport. [8][9] Debian 13 shipped 1.19.8, still vulnerable, and the fixed package did not arrive until August 8, 2026, fourteen days after the proof-of-concept pull request. [9][10][27]
The exploit came together across two model releases. On July 24, Opus 4.8 produced an ImageMagick/libheif exploit that ran with ASLR disabled, but across several sessions could not make it reliable against Discourse's defaults with ASLR on. [13] Anthropic released Claude Opus 5 the same night. In a clean session the model built a working ARM64 exploit for a local Mac in three hours, then ported it to the x86-64 jemalloc layout Discourse uses. [14] To get a remote exploit, the team put the model into an autonomous /goal loop aimed at a Discourse Cloud instance of their own, routed through rce.ee/ctf-forum so it would read as a CTF target, because Opus refused to attack a remote host directly. [15]
The libheif work is one target in a campaign Hacktron calls HEIF Heist, which traced the same library through Slack, Meta, GitHub Enterprise, Ruby on Rails and the Node.js frameworks Next.js, Astro and Gatsby. [22] Over two months, three researchers spent under $3,000 in tokens on the effort, reworking the exploit for each new target in a day or two while starting almost blind on the libheif version, the libc version and the deployment. [23][24]
If you self-host Discourse, a web-interface update may not replace the underlying image, so rebuild from /var/discourse with a git pull and ./launcher rebuild app. [25]
What to watch
- Whether libheif or MITRE assigns the fix a CVE after the fact, which is what would push Debian and other distros to backport it.
- Whether Hacktron's reported capability jump from Opus 5 to GPT-5.6 Sol holds up as HEIF Heist moves to more targets.
- Whether OpenAI changes the SSO configuration itself, given that the bounty was scoped only to the SSO finding.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Insufficient
- Hype gap+25
- Incentives50
- Confidence40
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
On July 25, 2026, a team at Hacktron used an OpenAI employee's Codex to open pull request #1186742 in openai/openai, OpenAI's internal monorepo.
- [2]
They reached the repo by chaining a heap buffer overflow in libheif with an SSO misconfiguration in OpenAI's identity infrastructure.
- [3]
The path from first looking at the forum's image pipeline to repo access took under 72 hours.
- [5]
community.openai.com runs Discourse, which screens uploads with FastImage; FastImage does not support HEIF, so .heic and .heif files were handed to ImageMagick's magick command for conversion, putting attacker-controlled files straight into the libheif parser.
- [6]
The Discourse Docker image was based on Debian 12 and shipped libheif 1.19.7.
- [7]
A heap buffer overflow during HEIC decoding gave out-of-bounds read and write primitives.
- [8]
The fix for the underlying bug had already landed upstream the previous year, but the commit was not labelled a security fix and received no CVE.
- [9]
Hacktron says the missing security label is likely why the backport never reached Debian in time: Debian 12 shipped 1.19.7 and Debian 13 shipped 1.19.8, both vulnerable.
- [11]
OpenAI offers Sign in with OpenAI through auth.openai.com; combined with the SSO misconfiguration, code execution on the forum meant no-interaction takeover of the ChatGPT and Codex accounts of active forum members.
- [12]
Hacktron is explicit that the escalation is not Discourse-specific but an OpenAI SSO issue, and that any first-party or third-party service using that SSO would yield the same access once compromised.
- [13]
On July 24, Opus 4.8 produced a working ImageMagick/libheif exploit with ASLR disabled, but across several sessions could not make it reliable against Discourse's default configuration with ASLR on.
- [14]
Anthropic released Claude Opus 5 that evening; a fresh session produced a working ARM64 exploit for a local Mac within three hours, then ported it to the x86-64 and jemalloc setup Discourse uses.
- [15]
The team ran the model in an autonomous /goal loop against their own Discourse Cloud instance, proxied through rce.ee/ctf-forum to make it look like a CTF target, because Opus refused to write an exploit against a remote instance directly.
- [16]
By 10:00 a.m. the agent had RCE on Discourse Cloud and proved it by reading /etc/hosts, and the same generated script worked against OpenAI's instance.
- [17]
They took over an employee account whose Codex was connected to OpenAI's GitHub organization, prompted that Codex to open the proof-of-concept PR, and stopped.
- [18]
The report went to OpenAI through Bugcrowd, and OpenAI confirmed a fix roughly 14 hours later.
- [19]
Discourse was reported separately through HackerOne, received the report on a Saturday, replied Sunday, had a fix by Monday, and added ImageMagick sandboxing as defense in depth.
- [21]
OpenAI noted that testing against the Discourse-hosted forum was out of scope and that the bounty covers the SSO finding, not the actions against Discourse.
- [22]
The libheif work is one slice of a larger campaign Hacktron calls HEIF Heist, tracing the library across Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks including Next.js, Astro, and Gatsby.
- [23]
Three researchers ran the campaign over two months for under $3,000 in tokens.
- [24]
Adapting the exploit to each new target usually took one or two days, starting almost blind without knowing the libheif version, libc version, or deployment environment.
- [25]
If you self-host Discourse, rebuild with git pull then ./launcher rebuild app from /var/discourse, since a web-interface update alone may not replace the underlying image.
- [26]
If an application processes user-controlled .heic, .heif or .avif images, Hacktron says to assume exposure across the libheif 1.19.x through 1.23.x families.
- [27]
Debian's fixed package arrived 14 days after the proof-of-concept pull request.
- [28]
Hacktron reports a further capability jump from Opus 5 to GPT-5.6 Sol when exploiting targets they knew nothing about beyond that they were vulnerable.
- [29]
Hacktron argues that operationalizing a known memory-corruption bug used to require rare expertise and months of effort, and that compressing that into days of compute changes who can do it.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toOne write past the chunk, read-write on the repo
1 article · October 9, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Single sign-on securityFollow
- Bug Bounty ProgramsFollow
- Image parser vulnerabilitiesFollow
- AI-Assisted Exploit DevelopmentFollow
- Security backportsFollow