One write past the chunk, read-write on the repo

Updated 11 October 2026: libheif v1.23.4 has been superseded by v1.23.5 (21 September) and v1.23.6 (5 October).

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. They got there by chaining a heap buffer overflow in libheif with an SSO misconfiguration in OpenAI’s identity infrastructure. The path from first looking at the forum’s image pipeline to repo access took under 72 hours. OpenAI paid a $6,500 bounty.

How the forum became a path into the repo

community.openai.com runs Discourse. Discourse checks uploaded images with FastImage, but FastImage does not support HEIF, so .heic/.heif files were handed to ImageMagick’s magick command for conversion. That put attacker-controlled files straight into the libheif parser. The Discourse Docker image was based on Debian 12 and shipped libheif 1.19.7. A heap buffer overflow during HEIC decoding gave out-of-bounds read and write primitives.

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. That 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. Debian published its Debian 13 update on August 8, 2026.

RCE on the forum mattered because OpenAI offers “Sign in with OpenAI” through auth.openai.com. Combined with the SSO misconfiguration, forum code execution meant no-interaction takeover of the ChatGPT and Codex accounts of active forum members. Hacktron is explicit that the escalation is not Discourse-specific. It is an OpenAI SSO issue, and any first-party or third-party service using that SSO would yield the same access once compromised. The forum was just the way they proved it.

The model did the hard part

The memory-corruption work is where the story turns. On July 24, Opus 4.8 produced a working ImageMagick/libheif exploit with ASLR disabled, but across several sessions it could not make the exploit reliable against Discourse’s default configuration with ASLR on. 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. By 6:00 a.m. on July 25, Hacktron had confirmed local RCE through an image upload.

They then put 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. By 10:00 a.m. the agent had RCE on Discourse Cloud and proved it by reading /etc/hosts. The same generated script worked against OpenAI’s instance.

From there 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. The report went to OpenAI through Bugcrowd; OpenAI confirmed a fix roughly 14 hours later. 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. Discourse published advisory GHSA-vhm9-85gw-x335. 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.

What this costs an attacker now

This 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. Three researchers ran it over two months for under $3,000 in tokens. 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. They also report a further capability jump from Opus 5 to GPT-5.6 Sol when exploiting targets they knew nothing about beyond “it’s vulnerable.”

That is the practical shift for anyone running these systems. Operationalizing a known memory-corruption bug used to require rare expertise and months of effort, which kept ordinary companies safe in practice even when the bug was public. Compressing that into days of compute changes who can do it.

If you self-host Discourse, rebuild now: git pull then ./launcher rebuild app from /var/discourse, since a web-interface update alone may not replace the underlying image. More broadly, if your application processes user-controlled .heic/.heif/.avif images, assume exposure across the 1.19.x through 1.23.x families. Update to the latest security-patched libheif and libde265 (v1.23.6 upstream as of October 5, 2026, whose notes rate four of its fixes high and advise all users to upgrade), and check distribution advisories rather than version numbers, since backports carry older numbers. Where untrusted HEIF/AVIF decoding is not needed, disable it, or isolate the pipeline in a hardened, ephemeral sandbox. ImageMagick’s security policy can restrict accepted formats and resource use.

One detail worth keeping: the attack sent thousands of images and repeatedly crashed targets’ image processors, and the only company known to have noticed was Shopify. Repeated decoder crashes were the visible signature, and almost nobody was watching it.

---

Contains a referral link.