The short version: how an OpenAI forum flaw became a ChatGPT account takeover
A pair of vulnerabilities, an image decoder bug in a help-desk platform and a single sign-on misconfiguration on a frontier AI company’s identity service, were chained together to take over ChatGPT and Codex accounts, including at least one belonging to an OpenAI employee whose Codex was connected to the company’s GitHub organization. The full chain from first discovery to proof of internal repository access took under 72 hours, and OpenAI paid a $6,500 bug bounty for the OpenAI-side finding.
What was actually exploited?
Two separate bugs combined to produce account takeover.
- An image-decoder bug in libheif. The OpenAI community forum at community.openai.com runs on Discourse. Discourse normally inspects uploaded images with FastImage, but FastImage does not understand HEIF or HEIC files, so those uploads get handed off to ImageMagick’s
magickcommand for conversion. ImageMagick in turn calls libheif to decode the file. The Discourse Docker image in use was based on Debian 12, which shipped libheif 1.19.7, a version that contained an unfixed heap buffer overflow with out-of-bounds read and write primitives. Debian 13’s 1.19.8 was also vulnerable at the time. The upstream fix had landed the previous year but was not tagged as a security patch and received no CVE, which is why the Debian security backport never landed. - An SSO misconfiguration on the OpenAI side. OpenAI’s own forum uses the auth.openai.com identity flow. The misconfiguration was the actual escalation: any account that could log into the forum could also be used to access ChatGPT and Codex, including for any user or employee who had signed in there. Because Codex can be connected to GitHub, Slack, and email integrations, the theoretical blast radius extended well beyond the forum.
The exploit chain, step by step
The researchers began by reviewing Discourse’s image-upload pipeline on July 23 and traced HEIC uploads into ImageMagick and libheif. With help from a Claude Opus 4.8 session that pointed out the missing security backports in the Debian libheif package, they built a local exploit against an ImageMagick plus libheif setup with ASLR disabled. Reproducing it reliably against Discourse’s default ASLR-enabled configuration took several sessions without success.
That changed when Anthropic released Claude Opus 5 the same evening. Within three hours, the new model produced a working ARM64 exploit for a local Mac. Asked to port that exploit to the x86-64 environment with the jemalloc configuration Discourse uses, the model produced a working local remote-code-execution proof by 06:00 UTC on July 25 from an image upload. Run in an autonomous loop against a Discourse Cloud instance, the agent achieved remote code execution by 10:00 UTC and demonstrated access by reading /etc/hosts.
Once the researchers had RCE on the OpenAI-hosted Discourse, they were able to take over active ChatGPT and Codex accounts without user interaction. To prove the scope without actually reading internal code, they used one compromised employee’s Codex to open a pull request against OpenAI’s internal monorepo openai/openai, then stopped all further testing at 15:30 UTC. OpenAI confirmed the fix at 22:49:45 UTC the same day.
How fast did the disclosure move?
- July 25, 05:00 to 06:00 UTC: local RCE confirmed through an image upload.
- July 25, 08:00 to 10:00 UTC: RCE reproduced against Discourse Cloud, then the OpenAI-hosted instance.
- July 25, 13:30 to 15:30 UTC: harmless proof-of-concept pull request opened in OpenAI’s monorepo, then testing halted.
- July 25, 22:49:45 UTC: OpenAI confirmed the issue fixed, roughly 14 hours after submission.
- July 25: report submitted to Discourse via HackerOne.
- July 27: Discourse had a fix ready and added image-processing sandboxing as defense in depth.
- July 28: Discourse published advisory GHSA-vhm9-85gw-x335 with patch and rebuild guidance.
- September 1: OpenAI paid the $6,500 bounty and marked the report resolved. OpenAI noted that testing against community.openai.com itself was outside the bug bounty scope; the award covers the OpenAI-side finding.
Is this just a Discourse problem?
No. The escalation step was an OpenAI SSO issue, not a Discourse-specific flaw. Discourse was used as the entry point because it accepted the auth.openai.com identity flow, but the same account takeover would have followed from any other first- or third-party OpenAI service that authenticated through the same flow and was compromised. The image-decoder bug is also not Discourse-specific. The same researchers have been running a multi-month follow-on project, HEIF Heist, tracing libheif across Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks such as Next.js, Astro, and Gatsby. Applications that process user-controlled images and accept .heic, .heif, or .avif files are likely affected if they are not on a patched libheif.
What self-hosted Discourse operators need to do
Rebuild the container, do not just apply a web-interface update. Older Discourse Docker images may carry a vulnerable libheif dependency, and a web-only update will not replace the underlying image-processing library. From /var/discourse, run git pull followed by ./launcher rebuild app. Discourse-hosted customers have already been patched. See advisory GHSA-vhm9-85gw-x335.
How widespread is the libheif risk?
Versions affected are not limited to a single release. Any deployment missing the latest upstream security patches across the 1.19.x, 1.20.x, 1.22.x, or 1.23.x families is potentially vulnerable. As of September 14, 2026, the latest upstream libheif security release is v1.23.4; v1.23.2 has been superseded by further security fixes. Distribution packages may carry backported fixes under older version numbers, so check the package security advisory. Debian published its security update for Debian 13 on August 8, 2026.
What did AI change about this attack?
The Discourse plus OpenAI exploit took a few days for an AI agent and just a few hours of human time. Across the full HEIF Heist project, three researchers spent two months and less than $3,000 in tokens total. Adapting the exploit to each new target usually took one or two days. The progression was visible inside this single campaign: Opus 4.8 failed across several sessions to produce a working exploit with ASLR enabled, and Opus 5 solved the same problem within hours of release. Across the wider campaign, GPT-5.6 Sol produced another clear jump, exploiting the vulnerability without knowing anything about the target system beyond the fact that it was vulnerable, starting from an image upload and turning memory corruption into a memory leak or shell usually without knowing the exact libheif version, libc version, or deployment environment. When code execution landed inside a sandbox, the models also helped with privilege escalation, lateral movement, and bypassing existing defenses. The research was not fully autonomous, and skilled human guidance remained important, but the amount of work a small team could perform increased dramatically.
What should defenders take from this?
Memory corruption bugs that used to be expensive to weaponize are now within reach of a small team using AI agents. The implication is not that any specific attacker is using AI, it is that the economics of exploitation have moved. A realistic threat model in 2026 should account for image uploads, identity flows, and decoder dependencies as live attack surface, not theoretical ones.
Two specific changes are worth making:
- Patch image-processing dependencies quickly and track distribution-specific security advisories even when no CVE exists upstream. A commit that fixes memory corruption is worth treating as a security fix even if it was not labeled as one.
- Add defense in depth around image pipelines. The ISO base media file format is complex and decoders change often, so future memory-safety flaws are likely. Where possible, disable untrusted HEIF and AVIF decoding in production, or isolate image-processing inside hardened ephemeral sandboxes. ImageMagick’s security policy supports restricting accepted formats and resource usage.
FAQ
What vulnerability let attackers take over ChatGPT and Codex accounts?
Two chained issues: a heap buffer overflow in the libheif image decoder reachable through HEIC uploads on the OpenAI-hosted Discourse forum, and an SSO misconfiguration on auth.openai.com that tied Discourse logins to ChatGPT and Codex access.
How long did it take to go from the first bug to internal OpenAI access?
Less than 72 hours from initial discovery on July 23 to a proof-of-concept pull request opened in OpenAI’s internal monorepo on July 25.
What should self-hosted Discourse operators do right now?
Rebuild the container. From /var/discourse run git pull then ./launcher rebuild app. A web-interface update alone does not replace the underlying libheif dependency. See Discourse advisory GHSA-vhm9-85gw-x335.
This article summarizes reporting from hacktron.ai.