Researchers chain HEIF decoder flaw and overbroad SSO token to reach internal OpenAI repo

From forum image upload to code execution

According to a writeup on dev.to summarizing security research originally published under the title "Hacking OpenAI," the chain started on OpenAI's Discourse-based community forums. When a user uploads an image, Discourse normally inspects it with FastImage, but that library does not understand the HEIF format. HEIF files are therefore routed to ImageMagick, which delegates decoding to libheif — and version 1.19.7 of that library contained a heap overflow, tracked as CVE-2026-32882. A crafted image was enough to turn image processing into remote code execution.

The Discourse advisory, referenced in the writeup, scored the flaw at 8.8 on the CVSS scale and directed operators to patched versions and Docker rebuilds. The bar for attackers was low: anyone able to post an image to the forum was in a position to try.

Building a reliable exploit was harder than finding the bug. The writeup says the researchers used Claude Opus 4.8 and Claude Opus 5 to help develop an exploit that worked against an ASLR-enabled environment, but stresses that expert guidance was still required and the process was not fully autonomous — a useful data point for anyone tracking how much of offensive security work AI can currently carry on its own.

From compromised forum to internal repository

Code execution in the image-processing container was only the first link. The compromised environment exposed an OpenAI single sign-on token whose permissions went well beyond what a forum session should carry. With that token, the researchers reached the forum user's ChatGPT and Codex account — an account belonging to an OpenAI employee. Because Codex was connected to GitHub on that account, the researchers had it open a pull request making a harmless README edit in an internal repository, purely to demonstrate impact.

According to the writeup, OpenAI confirmed limited access to repository metadata and commits along with the pull request creation, and stated that Slack messages were not accessed. The full chain was reportedly demonstrated in under 72 hours, and OpenAI paid a $6,500 bounty for the issue on its side.

Detection and remediation

The writeup catalogs the traces defenders could have caught: ImageMagick crashes during HEIF conversion, libheif-related exceptions, anomalous memory access and shells inside the image-processing container, unusual SSO tokens, and GitHub activity originating from Codex that no human initiated. On the identity side, the clearest signal is a forum-scoped token being replayed against ChatGPT and Codex APIs.

The fixes are unglamorous but direct: update the decoder, sandbox image processing, rebuild containers, cut SSO tokens down to minimal scopes per use case, revoke existing tokens and sessions, and force re-authentication of connected services. OpenAI, the writeup notes, reduced SSO token permissions and revoked affected tokens and sessions.

Why it matters

Two lessons make this incident worth studying. First, image decoders remain an under-defended attack surface: any service that accepts uploads and leans on ImageMagick inherits every bug in libheif, and the same first step may exist at other organizations the researchers did not test. Second, and more striking, a low-trust community forum became a bridge to internal source code because an SSO token carried far more power than its context required — and an AI coding agent sat at the other end with live GitHub credentials. The chain maps cleanly onto established MITRE ATT&CK techniques: exploiting a public-facing application (T1190), stealing an application access token (T1528), and reusing that token as alternate authentication material (T1550.001), all listed with high confidence in the writeup.

Questions remain open. The exact scopes of the overprivileged token and the full list of affected services are not public, the writeup does not establish whether anyone other than the researchers exploited the path, and the range of other libheif-dependent services vulnerable to an identical opening move is still unknown.