Researchers Just Used Claude to Hack OpenAI. The Image That Opened the Door Is the Real Story.

Here's the version of this story that got the headlines: researchers used Anthropic's Claude to break into OpenAI, the company that built ChatGPT and half the tools we lean on. That's the easy narrative, and it mostly writes itself. But the deeper story isn't the names on either side of the attack. It's the unremarkable thing that let it happen, and what it says about who's now capable of this kind of work.

The researchers were three people at a startup called Hacktron AI. And as they themselves point out, the entry point was not an exotic zero-day in a fortress. It was an image upload on OpenAI's community forum.

The ordinary door

OpenAI runs its help forum, community.openai.com, on Discourse, the open-source discussion platform. When someone posts a HEIC or HEIF image - the default photo format on iPhones - Discourse runs it through a conversion pipeline. FastImage, its usual image checker, can't handle Apple's format, so it hands the file to ImageMagick, a decades-old utility. ImageMagick in turn calls a decoder library called libheif to do the actual parsing.

That's three separate pieces of free, widely deployed software, chained together invisibly under a web form. And at the bottom of that chain sat a heap-buffer-overflow in libheif. Feed it a specially crafted image and it miscalculated where one image sat on top of another, and that miscalculation was enough to run arbitrary code on the server.

The aggravating part for the security community: the flaw had been fixed upstream about a year earlier. But the fix was never flagged as a vulnerability, so it never received a CVE number, the industry's standard way to route a bug into patching cycles. Discourse's Docker image was based on Debian 12, which shipped the vulnerable libheif 1.19.7. Even Debian 13 shipped the vulnerable 1.19.8 at the time. Nobody connected the dots, so the patch sat in an upstream repo while OpenAI's forum ran the broken version.

The model that crossed the line

Here's where the AI angle gets specific, because it wasn't a case of Claude doing everything at once. The researchers started with a special security-focused build of Claude Opus 4.8. It found the vulnerable package. It even produced a working exploit - but only with ASLR, the memory-randomization defense that turns most heap overflows into paperweights, switched off. Across multiple sessions, Opus 4.8 could not make the exploit reliable against Discourse's default, ASLR-enabled configuration.

That evening, Anthropic released Claude Opus 5.

"We started a new session," Hacktron wrote, "which first produced a working ARM64 exploit for a local Mac within 3 hours." Then they asked it to port the exploit to the x86-64 and jemalloc environment Discourse actually runs. By six in the morning on July 25, the team confirmed local remote code execution through an image upload. They placed Claude in an autonomous loop against their own test instance, and the agent achieved RCE on Discourse Cloud and read /etc/hosts to prove it. Then the generated exploit went live against OpenAI's forum.

Put the timing in perspective. Opus 4.8, a state-of-the-art model, struggled across several sessions and couldn't crack ASLR. Within hours of Opus 5's release, the same team handed it the same problem and it succeeded. "Opus 4.8 struggled across several sessions to produce a working exploit," they wrote. "Within hours of Opus 5's release, we gave it the same problem and it succeeded." That single overnight jump is the actual news here.

The second flaw and the blast radius

Forum-level remote code execution alone wouldn't have gotten the researchers near OpenAI's source code. The second vulnerability was OpenAI's own. The community forum accepted "Sign in with OpenAI" through auth.openai.com, and OpenAI's sign-in tokens for that forum carried excessive permissions. As SecurityWeek reported, OpenAI itself told them the tokens "grants full API access to associated ChatGPT and Codex accounts."

That's the piece that turned a compromise of a third-party forum into a compromise of OpenAI's own accounts. Discourse was merely the foothold; the identity flaw was the boundary crossing. "The vulnerability to escalate is not Discourse-specific," Hacktron wrote. "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."

From that position, the researchers did something careful and quietly chilling. They identified an OpenAI employee whose Codex was connected to OpenAI's GitHub organization, took over that account, and used it to open a harmless pull request - number 1186742 - in OpenAI's internal openai/openai monorepo. A pull request is a routine thing for a developer to create. It's also exactly the kind of action an authorized insider makes. No source code was read or exfiltrated, but the point was made: an attacker with this access could instruct an employee's AI agent to touch the company's crown jewels, and the platform would simply comply.

The whole chain, from initial discovery to access inside OpenAI's repository environment, took under 72 hours. OpenAI confirmed the fix about 14 hours after the report. Discourse had a fix ready within two days and published advisory GHSA-vhm9-85gw-x335, scoring the image-processing flaw a CVSS 8.8. OpenAI paid Hacktron a $6,500 bounty for the OpenAI-side finding, noting in a comment that testing against the Discourse-hosted forum itself sat outside the bug bounty's scope.

What the other side says

OpenAI disputes only the edges, and it's worth being precise about that. It confirmed the account-takeover path and the fix. "We narrowed the permissions on Community sign-in tokens and revoked affected tokens and sessions," the company told SecurityWeek. Its own review found "limited reads of private-repository metadata and commits" followed by the researcher-submitted pull request to a README file. On the Slack question, OpenAI said Hacktron did not verify actual access to employee Slack messages, though the researchers had flagged Slack as theoretically reachable through connected accounts. So the core account takeover is confirmed by the victim; the broadest reach claims are not independently verified.

What OpenAI can't dispute is the pattern. The same research team, in the same campaign, says it expanded this work across Slack, Meta, GitHub Enterprise, Zoom, and other targets - the project cost less than $3,000 in tokens total and took two months. They say no company detected their activity except Shopify, even after thousands of image uploads and repeated crashes in image processors. Adapting the exploit to a new company usually took one to two days.

"The amount of work a small team could perform increased dramatically," they wrote. That's the sentence to sit with.

The strategic tension

For years, memory-corruption exploitation carried an informal tax. The source code might be public and the bug even known, but turning it into a reliable exploit demanded rare expertise, deep knowledge of a specific environment, and real time. That tax was never a real security boundary - zero-days were always affordable to well-resourced nation states - but in practice it protected ordinary companies. Most attackers simply couldn't afford the expertise.

AI is dismantling that tax. As Hacktron put it: "Work that once required a well-resourced team and months of effort can now be compressed into days." The scarce expertise is being converted into compute, and compute is cheap and available to everyone. Gray Swan CEO Matt Fredrikson told TechCrunch the blunt version: "For $200 a month, anyone can use these tools and hack into a company like OpenAI. If it can happen to them - and I don't think they've been slouching recently on cybersecurity hygiene - it could happen to anyone."

You don't even need to agree with the alarm to grant the mechanism. The exploit in question crossed the reliability line on the night a new model shipped - not because a human got smarter, but because a frontier model got cheaply better at a task that was previously a boutique skill.

Why this story is yours

Run your threat model backward through the attack chain and it stops being an OpenAI story. An image upload on a community forum. A decoder dependency that sat unpatched because a fix landed upstream without a CVE. A federated identity token carrying more permission than it needed. An AI account connected to a code repository. Every organization that runs a web form accepting user images, or a single sign-on across tools, or an AI agent wired into its systems, is running at least one piece of this chain. The specific target is almost incidental - HEIF Heist, as the researchers dubbed it, is a class of attack on an entire ecosystem of image-processing software, not a single company.

The practical response mirrors the defense-in-depth Hacktron recommends and Discourse adopted: keep image-processing dependencies aggressively patched and sandboxed, isolate untrusted file decoding, review what your identity tokens can actually do, and treat AI agent credentials with the same care as privileged human accounts. The window between a fix sitting in an upstream repo and it reaching your production container is where attacks like this live, and AI has made that window dramatically more profitable to test.

The supply-chain discipline behind closing that window - tracking third-party dependencies, auditing identity permissions, hardening the image-processing and agent layers before someone else does it for you - is the kind of work that rarely shows up in a feature roadmap. At DMC, we help hardware and software companies map exactly these attack surfaces and tighten them before an exploit makes the economics real for them. If you want to stress test whether your image pipeline, SSO, or AI agent connections could be the next ordinary door, let's talk.