Three researchers at Hacktron just took over ChatGPT and Codex accounts belonging to OpenAI staff. The attack did not rely on phishing techniques or a leaked password. Through an image upload on OpenAI’s own help forum.
The forum runs on Discourse, and until recently anyone logging in there through “Sign in with OpenAI” could, in theory, have had their ChatGPT and Codex accounts hijacked. Since staff connects all sorts of services to those accounts, GitHub, Slack, email, the actual blast radius was enormous. The whole thing, from first finding the bug to sitting inside an internal OpenAI repository, took less than 72 hours.
Here’s how the attack worked. Discourse sends HEIC and HEIF image uploads to ImageMagick for processing, which uses a library called libheif to decode the files. A heap buffer overflow was found in that process. This type of memory bug can allow an attacker to read or write data outside the area the program is supposed to access.
The vulnerability had actually been fixed upstream the previous year, but the fix did not have a CVE and was not backported to Debian in time.
Normally, turning a bug like this into a working exploit can take weeks. This time, AI helped speed things up. The researchers first gave the task to Claude Opus 4.8, but it struggled once protections such as ASLR were enabled. After Anthropic released Opus 5, they gave it the same task in a new session. The model managed to build a working exploit against a local Mac in just three hours.
That’s the detail worth sitting with, and it’s exactly what caught wider attention. As the researchers put it themselves:
“The Discourse and OpenAI hack took a few days for an agent, and just a few hours of human time. The whole HEIF Heist research project going after Slack, Meta, adn more took two-months, cost less than $3,000 in tokens in total, and was conducted by three researchers. Adapting the exploit to each new company usually took only one or two days.” reads the report published by Hacktron.
“We observed that every new model is getting increasingly capable, as evident by the Discourse exploit presented in this report. Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5’s release, we gave it the same problem and it succeeded. Across the broader campaign, we saw another clear jump from Opus 5 to GPT-5.6 Sol, when we had to exploit the vulnerability without knowing anything about the target system besides that it’s vulnerable.”
From there things moved fast. They ported the exploit to match Discourse’s actual server setup, x86-64 running jemalloc, confirmed local code execution by 6 am, then pointed the model at their own cloud instance, disguised as a capture-the-flag target since Opus 5 refused to attack anything it recognized as a live system. By 10 am the agent had root-level access and had read /etc/hosts
to prove it. They then used the same exploit against OpenAI’s actual instance.
To prove the account takeover was real without touching anything they shouldn’t, they used one hijacked employee’s Codex to open a single, harmless pull request in OpenAI’s internal code repository. No source code read, nothing merged, nothing shipped. Then they stopped, reported everything to OpenAI and to Discourse, and waited.
Both moved quickly. OpenAI confirmed a fix about 14 hours after the initial report and eventually paid a $6,500 bounty, though it drew a careful line around what that bounty actually covered:
“OpenAI Rewarded $6,500 Bounty and Marked Resolved; OpenAI comment — To clarify the scope of that award: testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program. The award recognizes the OpenAI-side finding, not the actions against Discourse.” continues the report.
Discourse, for its part, had a patch ready by the following Monday and added sandboxing around its image processing as extra protection. Fair play to them, that’s a genuinely fast turnaround for a stack most companies don’t touch until something’s already on fire.
The bigger point isn’t really about one forum bug. It’s about what happens when a low-trust, public-facing service shares single sign-on with everything sensitive behind it. The researchers were blunt about where the real fault sits.
“We want to emphasize that the vulnerability to escalate is not Discourse-specific.” Hacktron states. “It is an OpenAI SSO issue that turned the forum compromise into access to ChatGPT and Codex. If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to same access – Discourse was merely one way of proofing it.”
That’s not a Discourse problem, and it’s not really an image-library problem either. It’s an identity architecture problem, and those don’t show up on a dependency scan.
This case sits inside a bigger project the team calls HEIF Heist, two months of chasing the same libheif issue across companies including Slack, Meta, GitHub Enterprise, and frameworks like Next.js. Total cost across three researchers: under $3,000 in AI usage. That number alone tells you something has shifted. Exploiting memory corruption bugs used to require rare, expensive expertise and months of grinding. Now it’s mostly compute, and compute is cheap and getting cheaper.
If your product accepts HEIC, HEIF, or AVIF uploads anywhere in the pipeline, check what version of libheif is actually running underneath, not just what your package manifest says. And if a public forum, support portal, or any low-trust surface shares login with your real infrastructure, that shared login is the actual attack surface, whatever the forum software’s own security record looks like.
“Security assumptions must catch up with attacker capabilities. A realistic threat model should take into account the economics of exploitation today, instead of relying on outdated assumptions about who can carry out sophisticated attacks.” concludes the report.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, OpenAI)