Claude Opus 5 Helped Researchers Break Into OpenAI Staff Accounts Through a Chained Exploit
A three-person security team at Hacktron pulled off something that should worry every company running AI-assisted infrastructure: they used Anthropic’s Claude Opus 5 to stitch together two separate vulnerabilities and gain access to the ChatGPT and Codex accounts of multiple OpenAI employees — eventually reaching all the way into an internal OpenAI code repository.
The entry point wasn’t some exotic zero-day sitting inside OpenAI’s core systems. It was a bug in the software running OpenAI’s public help forum, which, through a shared login system, opened a path straight into employee accounts.
To be clear, this wasn’t a malicious attack. It was disclosed responsibly. The researchers reported everything to OpenAI, demonstrated the access with a harmless pull request to prove the point, and stopped there. According to the team, the entire chain — from first probing the forum to reaching internal systems — took less than 72 hours.
OpenAI moved fast once notified, rolling out a fix within roughly 14 hours of the report. On September 1, the company paid Hacktron a $6,500 bounty, though it clarified the payout covered the issue on OpenAI’s side of the chain — not the forum vulnerability itself, since testing third-party forum software fell outside the scope of its bug bounty program. OpenAI hasn’t gone into detail publicly about the login weakness that made the account takeovers possible; the fix and the payment are effectively its confirmation that the research was legitimate.
Hacktron, which positions itself as an AI-assisted security research outfit, was deliberate about drawing a hard line. When they accessed one employee’s Codex-linked GitHub connection, the only thing that happened was a single test pull request landing in the internal repo. No source code was read, nothing was merged, nothing shipped, and no customer data was touched.
What makes this genuinely alarming, though, is the scale of what could have happened. Because OpenAI staff link other tools — GitHub, Slack, email — to their ChatGPT and Codex accounts through the same sign-on, the researchers say that same access chain could theoretically have extended into all of those systems. They didn’t go there. But the door was open.
The Real Problem Wasn’t the Forum — It Was the Login System
Here’s the part worth sitting with: the vulnerability that let a forum bug reach into staff accounts wasn’t really a forum problem at all. It was an identity problem.
OpenAI’s help forum offers “Sign in with OpenAI” — the exact same single sign-on system staff use everywhere else internally. So once the researchers had control of the forum’s backend server, that shared login became a bridge straight into the ChatGPT and Codex accounts of any OpenAI employee who was a forum member. No phishing, no user interaction needed. The victims did nothing wrong.
Hacktron was blunt about where the fault lies: this is an identity architecture issue on OpenAI’s end, not a flaw in the forum software. Any service, first-party or third-party, plugged into that same sign-on could have handed over the same level of access.
How They Actually Broke In?
The technical root cause traces back to how the forum handles images. OpenAI’s forum runs on Discourse, an open-source forum platform, which hands off uploaded HEIC and HEIF image files to ImageMagick — which in turn relies on a library called libheif to actually decode them. Buried in libheif was a flaw that let a maliciously crafted image corrupt the forum server’s memory.
Discourse’s own security advisory classifies this as remote code execution and rates it 8.8 out of 10 in severity, tracked as CVE-2026-32882. Interestingly, the official vulnerability record itself is more conservative — libheif’s maintainers and national vulnerability databases describe it as an out-of-bounds read capable of crashing the software or leaking adjacent memory, not code execution on its own.
That distinction matters, because it’s exactly the gap the researchers exploited. Leaked memory is valuable because it helps defeat ASLR, a standard defense that randomizes where code sits in memory to make exploitation harder. The team says they combined multiple libheif memory bugs — with AI assistance — to convert what should have just been a crash into a working, full remote code execution exploit against the forum server.
The frustrating twist: this had already been fixed upstream in libheif version 1.22.0 back in May 2026. But the forum’s server image, built on Debian 12, was still running the outdated 1.19.7 version when the researchers tested it in July. The patch existed and was public — Debian’s packaged build simply hadn’t caught up yet.
If you’re running your own Discourse instance, this is a direct warning: rebuild on the latest server image to pull in the patched libheif, because updating through the web interface alone won’t necessarily swap out the underlying library. Discourse-hosted sites were already patched by the time this became public; for self-hosted deployments, the fixed releases are 2026.7.0, 2026.6.1, 2026.5.2, and 2026.1.6.
Where Claude Opus 5 Actually Made the Difference?
This is the part that’s generating the most attention — and rightly so. The researchers initially tried Claude Opus 4.8 for the exploit-building work. It struggled. Across multiple sessions, it couldn’t reliably produce a working exploit once ASLR was in play.
Then Anthropic shipped Claude Opus 5 on the evening of July 24. The team started a fresh session with the new model, and within hours, it had produced a working exploit — something the previous model had failed to do across repeated attempts.
Naturally, Opus 5 launched with guardrails specifically designed to stop it from writing exploit code against real-world targets. The researchers worked around that by framing their own test server as a capture-the-flag practice environment, then running the model in an automated loop against it. Worth noting: this wasn’t a case of AI running wild with zero oversight. The researchers say skilled human direction was still very much part of the process — Opus 5 accelerated the work, it didn’t replace the operator.
The Bigger Picture
This incident lines up with a pattern security researchers and AI labs have flagged repeatedly this year: capable models are compressing the time and expertise it used to take to do serious offensive security work — for better or worse. Anthropic itself has previously disclosed that criminal and state-linked groups are already using Claude models to carry out real intrusions, not just to ask questions about them.
OpenAI, it turns out, was just one target in a much larger effort Hacktron is calling “HEIF Heist.” Over roughly two months, the team says they found the same category of image-decoding vulnerabilities across software used by several major companies — and did it for under $3,000 in total AI usage costs. They’ve linked the campaign to previously reported bugs affecting Slack, Meta products, GitHub Enterprise, and frameworks like Next.js.
That said, not every claim in the wider campaign has been independently verified to the same degree. The Next.js flaw is confirmed through Vercel’s own advisory, and the libheif maintainers themselves confirmed a working code-execution exploit tied to the Meta-linked bug. But the broader claim of code execution across the full list of affected companies hasn’t been independently confirmed — a caveat that also applied when this outlet first covered the Next.js flaw back in August.
For targets where the team had no prior knowledge going in, they reportedly used a different model entirely — OpenAI’s own GPT-5.6 Sol. Out of everyone affected, only one company, Shopify, appears to have actually noticed the testing activity, despite its image processors crashing repeatedly under thousands of test uploads.
What You Should Actually Do About This?
The takeaway here extends well beyond Discourse or OpenAI specifically. If your service accepts user-uploaded images and processes HEIC, HEIF, or AVIF files through libheif, an outdated build could leave you exposed the same way.
And more broadly: if a lower-trust, public-facing service shares single sign-on credentials with your internal tools, a breach on that public service can cascade into a breach everywhere that login has reach.
Practical steps worth taking now:
- Update libheif to the latest security release (1.23.4 as of early September 2026), or make sure your distribution’s patched build is actually in use.
- If you don’t need to decode untrusted HEIF or AVIF files, turn that capability off — or isolate image processing inside a properly locked-down sandbox.
- Reassess what your single sign-on trusts. Sensitive actions should require a fresh identity check rather than relying on an existing session token.
As of now, there’s no evidence this particular OpenAI vulnerability was exploited maliciously in the wild — it isn’t on the U.S. government’s list of known-exploited vulnerabilities as of mid-September 2026, though absence from that list isn’t proof of safety either. And one question remains genuinely open: whether organizations that have already patched should still be checking for signs of earlier, undetected access. On that, there’s no clear answer yet.
