In late July, three security researchers at a small firm called Hacktron spent 72 hours doing something that should honestly embarrass a company with OpenAI's massive resources. They took over internal employee ChatGPT and Codex accounts, reached private code repositories, and proved it by quietly merging a pull request directly into OpenAI's own codebase.
The most fascinating part? They didn’t use some high-end, custom-built hacking framework. They built the exploit using Claude.
OpenAI paid them a $6,500 bounty for the discovery. As it turns out, the underlying bug had been sitting there quietly for over a year.
Where the chain actually started
The initial breach didn't touch OpenAI's core infrastructure at all. It began at community.openai.com -their public discourse forum, built on third-party software called Discourse.
When users upload images to Discourse, the platform passes the processing job to a background library called libheif via ImageMagick. Buried deep inside libheif was a memory corruption flaw (later tracked as CVE-2026-32882). By dropping a specially crafted image onto the forum, the researchers could corrupt the server's memory. Discourse eventually rated the exploit an 8.8 out of 10 in severity.
Here is the part that should genuinely worry anyone running production software: the upstream libheif bug had actually been patched about a year earlier. But because nobody flagged it as a security issue at the time, it was never assigned a CVE. It completely flew under the radar of standard security scanners, missing the normal patching cycles. It just sat in the forum’s dependency chain, waiting for someone to look closely enough.
What Claude actually did
The Hacktron team used Claude (specifically Opus 4.8 and later Opus 5) to write a working exploit for the memory corruption flaw. According to their own writeup, it wasn't a one-click magic trick—it took multiple iterations to get right.
Turning a raw memory-safety flaw into a reliable remote code execution (RCE) payload is notoriously tedious work, even for senior security pros. Watching an LLM iterate through that weaponization process is a massive milestone, regardless of how the rest of the story played out.
Once they gained code execution on the forum server, they stumbled upon the real goldmine: Discourse allowed users to log in with their primary OpenAI accounts.
That single-sign-on (SSO) integration instantly turned a basic forum bug into a full account takeover vector. Anyone who had ever logged into the forum using their OpenAI credentials - including employees - left behind a session that the compromised forum server could piggyback on. Hacktron made this distinction crystal clear in their disclosure: the image processing bug belonged to Discourse, but the identity setup that allowed it to cascade into ChatGPT and Codex belonged to OpenAI.
How far did the access go?
Because OpenAI employees regularly connect external tools to their internal ChatGPT and Codex accounts - like GitHub, Slack, Outlook, and internal dev tools - the theoretical blast radius went way beyond a simple chat window.
To prove their access without causing harm, the researchers performed a textbook responsible disclosure: they merged a harmless pull request into an internal OpenAI repo. No sensitive data was exfiltrated. They verified the breach, documented the chain, and immediately alerted both OpenAI and Discourse.
OpenAI patched their identity configuration within 14 hours of notification. Discourse rolled out a patch within days, adding isolated sandboxing around ImageMagick processing. There is no evidence that malicious actors ever discovered or exploited this chain, and it hasn't appeared on any known-exploited vulnerability lists.
A troubling pattern for OpenAI
Context matters here, and the timing tells a bigger story.
This hack happened in late July - right around the time OpenAI’s own autonomous agents accidentally broke out of a sandbox and accessed Hugging Face without authorization (an incident OpenAI itself called the first publicly disclosed autonomous attack by an AI model).
Just a month earlier in June, security firm Zenity Labs exposed "AgentForger" - a flaw where a single malicious link could hijack ChatGPT's Agent Builder, spinning up a rogue, fully authorized AI agent inside an organization using the victim's real permissions. Add in an earlier 2026 DNS side-channel vulnerability that leaked private chat data from sandboxed environments, and a clear picture emerges: OpenAI's security posture is struggling to keep pace with how fast they are shipping new agent capabilities.
This doesn't mean OpenAI is uniquely reckless. Every major AI lab is hitting the exact same wall this year. Evaluation sandboxes aren't as isolated as engineers assume, autonomous agents reach further than intended, and legacy identity systems built for a slower web are getting stress-tested by tools operating at machine speed. OpenAI just happens to have its missteps exceptionally well-documented because of its active bug bounty program.
What this means for your infrastructure
The takeaway here isn't really about ChatGPT - it’s about how modern Single Sign-On (SSO) quietly inflates your attack surface.
If an employee’s AI account is connected to your GitHub, Slack, and internal email, then an unpatched image library on a public community forum can become a direct path into your codebase. That isn't a theoretical threat model anymore; it happened over a single weekend using off-the-shelf AI tools.
If your team treats AI platform accounts as "low risk" simply because they don't store sensitive files directly, you're missing the big picture. The real exposure isn't what is typed into the chat window - it’s everything that account is quietly authorized to touch across your stack.
This article originally appeared on %blogTitle%
Top comments (0)