Three security researchers used Claude Opus 5 to exploit a heap buffer overflow in libheif, gaining write access to OpenAI's internal monorepo within 72 hours through vulnerabilities in the community forum and single sign-on system. They discovered an unpatched flaw in image processing that enabled remote code execution on the Discourse server, then leveraged compromised employee credentials to access GitHub integrations.
OpenAI awarded only a $6,500 bounty despite the breach's severity, arguing the initial vulnerability existed on third-party infrastructure. The incident exposed broader ecosystem risks, as the same libheif vulnerability affected Slack, GitHub Enterprise, and Meta, highlighting how unmaintained dependencies create widespread security exposure across major tech platforms.
Something crazy just happened in the AI world. Three guys with Claude and Codex subscriptions were able to use Opus 5 to access OpenAI auth tokens and gain write access to OpenAI’s monorepo over the course of two days.
My first reaction is… How? We are not talking about some classified, unreleased military-grade intelligence model like Mythos. This was done using Opus 5.
What does this tell us about OpenAI’s security?
Well, I remember what former OpenAI researcher Leopold Aschenbrenner said back in April 2024 after he got fired.
He circulated an internal memo and then went on the Dwarkesh Patel Podcast to warn everyone that OpenAI’s security was egregiously insufficient to protect core algorithmic secrets from foreign actors.
Looking at what just unfolded, was he right all along?
Who the hackers are
The breach was discovered and executed by the team at HacktronAI, led by security researchers rootxharsh, iamnoooob, and S1r1u5. You can see their original announcement on X and watch their technical breakdown on YouTube.
These researchers are not random kids messing around in a basement. They are established industry professionals who regularly audit and secure architectures for platforms like Perplexity and Vercel.
When they turned their focus toward OpenAI, they found an attack path that took them from an external public forum all the way to internal source code in under 72 hours.
The entry point for this entire chain was the OpenAI Community Forum, which runs on Discourse. Discourse relies on ImageMagick to process image uploads, which in turn calls libheif to decode HEIC and HEIF files.
The researchers discovered a heap buffer overflow vulnerability in libheif.
What makes this frustrating is that a patch was already committed to the libheif GitHub repository. Upstream maintainers had fixed the bug but never labeled it as a security release.
For devs, you can see the code changes in that specific commit.
Because there was no CVE or security flag, downstream platforms like Discourse never pulled the update. This left their production instances exposed.
A heap overflow is a dangerous memory corruption flaw. The heap is an area of memory dynamically allocated at runtime. A stack overflow affects local function variables in structured memory frames, but a heap overflow occurs when incoming data exceeds the boundaries of an allocated heap buffer.
Stack and Heap
The data spills over into adjacent memory blocks. This dynamic spill corrupts critical application pointers, variables, and execution instructions.
The vulnerability lived inside the image overlay processing logic. HEIF files rely on the ISO base media file format to create a complex graph of derived images, auxiliary items, and image grids.
int dx = get_x_offset();
int in_w = overlay_width;
int out_w = base_image_width;
// Bounds check vulnerable to integer overflow
if (dx + in_w > out_w) {
in_w = out_w - dx;
}
When the parser calculated overlay offsets, it failed to handle integer boundaries correctly.
This looks like a harmless bounds check on the surface, but the offset value is entirely user controlled. An attacker can set the horizontal offset dx to a massive number near the integer limit.
When the code evaluates dx + in_w, the calculation overflows and wraps around the maximum integer limit. The resulting sum becomes a negative or tiny value, which easily bypasses the boundary check.
The parser trusts this failed check and executes a memory copy operation. Data from the malicious HEIF upload writes past the designated buffer boundaries and overwrites adjacent memory on the heap. By carefully structuring this overflow, the researchers achieved remote code execution on the Discourse server.
The Pivot to the Monorepo
Getting remote code execution on an external community forum is a bad security incident. But it should never grant access to a company’s crown jewels.
That is where the second vulnerability entered the picture. The team identified a severe flaw in the OpenAI Single Sign-On configuration connecting the forum to their primary infrastructure.
With root level execution on the forum server, the researchers intercepted live authentication flows. They harvested valid session tokens from active OpenAI employees who used the forum to communicate with users.
Because OpenAI linked these employee credentials across multiple tools, compromising those forum sessions gave the researchers direct access to internal ChatGPT and Codex accounts. These employee accounts held active integrations with Gmail, Google Drive, Outlook, Slack, and GitHub.
To prove the severity of the access without exfiltrating proprietary algorithms, the researchers used an employee account linked to the OpenAI GitHub organization. They instructed Codex to generate a harmless pull request, recorded as PR #1186742, inside the private openai/openai monorepo.
Prompt to an employee’s Codex account to open a PR for us in OpenAI’s internal monorepo. Image from Hacktron
It is wild how quickly they moved from account access to a pull request in the monorepo.
The Insulting Bounty
The researchers acted ethically throughout the entire process.
They reported the Discourse vulnerability on a Saturday. Discourse acknowledged it on Sunday, and a fix went live on Monday. OpenAI patched the Single Sign-On vulnerability within 14 hours of notification.
OpenAI awarded the team a bounty of only $6,500.
We immediately reported the initial vulnerability to OpenAI and Discourse and worked with them to coordinate the patch. We appreciate their attention to detail and fast resolution of this issue. OpenAI also paid us a $6,500 bounty.
Their reasoning was that the initial remote code execution bug resided on a third-party Discourse server, which fell outside their core bounty scope.
They only paid out for the Single Sign On escalation.
It wasn’t just me who got pissed off at how small the bounty was. The security community was stunned.
User statements about the $6,500 bug bounty from OpenAI
Yeah.. I know. It’s crazy. Companies seem not to understand that by making moves like this, they are actually promoting this kind of behavior. A complete exploit chain offering write access to OpenAI’s internal monorepo would easily command hundreds of thousands of dollars on the private market or from a foreign broker.
Paying pocket change to researchers who responsibly hand over a potential exploit is astonishingly short sighted.
The researchers used Claude Opus 4.8 to identify the underlying libheif flaw and write a partial exploit. Within hours of Anthropic launching Opus 5, the team fed the context to the new model. Opus 5 adapted the exploit to Discourse and generated working code execution on their test environment. Security research that used to demand weeks of manual reverse engineering was executed in days by AI agents.
This exposes the dangerous reality of shipping unvetted code into production. We all know why LLMs are not widely used in financial and legal institutions yet because of their tendency to hallucinate.
Yet inside tech organizations, automated vibe coding without proper human verification is becoming standard practice. Boris Cherny from Anthropic previously stated that a substantial portion of Claude’s own codebase is generated by AI.
Here’s the basic lesson here: When companies prioritize velocity over verification, basic security oversights slip through.
And for us, developers, when we deploy vibe-coded apps and attackers use smarter AI agents to find the flaws, manual defense strategies collapse.
What’s to take from all this?
OpenAI actually got incredibly lucky here. It has only been days since Astra was released, and Sam agreed with the AI slowdown call from Dario.
If a malicious group had found this vulnerability first, they would not have submitted a bug report for a small bounty. They would have quietly planted backdoors in the monorepo or stolen algorithmic secrets.
OpenAI avoided a catastrophic breach simply because the hackers chose to act ethically.
Will they be ramping up AI innovation to avoid security vulnerabilities like this? For sure, but ramping up AI capabilities to patch vulnerabilities faster is a double edged sword.
Every model upgrade that helps an internal security engineer audit a codebase also equips external attackers with a faster and cheaper tool to crack legacy dependencies.
The blast radius extends well beyond OpenAI. Following their successful proof of concept, the researchers checked other services using the same vulnerable libheif parser. They found that the bug left systems across Slack, GitHub Enterprise, and Meta exposed to the exact same attack vector.
When major tech giants rely on identical unmaintained libraries, a single flaw in a media decoder puts the broader software ecosystem at risk.
Should we be all worried? Definitely. Relying on perimeter defenses is no longer viable. Tech labs need to isolate authentication tokens, strictly compartmentalize internal monorepos, and stop granting expansive permissions to employee developer accounts.
What do you think about this whole situation? Are we moving too fast with AI? Let me know your thoughts in the comments.
