OpenAI Hacked in 72 Hours by Three People and Claude Opus 5
OpenAI hacked, in under 72 hours, by three researchers and an AI model that had shipped the night before. On July 25, 2026, the team at Hacktron AI chained a heap overflow in an open source image decoder into remote code execution on OpenAI's community forum, escalated through a flaw in OpenAI's own single sign-on, and used a compromised employee's Codex account to open a pull request inside OpenAI's private monorepo.
Key takeaways
- Three researchers at Hacktron AI (Harsh Jaiswal, Mohan Pedhapati and Rahul Maini) went from first look at Discourse's image pipeline on July 23 to a pull request in OpenAI's internal monorepo on July 25. They published the write-up in September 2026.
- The chain had nine links, and only one of them belonged to OpenAI. It started in libheif, a native image decoder almost nobody installs deliberately, and ended in
openai/openai. - Claude Opus 4.8 could not land the exploit. It kept failing against ASLR across multiple sessions. Opus 5 was released on the evening of July 24, and a fresh session produced a working ARM64 exploit within three hours.
- The "under $3,000 in tokens" figure being quoted everywhere is real, but it covers the entire two-month HEIF Heist project against Slack, Zoom, Meta and others. It is not the price of this one hack, which Hacktron describes as a few agent-days and a few hours of human time.
- OpenAI confirmed a fix roughly 14 hours after the report and paid a $6,500 bounty, while noting that testing against the Discourse-hosted forum was outside its bug bounty scope and that the award covers the OpenAI-side finding.
- The detection result is the part that should worry defenders: across the whole research project, Hacktron says only Shopify noticed, even after thousands of malformed images and repeatedly crashing image processors.
- If your product accepts a user-uploaded HEIC, HEIF or AVIF file and runs it through ImageMagick, libvips or sharp, you are on the same attack surface. Upgrade to libheif 1.23.2 or later.
Published September 18, 2026. Every timestamp, version number, dollar figure and quotation below comes from Hacktron AI's own disclosure, Hacking OpenAI, and the companion research site HEIF Heist. Where the viral coverage on X and in the financial press differs from the primary source, this article follows the primary source and says so.
What actually happened, link by link
The framing in most of the coverage is "AI hacked OpenAI." That is not what happened. Three experienced vulnerability researchers used an AI model to do the one part of offensive security that has always been the bottleneck: turning a memory corruption bug into a reliable exploit. Everything else was human judgement about where to point it.
Read that table as a supply chain, because that is what it is. OpenAI did not choose libheif. Discourse did not choose libheif. Debian shipped it, ImageMagick linked it, and a support forum inherited it. The only genuinely OpenAI-owned defect in the whole chain is step 6, the SSO flaw, and Hacktron has not published its technical details.
Why Opus 5 is the part of this story that matters
Strip out the brand names and this is a story about a capability threshold being crossed on a specific evening.
Hacktron had the bug. They had a crash. What they did not have was a working exploit, because modern exploitation means defeating ASLR and wrangling jemalloc's heap layout, and that is where Opus 4.8 stalled across multiple sessions. Anthropic released Opus 5 on the evening of July 24. Hacktron opened a new session, and it produced a working ARM64 exploit for a local Mac in about three hours, then ported it to x86-64 with the right allocator configuration.
By 06:00 UTC on July 25 they had confirmed local code execution through an image upload, and they put the model into an autonomous goal loop against their own Discourse instance before ever touching OpenAI's. That last detail is easy to skim past and it is the actual news: the expensive, specialist, week-consuming stage of an exploit chain became an overnight agent run. We wrote up how the current frontier models compare on exactly this kind of long-horizon reasoning in our Opus 5 versus Fable 5 versus GPT-5.6 Sol breakdown, and the same pattern of putting an agent in a loop rather than a chat window is what we describe in agentic coding as a process.
The $3,000 figure is being misquoted, and the truth is worse
Half the viral posts say this hack cost less than $3,000 in tokens. The primary source says something different. Hacktron's sentence is that the whole HEIF Heist research project, "going after Slack, Zoom, Meta, and more," took two months, cost less than $3,000 in tokens in total, and was done by three researchers.
So the correct claim is not that breaking into OpenAI cost $3,000. It is that breaking into OpenAI, Slack, Meta, GitHub Enterprise and a list of others cost less than $3,000 in tokens between them. The misquote is flattering to OpenAI by comparison.
Put it next to what this class of work used to cost. A reliable heap-overflow exploit against a hardened target was a senior specialist and several weeks, which is why exploit brokers price them in six figures. Hacktron puts per-target exploit development at one to three days with an agentic approach. That is the entire economic story, and the dollar amount is almost beside the point.
Nobody saw it coming, and almost nobody saw it happen
The most damning line in the disclosure has nothing to do with OpenAI. Hacktron writes that they are not aware of any company that detected the activity except Shopify, even after thousands of images were sent and their image processors repeatedly crashed.
Think about what that means operationally. A decoder crashing is not a subtle signal. It is a process dying, over and over, on attacker-controlled input. Most teams route that into a metric nobody reads, or swallow it in a retry, because a broken upload looks like a user problem rather than an attack. The monitoring was pointed at uptime, and the attack did not affect uptime.
The other structural failure is the missing CVE. The vulnerable libheif code had already been changed upstream, but the commit was not documented as a security fix and got no CVE identifier. Every scanner that works by matching installed versions against CVE feeds reported the host as clean, correctly and uselessly. If your entire vulnerability management story is "we run a scanner," this is the shape of the thing it cannot see.
What this means if you are not OpenAI
It is tempting to file this under "big lab gets embarrassed." The uncomfortable read is that OpenAI came out of it comparatively well: the bug that mattered was fixed in roughly 14 hours, the researchers were paid, and nobody has suggested customer data moved. Most companies would not have found it in 14 days.
The transferable lesson is that the attack did not target OpenAI's models, its training data or any of the things AI security conversations usually obsess over. It targeted a support forum. The path ran through a dependency nobody chose, and the escalation ran through identity plumbing. That is a completely ordinary application security failure, executed at a speed that is not ordinary at all.
The uncomfortable scaling question
The reaction that spread fastest on X was the obvious one: if three people can do this in 72 hours, what does a well-funded state actor do with the same tooling and no disclosure ethics? It is a fair question, and it does not have a comforting answer.
The useful version of the question is narrower and answerable. Attackers just got a large, cheap multiplier on the slowest part of their work. Defenders can have the same multiplier, and mostly are not using it. Anthropic shipped a security scanner into the terminal for precisely this reason, which we covered in our walkthrough of the Claude Code security plugin, and the same models that built this exploit chain will read your dependency tree and your upload handler if you ask them to. Teams that want that review to run entirely inside their own perimeter can now do it on hardware they control, which is the calculation we ran in what a self-hosted LLM actually costs.
The honest summary of September 2026: offensive AI is cheap, fast and demonstrated. Defensive AI is available, affordable and mostly unadopted. That gap is the risk, not the models.
What to do this week
Three things, in order, none of which require a security program you do not already have.
- Find every place your product decodes a user-supplied image, including the ones inside libraries you did not write. Check the native libheif and libde265 versions in your production images, not the versions in your lockfile.
- Turn decoder crashes into an alert with a name and an owner. If a process dies on user input more than a handful of times an hour, someone should be woken up.
- Audit what a single compromised employee session can reach through connected AI agents. Step 9 of this chain was an agent with write access to a monorepo, doing exactly what it was told.
Find this in your own stack before someone else does
The chain above is nine ordinary engineering decisions that only look reckless in hindsight: an inherited native dependency, a scanner with nothing to match on, an upload handler with ambient credentials, and an integration token with more reach than anyone intended. Every one of those is findable in a week of focused work. None of them are findable by a tool you bought and never tuned.
Valletta Software Development builds and hardens the systems this attack ran through: image and file ingestion pipelines, authentication and SSO integration, agent and API permissions, and the CI checks that keep a native dependency from ageing quietly in a base image. We will inventory your real attack surface, tell you which parts of it we would attack first, and fix what we find. Tell us what your product accepts from users and we will scope it.
FAQ
Was OpenAI actually hacked?
Yes. On July 25, 2026, researchers from Hacktron AI obtained remote code execution on community.openai.com, escalated through a flaw in OpenAI's single sign-on to take over employee ChatGPT and Codex accounts, and used that access to open pull request #1186742 in OpenAI's internal monorepo. It was authorised security research, reported through Bugcrowd, and OpenAI paid a bounty.
Did Claude hack OpenAI by itself?
No. Three human researchers chose the target, found the attack surface and made every strategic decision. Claude Opus 5 wrote the memory-corruption exploit, which is the step that traditionally takes a specialist weeks, and was then run in an autonomous loop against Hacktron's own test instance. The model was the power tool, not the operator.
How much did the hack cost?
Hacktron's "less than $3,000 in tokens" figure covers the full two-month HEIF Heist project across many targets, not this single intrusion. For the OpenAI chain specifically they describe a few days of agent time and only a few hours of human time. The meaningful number is the time, not the money.
What was the vulnerability?
A heap buffer overflow in libheif 1.19.7 on Debian 12, triggered while decoding a malicious HEIC image and giving out-of-bounds read and write primitives. The upstream code had been changed a year earlier, but the commit was not marked as a security fix and never received a CVE, so it was not backported and scanners did not flag it.
Is my application affected?
Possibly, if it accepts user-uploaded HEIC, HEIF or AVIF files and processes them with ImageMagick, libvips or sharp, all of which sit on top of libheif. The fix is to upgrade to libheif 1.23.2 or later along with the current libde265, and to disable untrusted HEIF and AVIF decoding where you do not need it or isolate it in a hardened, ephemeral sandbox.
What did OpenAI say?
OpenAI confirmed the fix roughly 14 hours after the report and paid a $6,500 bounty. It also clarified the scope of that award, stating that testing against the Discourse-hosted community.openai.com was explicitly excluded from its bug bounty program and that the payment recognises the OpenAI-side finding rather than the actions against Discourse.
Why did Opus 4.8 fail where Opus 5 succeeded?
Hacktron reports that earlier sessions with Opus 4.8 struggled in ASLR-enabled environments, which is the standard defence that makes an exploit unreliable unless the attacker can leak or predict memory layout. Opus 5, released on the evening of July 24, 2026, produced a working ARM64 exploit in a fresh session within about three hours. Neither company has published a technical explanation for the jump.