In July 2026, a three-person team at Hacktron AI chained a memory-corruption bug in libheif (yes, the HEIC/HEIF image decoder) with an SSO misconfiguration to take over OpenAI employee ChatGPT/Codex accounts — and prove access to an internal GitHub monorepo. The most interesting part isn't the bug. It's that the working exploit was built by Claude, and that a single model upgrade turned a failing exploit into a working one within hours.
Here's the technical chain, end to end.
The entry point
OpenAI's community forum (community.openai.com) runs Discourse and supports "Sign in with OpenAI." Discourse normally checks uploaded images with FastImage — but FastImage doesn't support HEIF, so those files get routed to ImageMagick, which hands off to libheif for decoding. HEIC is the default photo format on iPhones, so any user posting a screenshot hits this path.
Hacktron pointed Claude Opus 4.8 at the Discourse Docker image and asked it to audit the installed libheif package. It found that certain upstream security fixes had never been backported — leaving a heap buffer overflow with OOB read/write during HEIC decoding.
The bug nobody tracked
The uncomfortable detail: the fix already existed upstream, months earlier — but it was never flagged as security-relevant and never got a CVE. No CVE means no signal for downstream distros to backport it. Discourse's Docker image, built on Debian 12, shipped vulnerable libheif 1.19.7. Even Debian 13 was still shipping a vulnerable 1.19.8 at the time (patched in early August).
This is the same bug shape as three CVEs disclosed for libheif around the same window — worth knowing if you run anything that touches HEIF/AVIF:
| CVE | Bug | Impact |
|---|---|---|
| CVE-2026-32741 |
memcpy in mask-image decode copies attacker-controlled length into a fixed buffer, no bounds check |
Heap corruption / potential RCE |
| CVE-2026-32814 | Grid-tile decode silently "succeeds" on a corrupted tile, leaving uninitialized heap bytes in the output pixels | Cross-user info leak (4KB+/plane) in any server that re-encodes uploads |
| CVE-2026-32882 | Discourse's own tracked advisory for the RCE path through ImageMagick/libheif | RCE via image upload, CVSS 8.8 |
All root in the same pattern: libheif trusting attacker-supplied length/geometry fields without validating against actual buffer size. Fixed upstream in 1.22.0; current hardened release is 1.23.4.
Turning it into RCE
Opus 4.8 got a working exploit with ASLR disabled but failed repeatedly against Discourse's real ASLR-enabled config. Claude Opus 5 shipped that evening. A fresh session produced a working ARM64 exploit locally within 3 hours, ported it to Discourse's actual x86-64/jemalloc setup, and by the next morning the team had confirmed local RCE via image upload.
They then ran the model in an autonomous loop against their own cloud instance — proxied to look like a CTF target, since the model refused to knowingly attack a real production system. It got RCE within hours and proved it by reading /etc/hosts. That exploit script was then run against OpenAI's actual instance.
Notable: the safety boundary was worked around by disguising the target, not defeated outright. And the capability delta between model generations wasn't gradual — same bug, same environment, one version failed repeatedly, the next succeeded in hours.
From forum RCE to internal repos
The real prize was OpenAI's SSO, not the forum itself — any service trusting that identity layer would've offered the same escalation. After confirming zero-interaction account takeover, the team reported immediately, took over one employee's account (whose Codex was GitHub-connected), and had that Codex open a harmless proof-of-concept PR in OpenAI's private monorepo before stopping.
Response
OpenAI confirmed a fix ~14 hours after submission (revoked tokens, narrowed SSO scopes) and paid a $6,500 bounty. Discourse shipped a fix within days, published GHSA-vhm9-85gw-x335, and added ImageMagick sandboxing.
Why it matters beyond OpenAI
Hacktron folded this into a broader "HEIF Heist" project tracing libheif's footprint across Slack, Meta, GitHub Enterprise, and JS frameworks (Next.js, Astro, Gatsby). Their economics: the whole multi-company campaign cost under $3,000 in tokens, ran two months, and typically took 1–2 days to adapt to a new target — starting blind on version info. They say they went undetected everywhere except Shopify, despite sending thousands of malformed images.
Takeaways
- "No CVE" ≠ "not a security fix." Unlabeled upstream memory-safety commits in media codecs can be exactly as dangerous as CVE-tracked ones — check commit logs, not just advisories.
- Patch to actual upstream versions, not just what your distro claims is "latest."
- Sandbox untrusted media decoding. ImageMagick's policy file can restrict formats and resources; process-level isolation is better still.
- SSO is your real blast radius. The forum was incidental — the identity trust relationship is what turned a decoder bug into internal repo access.
Sources: Hacktron AI ("Hacking OpenAI"), TechCrunch, VentureBeat, Cybernews, BetaNews, SOFX, XenoSpectrum (Sept 13–19, 2026); CVE/OSV/Debian/Red Hat records for CVE-2026-32741, CVE-2026-32814, CVE-2026-32882.
Top comments (0)