On a Friday evening in July 2026 a small team of security researchers was stuck. They had found a serious bug in an image library, but their exploit only worked with a key memory protection switched off. The AI model helping them could not make it reliable. Then a new model was released, and within hours everything changed. By Saturday afternoon they had a harmless pull request sitting inside OpenAI’s internal code repository. So did Claude hack OpenAI? The honest answer is more interesting than the headline.
Three people and a stalled exploit
Harsh Jaiswal, Mohan Pedhapati and Rahul Maini work at Hacktron AI, a small security firm. For a few months they had been studying frontier AI companies, looking for weaknesses. Their attention settled on OpenAI’s public community forum, the place where developers and users trade questions and fixes. It runs on Discourse, a popular open source forum platform.
They started on Thursday. By Friday they had something that nearly worked. An exploit could run code on a Discourse server, but only when ASLR was turned off. That protection randomises where programs sit in memory, and real servers run with it on. Several attempts to get around it went nowhere.
Then, that same evening, Anthropic released a new model.
The libheif vulnerability nobody flagged
To see how they got there, go back to Thursday. The team began by reading how Discourse handles uploaded images. According to Hacktron’s own write up, the platform normally checks images with a tool called FastImage. FastImage did not support HEIF, the format modern iPhones use for photos. So Discourse handed those files to ImageMagick for conversion, and ImageMagick passed them to libheif. An uploaded file went straight into a parser written in C.
The researchers found a heap buffer overflow in libheif that gave out of bounds reads and writes during decoding. The bug had a quiet history. Upstream had changed the vulnerable code a year earlier, but that commit was never labelled a security fix and never received a CVE. Hacktron believes that is why the fix did not reach Debian. Discourse’s Docker image was built on Debian 12, which shipped libheif 1.19.7. Debian 13 still carried the vulnerable 1.19.8 until a security update on August 8.
A fix existed. Nobody had marked it as urgent.
The night a new model landed
On Friday the team had used Claude Opus 4.8 to build the exploit that only worked with ASLR off. Several more sessions failed to make it hold up with the protection on. That evening Anthropic released Claude Opus 5, and the researchers gave it the same problem.
Within three hours it produced a working exploit for a local Mac. They asked it to port the work to the setup Discourse actually uses, x86-64 with the jemalloc memory allocator. By 6:00 a.m. on Saturday they had confirmed code execution through an image upload on their own machine.
Next they put the model in an autonomous loop against their own Discourse Cloud instance and checked back at 10:00 UTC. The agent had achieved code execution. The team used the script it had written against OpenAI’s forum, and it worked there too.
The second door
A compromised forum is still only a forum. What made this serious was a separate flaw. The forum offers “Sign in with OpenAI” through auth.openai.com, and Hacktron suspected that identity flow could carry an attacker further. With code execution in hand, the team confirmed that active forum members could have their ChatGPT and Codex accounts taken over with no interaction.
Hacktron is firm that this was an OpenAI problem and not a Discourse one. Any first or third party service using the same sign on could have produced the same result. SecurityWeek reported that the forum’s sign in tokens carried excessive permissions, including full API access to the linked ChatGPT and Codex accounts.
One pull request, then silence
Some of the accounts belonged to OpenAI employees. One of them had Codex connected to OpenAI’s GitHub organisation. Between 13:30 and 15:30 UTC on Saturday the team used it, but not to browse code. They asked that employee’s Codex to open a pull request, number 1186742, in the internal monorepo called openai/openai. Then they stopped testing.
A pull request proves write access exists without requiring anyone to read a thing. Hacktron says it avoided learning anything sensitive. OpenAI’s account differs a little. Quartz reported that OpenAI told the Wall Street Journal its review found limited reads of private repository metadata and code. Both versions agree on the part that matters. A path from a public forum to an internal repository existed.
So who did the hacking?
Headlines said Claude hacked OpenAI. The people involved tell it differently. Pedhapati has described the team as three guys with Claude and Codex subscriptions. The write up is just as plain about the limits. The work was not fully autonomous, and skilled human guidance stayed important. The researchers chose the target, formed the hunch about the sign in path and decided where to stop. Only a few hours of human time went into the OpenAI hack.
What the model changed was the middle of the story. The earlier model stalled on ASLR across several sessions. Opus 5 solved the same problem within hours of release. That is a real shift in how quickly a known bug can become a working exploit.
It also works the other way. Code written by AI can look correct while quietly repeating insecure patterns. Our piece on quality engineering in the age of AI explains why a pull request that passes CI is no longer enough evidence that it is safe to merge.
What happened afterwards
The team filed its report through Bugcrowd on July 25, and OpenAI confirmed a fix about 14 hours later. An OpenAI spokesperson said the company narrowed permissions on community sign in tokens and revoked the affected tokens and sessions. As far as VentureBeat could verify, OpenAI has not published a detailed account of its own.
Discourse was reported separately through HackerOne. It replied on Sunday, had a fix by Monday and published advisory GHSA-vhm9-85gw-x335 on July 28, along with sandboxing around ImageMagick.
OpenAI paid a $6,500 bounty, resolved on September 1. The award covers only the OpenAI side of the finding, since testing against the Discourse hosted forum was outside the programme. Hacktron published its full account on September 13.
A bigger story than one forum
The OpenAI forum was one stop in a longer project called HEIF Heist. Over two months the same three researchers followed the vulnerable libheif dependency through Slack, Meta, GitHub Enterprise, Ruby on Rails and JavaScript frameworks such as Next.js, Astro and Gatsby.
Hacktron says the whole campaign cost under $3,000 in tokens. Adapting the exploit to each new company usually took a day or two. It also says Shopify was the only company it knows of that noticed anything, even after thousands of images were sent.
If your app takes image uploads
Anything that accepts HEIC, HEIF or AVIF files deserves a check. Start with the libraries. Update libheif and libde265 through your distribution or an upstream release. Version 1.23.4 was the latest security release I could find, though you should look for anything newer. Distributions often backport fixes under older version numbers, so read the package advisory as well as the version.
Then limit what ImageMagick will accept. Its security policy lets you restrict formats and resource use, and if you have no need for HEIF or AVIF decoding you can switch it off. Finally, run image processing in a sandbox that is hardened and short lived. If you self host Discourse, run git pull and then ./launcher rebuild app from /var/discourse, because a web interface update alone may not replace the vulnerable image.
What it means for teams using AI tools
The image bug drew the attention, but the identity design turned it into an incident. A community forum should not share trust with products that connect to GitHub, Slack and email, yet Hacktron noted that a compromised account could theoretically reach all three.
Connected AI tools make this sharper. A coding agent inherits whatever the account behind it can touch. Our guide to AI agents in production recommends least privilege by default, with each agent holding only the tools and data its task needs and every action logged.
Hacktron makes a wider argument too. Software was long protected by complexity, because even a public bug took rare skill and weeks of work to exploit. AI is compressing that effort, and defenders will have to plan for how quickly a known flaw can become a working attack.
The takeaway
Nothing in this chain was exotic. An image parser missed a backport, an identity setup trusted the wrong place and a developer tool had reach nobody had mapped. Each one sat unnoticed on its own. A new model gave three researchers the speed to line them up in a weekend.
