A HEIC image uploaded to a community forum reportedly ended with a pull request inside OpenAI's private monorepo. The exploit crossed an image decoder, a forum server, shared login, an employee's Codex session and a connected GitHub account. That sequence, described by security firm Hacktron, is why the incident matters well beyond OpenAI: several controls that looked separate collapsed into one path. Hacktron says OpenAI closed its side of the chain roughly 14 hours after the initial bug-bounty report.
Researchers Harsh Jaiswal, Mohan Pedhapati and Rahul Maini say they reached remote code execution on community.openai.com on July 25, 2026. They then used an OpenAI single sign-on weakness to access several employee ChatGPT accounts. To demonstrate the result without reading internal code, the team says it instructed one employee's Codex session to create a harmless pull request, numbered 1186742, in the openai/openai monorepo. Hacktron reports that it stopped testing afterward and later received a $6,500 bounty for the OpenAI-side finding. Those account and repository details come from the researchers' disclosure; OpenAI has not published a comparable technical account.
One part of the chain is independently documented. Discourse's advisory identifies CVE-2026-32882, a high-severity flaw that allowed code execution when Discourse processed a malformed HEIF upload. The advisory gives it a CVSS score of 8.8 and says the attack required low privileges, no user interaction and network access. Discourse credits Hacktron as the reporter.
A phone photo format opened the first door
Discourse normally checked uploaded images with FastImage, according to Hacktron's reconstruction. HEIC and HEIF files took a different route because FastImage did not support them: ImageMagick converted the upload, handing attacker-controlled input to the underlying libheif decoder. Hacktron's report traces that format-specific path. A file type added for ordinary phone photos had become an alternate security boundary.
The vulnerable arithmetic had already changed upstream in May 2025, but the commit was titled "simplify overlay overlap area computation". It did not identify itself as a security fix and had no CVE at the time. Hacktron says the Discourse container consequently carried libheif 1.19.7 from Debian 12, while Debian 13 still shipped 1.19.8 during the research. The missing backport left a heap overflow that the researchers developed into out-of-bounds reads and writes, then code execution.
This distinction matters for dependency scanning. A lockfile audit can be clean while the container's operating-system packages still expose an application to hostile input. The Discourse advisory names the application and patched releases; the decoder arrived through the base image rather than the forum's Ruby dependency graph. Teams that inspect only language packages would miss the component that actually parsed the file.
The larger failure sat at the identity boundary
Remote code execution on a forum should have ended at the forum. Hacktron says administrative control of community.openai.com instead provided a route through "Sign in with OpenAI" to ChatGPT and Codex sessions belonging to active forum users. The researchers describe this as an OpenAI identity flaw, separate from the Discourse bug that supplied the first foothold. Their timeline places the initial discovery, report, employee-account proof and shutdown of testing inside a single day.
The public evidence has an important limit. Discourse confirms the malformed-image RCE, its severity and the fixed versions. Hacktron's post is the source for the employee takeover, the internal pull request and OpenAI's response. It reproduces a note attributed to OpenAI saying the forum itself sat outside the bug-bounty program and that the $6,500 award covered the OpenAI-side issue. That scope distinction appears in Hacktron's disclosure, so the full chain should be described as the researchers' account rather than an OpenAI-confirmed postmortem.
The reported GitHub reach came through a connected Codex session. This turns an AI assistant with repository access into part of the authentication perimeter. If a session can create a pull request, anyone who inherits that session may gain the same action, even when GitHub's own login and repository permissions work as designed. Hacktron says it used that existing connection only for the harmless proof. The practical review question is therefore wider than who can sign into the assistant: which connected systems will accept actions from that session?
Claude shortened the exploit work
The researchers also documented how they developed the exploit. They say Claude Opus 4.8 found that security-relevant changes were missing from the installed libheif package and produced a working exploit with address randomization disabled. That model struggled to make the exploit reliable under Discourse's default setup. After Anthropic released Opus 5 on July 24, the team says a new session produced a working Arm64 exploit for a local Mac within three hours, then adapted it to the x86-64 and jemalloc combination used by Discourse. Hacktron gives the model sequence and dates in its technical narrative.
Human direction remained central. Hacktron says the team supplied the target, interpreted crashes, moved between architectures and validated results first on infrastructure it controlled. The post describes the wider HEIF research campaign as two months of work by three researchers, costing less than $3,000 in model tokens. It also states plainly that the hacking was not fully autonomous. Those cost and staffing figures are Hacktron's own accounting, not a general benchmark for automated exploitation.
The operational change is still uncomfortable. A source change that looked like routine arithmetic cleanup could be converted into a working memory-corruption exploit much faster once a skilled team gave a model the right environment and feedback. The model supplied speed; the unpatched decoder and broad identity trust supplied access. The disclosed sequence from package analysis to working Discourse exploit gives defenders a concrete reason to shorten the time between an upstream fix and a rebuilt production image.
Updating the web app may leave the decoder behind
Discourse's repair instructions are unusually specific because the vulnerable library lived inside its Docker image. The project tells self-hosters to rebuild the application container; Hacktron warns that an update performed only through the web interface may not replace the operating-system package underneath it. The relevant commands are short:
cd /var/discourse
git pull
./launcher rebuild app
The advisory lists patched Discourse versions 2026.7.0, 2026.6.1, 2026.5.2 and 2026.1.6. It also says the latest Docker image contains a patched libheif. Debian's DSA-6417-1 fixed CVE-2026-32882 and eleven other libheif issues in 1.19.8-1+deb13u1 for Debian 13. The distribution kept the 1.19.8 base version while adding its backport, which is why comparing version numbers alone can give the wrong answer. Package advisory status and the running container's build matter more.
Upstream has continued shipping security work. The libheif 1.23.4 release, published on September 6, fixes six more security issues, three rated high, and remains API- and ABI-compatible with 1.23.3. Those are separate flaws from the July Discourse advisory. Their proximity shows why patching CVE-2026-32882 should be followed by an inventory of every service that decodes HEIF or AVIF, including background workers and upload proxies that rarely appear in an application's visible feature list.
Discourse added a second wall around ImageMagick
Replacing the decoder addressed the known flaw. Discourse also changed how image tools run. A July 27 commit routes ImageMagick and image_optim calls through Discourse::SafeExec, using Linux Landlock on kernels 5.13 and newer. Its tests deny network access and restrict file reads and writes to explicit paths. If another decoder bug reaches code execution, that process should have fewer files to inspect and no network route for moving onward.
The same separation belongs around identity. A community service should receive only the claims and session authority it needs, while a coding assistant's connector should require its own narrowly scoped authorization. Write actions deserve another confirmation boundary when they target private repositories. Those recommendations follow directly from the five-step trust jump Hacktron reports: parser, forum, SSO, assistant session and GitHub connection. Fixing any one transition could have stopped the proof before the monorepo.
OpenAI's side remains the least documented part. Hacktron says the company fixed it on July 25, yet no public technical advisory explains which identity control failed or whether similar OpenAI SSO clients needed changes. The next useful disclosure would define that boundary and let other integrators test their own assumptions. Until then, the check developers can perform today is concrete: confirm the libheif security status inside the container that is running, rebuild affected Discourse hosts, and verify that untrusted image conversion runs inside the sandbox described in Discourse's published fix.