OpenAI ChatGPT accounts compromised through forum image upload vulnerability
A pair of vulnerabilities chained together gave attackers a path from an image upload on OpenAI’s community help forum to takeover of employee ChatGPT and Codex accounts, including access to a connected GitHub organization, with a proof-of-concept pull request opened in the internal monorepo as the demonstration of impact. The OpenAI-side issue was fixed within roughly 14 hours of disclosure, and the underlying image-decoder flaw was patched upstream and in the Discourse platform within days.
What the exploit chain looked like
The attack started with a heap buffer overflow in libheif, the library used to decode HEIC and HEIF image files inside the Discourse image pipeline. Discourse normally uses FastImage for image checks, but FastImage does not handle HEIF, so those files were passed to ImageMagick’s magick command for conversion, exposing the underlying libheif parser directly to attacker-controlled files.
The vulnerable code path had been changed upstream the previous year, but the commit was never documented as a security fix and received no CVE, so the backport never reached Debian 12 or Debian 13 in time. Discourse’s Docker image, based on Debian 12, was running libheif 1.19.7, and Debian 13 was still shipping a vulnerable 1.19.8 at the time.
The attackers turned the memory-corruption bug into a working ImageMagick and libheif code-execution exploit with the help of an AI coding model. After Opus 5 was released, they pointed a new session at the same problem and got the exploit working against a default Discourse configuration with ASLR enabled within hours. They then ran the agent in an autonomous loop against their own Discourse Cloud instance until it achieved remote code execution, and reused the generated script to gain RCE on OpenAI’s community.openai.com instance.
From a forum compromise to ChatGPT and Codex account takeover
The forum exploit by itself did not produce an OpenAI breach. OpenAI runs its community on Discourse and enables Sign in with OpenAI through auth.openai.com. That SSO link is what made a forum compromise equivalent to a ChatGPT and Codex account takeover for any active member of the forum, including OpenAI staff. The weakness was in the identity flow, not in Discourse itself: any first-party or third-party OpenAI service authenticating through the same SSO could have produced the same access if compromised.
Once an OpenAI employee’s account was under control, the connected Codex integration to OpenAI’s GitHub organization was reachable. The attackers did not read internal code. Instead, they sent a prompt through the employee’s Codex account that opened a proof-of-concept pull request, PR #1186742, in OpenAI’s internal monorepo. That pull request was the evidence of impact. All further testing stopped the same day.
Timeline from initial finding to fix
The full sequence, in UTC, ran as follows. On July 25 at 05:00 to 06:00, the team confirmed remote code execution and administrative access to community.openai.com. Between 08:00 and 10:00, they submitted a report through OpenAI’s Bug Bounty Program on Bugcrowd. Between 13:30 and 15:30, they created the proof-of-concept pull request in the internal monorepo, updated the Bugcrowd submission, and notified OpenAI security directly. At 22:49:45, OpenAI confirmed the fix.
The Discourse side ran in parallel. The Discourse report was submitted via HackerOne on July 25, Discourse replied the next day, had a fix ready by July 27, and published advisory GHSA-vhm9-85335-x335 on July 28. As a defense in depth move, Discourse added image-processing sandboxing on top of the patch. On September 1, OpenAI closed the case and paid a $6,500 bounty. The bounty covered the OpenAI-side finding; testing against the Discourse-hosted community.openai.com was explicitly excluded from OpenAI’s bug bounty scope.
How much human and AI effort it actually took
The attackers describe the Discourse and OpenAI work as a few days of agent time and only a few hours of human time. The broader HEIF Heist research project, which traced libheif across Slack, Meta, GitHub Enterprise, Ruby on Rails, and JavaScript frameworks including Next.js, Astro, and Gatsby, took about two months for three researchers and cost less than $3,000 in tokens. Porting the exploit to each new company typically took one or two days.
The report highlights a clear jump in capability between model generations. Opus 4.8 struggled across several sessions to produce a working ASLR-enabled exploit; Opus 5 produced one within hours of release. Across the wider campaign, GPT-5.6 showed a further jump at adapting the exploit when given nothing about the target environment except that it was vulnerable.
Who detected the activity
Across the campaign, which involved thousands of uploaded images and repeated crashes of image processors at multiple companies, the report states that no company detected the activity except Shopify. When code execution landed inside a sandbox or restricted environment, the same AI-assisted process handled privilege escalation, lateral movement, and bypassing existing defenses.
What is affected and how to patch
The issue is not a single version. Multiple libheif release families, including 1.19.x, 1.20.x, 1.22.x, and 1.23.x, contained applicable flaws. Any deployment without the latest upstream security patches is potentially vulnerable.
- Install the latest security-patched libheif and libde265 packages through your distribution’s security channel, or an upstream release. As of September 14, 2026, the latest upstream release is v1.23.4; v1.23.2 has been superseded by further fixes.
- Distribution packages may carry backported fixes under an older upstream version, so check the package security advisory as well.
- For self-hosted Discourse, rebuild the installation from /var/discourse with git pull followed by ./launcher rebuild app. A web-interface update alone may not replace the underlying image, and older Docker images can still pull in a vulnerable libheif dependency.
- Production architectures handling untrusted user images should consider disabling HEIF and AVIF decoding where it is not needed, and isolating image-processing pipelines inside hardened, ephemeral sandboxes. ImageMagick’s security policy supports restricting accepted formats and resource usage.
What the broader research turned up
The HEIF Heist investigation traced the same library through Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks such as Next.js, Astro, and Gatsby. A large share of widely used software depends on this single image-processing library. Applications that process user-controlled images and accept .heic, .heif, or .avif files are likely to be affected.
The report frames the long-term lesson in terms of attacker economics. Memory-corruption bugs and even working exploits have historically been public for years without being weaponized at scale, because turning a bug into a reliable exploit required rare expertise and detailed knowledge of the target environment. AI-assisted research is compressing that work into days, which means defenders need threat models that account for the new economics of exploitation rather than relying on outdated assumptions about who can carry out a sophisticated attack.
For any business relying on AI-driven search and discovery, the practical lesson is that the integrity of the identity layer matters as much as the integrity of the app it sits in front of. A misconfigured SSO flow turned a third-party forum into a path to internal code repositories, and that is the kind of cross-product chain an audit needs to look for.
FAQ
What vulnerability was used to access OpenAI employee accounts?
A heap buffer overflow in libheif, exposed through Discourse’s image-upload pipeline, was chained with an SSO misconfiguration in OpenAI’s identity flow. That combination allowed remote code execution on community.openai.com and, through the Sign in with OpenAI SSO link, takeover of ChatGPT and Codex accounts for active forum members, including OpenAI employees.
How quickly did OpenAI fix the issue?
OpenAI confirmed the fix roughly 14 hours after the initial Bugcrowd submission on July 25, 2026, and marked the case resolved on September 1, 2026, with a $6,500 bounty. The Discourse-side libheif issue was reported the same day via HackerOne and was fixed and published as advisory GHSA-vhm9-85gw-x335 by July 28, 2026, with image-processing sandboxing added as defense in depth.
Which systems are affected by the libheif flaw?
Affected code is not tied to a single version. Vulnerable release families include 1.19.x, 1.20.x, 1.22.x, and 1.23.x. The HEIF Heist research traced the library through Slack, Meta, GitHub Enterprise, Ruby on Rails, and JavaScript frameworks including Next.js, Astro, and Gatsby. Applications that process user-controlled images and accept .heic, .heif, or .avif files are likely to be affected and should update to a security-patched build, with deployment-specific sandboxing where possible.
This article summarizes reporting from hacktron.ai.