Security researchers chained a remote code execution flaw in the libheif image decoder with a single sign-on misconfiguration to take over ChatGPT and Codex accounts belonging to OpenAI staff through the company’s own Discourse-hosted forum, with the full attack completed inside 72 hours. The same image-processing library powers a much wider ecosystem, leaving many platforms exposed.
What happened to community.openai.com?
On July 25, 2026, attackers chained two vulnerabilities to seize multiple OpenAI employee accounts on ChatGPT. From those accounts they could reach internal OpenAI repositories and connected services such as GitHub. The entry point was the OpenAI community forum, hosted on Discourse at community.openai.com, where a Sign in with OpenAI option linked forum sessions back to ChatGPT and Codex.
Until the patch landed, any forum user who signed in through that SSO flow could have had their downstream ChatGPT account hijacked without further interaction. Because users can connect third-party services to Codex and ChatGPT, the theoretical blast radius extended to GitHub, Slack, and email. The researchers confirmed access by asking the compromised employee’s Codex agent to open a benign pull request in OpenAI’s internal monorepo, then stopped further testing. OpenAI awarded a $6,500 bounty for the OpenAI-side finding; the forum-side flaw sat outside the program’s stated scope.
How was the exploit chain built?
Two separate weaknesses were combined. The first was a heap buffer overflow in libheif, an open-source HEIC/HEIF/AVIF image decoder used by ImageMagick. The second was an identity-flow flaw in how OpenAI’s SSO handed OpenAI employee sessions into the forum and back out into ChatGPT.
The libheif image decoder flaw
Discourse normally uses FastImage to identify uploaded files. FastImage does not recognise HEIF images, so Discourse passed them to the magick command-line tool from ImageMagick, which uses libheif directly. Attacker-controlled HEIC files therefore reached the libheif parser without additional filtering.
Reviewing the Debian package list inside Discourse’s Docker image, the researchers found that security-relevant fixes had not been back-ported to the libheif version shipped with Debian 12. The vulnerable code had been changed upstream the previous year, but the commit was not flagged as a security fix and received no CVE, which partly explains why neither Debian 12 nor Debian 13 had caught up at the time. The Discourse image installed libheif 1.19.7, and Debian 13 still shipped the vulnerable 1.19.8. Debian later published its security update on August 8, 2026.
Why Opus 5 changed the timeline
Anthropic released Claude Opus 5 in the middle of the research. Earlier Claude Opus 4.8 sessions failed to produce a working exploit against ASLR-enabled code across multiple attempts. A fresh Opus 5 session delivered an ARM64 exploit for a local Mac within three hours, then ported it to the x86-64 jemalloc environment used by Discourse. By 6:00 a.m. UTC on July 25, the team had confirmed local code execution from an image upload. Running the same model in an autonomous loop against a Discourse Cloud instance resulted in remote code execution within hours. The same script then delivered RCE on OpenAI’s instance.
The SSO flaw that turned RCE into account takeover
Once the team had a foothold on the forum, they confirmed that a logged-in OpenAI employee session on Discourse could be converted into a takeover of that employee’s ChatGPT and Codex accounts with no further user interaction. The research team emphasised that the escalation path is not Discourse-specific. Any first-party or third-party OpenAI service that authenticated through the same SSO flow would have yielded the same downstream access; the forum was simply the chosen proof.
What was the full disclosure timeline?
- July 25, 05:00 to 06:00 UTC: Initial discovery, with remote code execution and admin access obtained on the Discourse environment hosting community.openai.com.
- July 25, 08:00 to 10:00 UTC: Report submitted to OpenAI through the Bugcrowd bug bounty program after cross-product impact was confirmed.
- July 25, 13:30 to 15:30 UTC: Proof-of-concept impact demoed by opening a harmless pull request from a compromised employee’s Codex account, then all further testing ceased.
- July 25, 22:49:45 UTC: OpenAI confirmed the issue fixed, roughly 14 hours after the report.
- July 25: Separate report filed with Discourse through HackerOne.
- July 26: Discourse acknowledged the report on Sunday.
- July 27: Discourse shipped a fix and added image-processing sandboxing as defence in depth.
- July 28: Discourse published advisory GHSA-vhm9-85gw-x335.
- September 1, 2026: OpenAI issued the $6,500 reward and marked the report resolved.
How much did this kind of research cost?
The combined Discourse and OpenAI work took a few days for an AI agent and only a few hours of human direction. The wider investigation, which the team calls HEIF Heist and which now covers Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks including Next.js, Astro, and Gatsby, ran for two months, cost less than $3,000 in model tokens, and involved three researchers. Adapting the exploit to each new company typically required only one or two days.
Across HEIF Heist, no target flagged the activity, with the sole exception of Shopify, even after thousands of images were sent and image processors crashed repeatedly. When code execution landed inside a sandbox, the models also helped with privilege escalation, lateral movement, and bypassing existing defences. Skilled human guidance remained important, but the work a small team could perform expanded sharply with each new model generation.
Who is exposed to the same libheif bug?
HEIF Heist is not tied to one library version. It targets an ecosystem of vulnerabilities spread across the 1.19.x, 1.20.x, 1.22.x, and 1.23.x release families. Any deployment that lacks the latest upstream security patches is potentially vulnerable. As of September 14, 2026, the current upstream security release is libheif v1.23.4, and v1.23.2 has already been superseded by further fixes. Distribution packages may carry backported fixes under older upstream version numbers, so distribution security advisories should also be checked.
Self-hosted Discourse administrators
Discourse self-hosters should rebuild now. Older Docker images may contain a vulnerable libheif dependency, and a web-interface update alone may not replace the underlying image. The recommended command sequence from the Discourse launcher path is git pull followed by ./launcher rebuild app, run from /var/discourse. Discourse-hosted customers were already patched.
Defence in depth for image processing
Given the complexity of the ISO base media file format and the speed at which decoder bugs have been appearing, future memory-safety flaws are likely. Production architectures should disable untrusted HEIF and AVIF decoding where it is not needed, or isolate image-processing pipelines inside hardened, ephemeral sandboxes. ImageMagick’s security policy supports restricting accepted formats and resource usage.
What does this say about AI-assisted exploitation?
Memory corruption bugs were public in many cases, but turning a bug into a reliable exploit against a real target often required rare expertise, long timelines, and detailed knowledge of the specific environment. Weaponising known vulnerabilities cost significant time and expertise, and zero-days were mostly reserved for the highest-value targets. That difficulty gap was never a real security boundary, but it often shielded ordinary companies from attack.
AI is now compressing that expertise into compute. Months of work for a well-resourced team can now be measured in days for a small team, and threat models need to be recalibrated to the economics of exploitation as it stands now. Workshops that target image processing pipelines should consider the fact that an attacker can iterate against an unknown environment with image uploads alone, and design their detection, sandboxing, and patch cadence accordingly.
For software vendors, the practical takeaway is twofold. Track upstream library security advisories actively rather than relying on distribution backports, because some fixes never receive CVE numbers. Audit every path through which third-party logins flow into high-privilege services, since a compromise of any linked first-party or third-party service can become an account takeover on the whole identity graph.
FAQ
What was the core vulnerability behind the OpenAI ChatGPT account takeover?
The chain combined a heap buffer overflow in the libheif image decoder inside Discourse’s image-upload pipeline with an OpenAI single sign-on flow that turned a forum session into ChatGPT and Codex account access. The libheif version shipped with Debian 12 and 13 was missing security-relevant backports.
How long did the OpenAI account takeover chain take to develop?
From initial discovery to confirmed access on an OpenAI employee account, the full chain took less than 72 hours. The team confirmed local RCE through an image upload by 6:00 a.m. UTC on July 25, 2026, and stopped testing the same day.
What should organisations using libheif do now?
Update libheif and libde265 through the distribution’s security channel or take the latest upstream security-patched release, then rebuild any container images that bundle the libraries. Self-hosted Discourse installs should run git pull and ./launcher rebuild app from /var/discourse, and consider ImageMagick sandboxing as defence in depth.
Related coverage
- OpenAI Restricts ChatGPT Rollout at Trump Admin’s Request
- OpenAI’s ChatGPT superapp plan, explained
- OpenAI Rolls Out ChatGPT Voice in Real Time
Want help with this in Myrtle Beach or Long Island? Talk to us.
NewSunSEO
Grow in Google and AI Search
AI-SEO, local search, paid ads and websites from one team, with offices on Long Island and in Myrtle Beach.
- AI-SEO
- Local AI-SEO
- AI Consulting
- PPC
- Web Design
- Web Development
- Long Island Office(631) 320-1700
- Myrtle Beach Office(843) 492-7131
Request a Free Proposal
Tell us about your business and where you want to grow.
We will reply by email to talk through your goals and what a proposal would include.
We use your details only to reply to you and send what you asked for. See our Privacy Policy.
