Claude Opus 5 Helped Hacktron Take Over OpenAI Staff Accounts

Claude Opus 5 Helped Hacktron Take Over OpenAI Staff Accounts

Three researchers at the security firm Hacktron chained a memory-corruption bug in the libheif image library with a weakness in OpenAI's own login system, took over the ChatGPT and Codex accounts of several OpenAI employees, and reached an internal OpenAI repository - all in under 72 hours from the first look.

It was responsible security research, not an attack: the team reported everything to OpenAI, proved the access by opening a harmless pull request in OpenAI's internal monorepo, and stopped. OpenAI confirmed a fix about 14 hours after the report and paid a $6,500 bounty on September 1.

Two things make this story worth reading. One is how much of the exploit engineering was done by Anthropic's Claude Opus 5. The other - far more important for most teams - is that a bug in a public help forum became access to internal repositories. That is not a forum problem. It is an identity-design problem.

The kill chain, end to end

Hacktron's write-up breaks the full chain into nine links:

1. libheif         -> image decoder (heap buffer overflow in HEIC decoding)
2. Debian 12       -> missing security backport, ships vulnerable libheif
3. ImageMagick     -> calls libheif for HEIC/HEIF conversion
4. Discourse       -> passes image uploads to ImageMagick
5. OpenAI forum    -> community.openai.com runs Discourse
6. OpenAI SSO      -> "Sign in with OpenAI" on the forum
7. ChatGPT / Codex -> accounts of forum members who worked at OpenAI
8. GitHub          -> an employee's Codex was connected to OpenAI's GitHub org
9. Internal repos  -> openai/openai monorepo

The entry point is deceptively boring. OpenAI's forum runs on Discourse, and Discourse normally uses FastImage to inspect uploads - but FastImage has no HEIF support, so HEIC/HEIF files were handed to ImageMagick's magick command instead. ImageMagick sits on top of libheif, and that exposed the decoder directly to attacker-controlled files.

A crafted HEIC image triggered a heap buffer overflow leading to out-of-bounds read/write primitives during decoding. That turned into remote code execution on the forum server.

Why a forum bug reaches staff accounts

The escalation is the interesting part, and it is not a Discourse bug. Open the forum with the same "Sign in with OpenAI" single sign-on that staff use everywhere else. Once the researchers controlled the forum server, the shared login let them take over the ChatGPT and Codex accounts of forum members who worked at OpenAI - and the victims did not have to do anything.

Hacktron frames it exactly right: this is an OpenAI identity problem, not a forum problem. Any first- or third-party service using the same SSO could have granted the same access. Discourse was merely one way of proving it. And because staff connect other services to ChatGPT and Codex, the same access could in theory have extended to GitHub, Slack, and email.

To prove impact without touching anything sensitive, the team used one employee's Codex to open a single pull request (PR #1186742) in OpenAI's internal openai/openai monorepo. They did not read source code, merge or ship anything, or touch customer data. Then they stopped.

The AI did the hard part

The exploit path started on July 23, when the team reviewed Discourse's image pipeline and had an Opus 4.8 session inspect the installed libheif package. The model spotted that security fixes were missing from the version Debian ships, and on July 24 the researchers had a working code-execution exploit with ASLR disabled - but several more sessions failed to make it reliable against Discourse's real configuration with ASLR enabled.

That evening, Anthropic released Claude Opus 5. A fresh Opus 5 session produced a working ARM64 exploit for a local Mac within three hours, then ported it to the x86-64 + jemalloc setup Discourse uses. By 6:00 a.m. on July 25, local RCE through an image upload was confirmed.

The model's own safeguards got in the way of the next step: Opus 5 refused to write exploits for remote instances. So the researchers pointed it at their own Discourse Cloud instance, proxied through rce.ee/ctf-forum to make it look like a capture-the-flag target, and let it run in an automated /goal loop. By 10:00 a.m. the agent had RCE on that instance, demonstrated by reading /etc/hosts. A human then used the generated exploit script against OpenAI's actual forum.

Hacktron is careful to note this was not hands-off automated hacking - skilled human direction mattered at each step. But the time and skill it used to take to weaponize that memory corruption collapsed from weeks to hours.

The two real root causes

The dependency gap. The dangerous code had been changed upstream the previous year, but the commit was not documented as a security fix and received no CVE - likely why Debian 12 and 13 had not back-ported it in time. Discourse's image (based on Debian 12) shipped libheif 1.19.7; Debian 13 shipped 1.19.8. The fix had already landed upstream in libheif 1.22.0 back in May 2026 - months before the test. Debian only published its own security update (DSA-6417-1) on August 8, 2026.

There is a subtlety in how the bug is described. Discourse's advisory rates the result as remote code execution, 8.8 out of 10, tracked as CVE-2026-32882. But in libheif's own advisory and the national databases, CVE-2026-32882 is an out-of-bounds read that can crash the software or leak nearby memory - not a direct code-execution bug. The researchers combined libheif's memory bugs, with the AI's help, to defeat ASLR and turn the crash into working code execution.

The SSO blast radius. This is the lesson that generalizes. A lower-trust public service sharing your single sign-on with internal tools means a break-in on that service is a break-in one hop from everything. OpenAI's fix was on the login side; the award "recognizes the OpenAI-side finding, not the actions against Discourse," OpenAI said, since testing the forum itself was outside its bug bounty program. There is no sign the flaw was used in the real world - as of mid-September 2026 it is not on the U.S. government's known-exploited list, though that list is not proof either way.

What to do if any of this is in your stack

If you self-host Discourse, this part hits you directly. Hacktron notes a web-interface update may not replace the old library - rebuild the container image:

cd /var/discourse
git pull
./launcher rebuild app

Discourse-hosted sites were already patched; the fixed self-hosted releases are 2026.7.0, 2026.6.1, 2026.5.2, and 2026.1.6. Beyond that:

• Update libheif to the latest security release - 1.23.4 as of early September 2026 - or to your distribution's patched build. If you accept HEIC/HEIF/AVIF uploads, an old build of this one library is your exposure.
• Where you don't need it, turn off decoding of untrusted HEIF/AVIF images, or run image processing inside a hardened, ephemeral sandbox. ImageMagick's security policy can restrict accepted formats.
• Limit which services your single sign-on trusts, and require a fresh identity check before sensitive actions instead of trusting an existing session. The trust boundary, not the prompt of the day, is what separates a public forum from an internal one.

The wider picture: HEIF Heist

This was one target in a broader project Hacktron calls HEIF Heist: over roughly two months, the same class of image-decoding flaws in software used by other large companies, at a total cost of under $3,000 in AI usage. It links the campaign to reported bugs in Slack, Meta's products, GitHub Enterprise, and web frameworks such as Next.js.

Those wider claims are backed unevenly. The Next.js flaw is confirmed in Vercel's own advisory, and libheif's maintainers confirmed a working code-execution exploit for the bug tied to Meta - but the broader claim of code execution across many applications has not been independently confirmed. Only one company, Shopify, appears to have noticed, even though its image processors crashed repeatedly under thousands of test uploads. Across the campaign the team used OpenAI's own GPT-5.6 Sol for targets where nothing was known in advance.

The lesson is not "AI is scary"

Capable models are sharply compressing the cost of offensive work - Anthropic itself reports that criminal and state-backed groups are already using Claude for real intrusions. Assume the same economics apply to you.

But the two things that made Hacktron's chain work are fixable today without touching AI at all: don't let a public, lower-trust service share an identity boundary with internal tools, and stop letting an untrusted image parser run with the privileges of the process that hosts it. Fix those two and the best exploit in the world has nowhere to chain to.

If you want more context on how AI agents are being pulled into real intrusions, our coverage of the Shai-Hulud worm hijacking an AI coding session documents the same trend from the supply-chain side, and the PaperCut attacks show how quickly AI-assisted tooling turned a known flaw into mass exploitation.

Sources

• Hacktron: Hacking OpenAI
• The Hacker News: Claude Opus 5 Helped Researchers Take Over OpenAI Staff Accounts via Chained Flaws
• Discourse: Discourse Security Advisory GHSA-vhm9-85gw-x335
• NIST NVD: CVE-2026-32882
• libheif (strukturag): libheif v1.23.4 security maintenance release
• Hacktron: HEIF Heist
• The Hacker News: Next.js Patches Critical AVIF and Image Handling Flaws
• The Hacker News: Claude Used to Automate Exploitation