Claude Opus 5 Cracked OpenAI Staff Accounts in Under 72 Hours

Security researchers at Hacktron chained two vulnerabilities to take over ChatGPT and Codex accounts belonging to OpenAI employees, then walked into an internal OpenAI code repository. The whole thing took less than 72 hours. The AI model that made it possible was Anthropic's Claude Opus 5.

This was responsible disclosure research, not a malicious attack. The team reported everything to OpenAI, demonstrated internal access with a single harmless pull request, and stopped there. OpenAI pushed a fix within 14 hours of the report and paid Hacktron a $6,500 bug bounty on September 1. The company noted the bounty covered the OpenAI-side flaw, not anything done against Discourse, the open-source forum software where the attack chain began.

OpenAI has not publicly described the login vulnerability. The fix and the payment are the only official acknowledgements.

How a Help Forum Became a Door Into OpenAI

OpenAI's public help forum runs on Discourse and offers a "Sign in with OpenAI" option. That single sign-on is the same system OpenAI staff uses for other services, including ChatGPT and Codex. Once the researchers controlled the forum server, that shared authentication let them take over accounts belonging to OpenAI employees who also used the forum. No victim had to click anything.

Hacktron described this as an identity architecture problem on OpenAI's side: the forum was simply one service that trusted the same login system as everything else. Any other first- or third-party service wired to the same sign-on would have handed over the same access.

The entry point was an image parsing bug. Discourse passes uploaded HEIC and HEIF images through ImageMagick, which calls the libheif library. A flaw in libheif, tracked as CVE-2026-32882, allowed a specially crafted image to corrupt server memory. Discourse's advisory rates it 8.8 out of 10 and describes the outcome as remote code execution. The upstream libheif advisories are more conservative, classifying it as an out-of-bounds read that can crash the process or leak adjacent memory rather than execute code directly. The researchers say they combined multiple libheif memory bugs to turn that crash into working code execution, using the leaked memory to defeat ASLR in the process.

The patch for libheif arrived in version 1.22.0 back in May 2026. The fix was public. The CVE was public. But the forum server, running on Debian 12, still carried libheif 1.19.7 when the researchers looked in July. Debian had not yet included the patched version in its packaged build.

If you run a self-hosted Discourse instance, a web interface update alone will not pull in the fixed library. You need to rebuild on the latest image. Sites hosted directly by Discourse were already patched. Fixed self-hosted versions are 2026.7.0, 2026.6.1, 2026.5.2, and 2026.1.6.

Where Claude Opus 5 Came In

The researchers first tried Claude Opus 4.8 to build a working exploit. Over multiple sessions, it could not get past ASLR. Anthropic released Claude Opus 5 on the evening of July 24. In a fresh session, it produced a working exploit within hours.

Opus 5 ships with guardrails against writing exploits for real targets. The team sidestepped them by framing the work as a capture-the-flag exercise against their own test server, then running the model in an automated loop. They are clear that this was not autonomous hacking: skilled human oversight drove the process throughout.

The case is a fairly direct illustration of something both researchers and AI companies have been saying for a while now. Capable models are compressing the time and expertise that serious offensive security work used to demand. Anthropic has previously acknowledged that criminal and state-sponsored groups are already using Claude for live intrusions, not just reconnaissance.

How Far the Access Could Have Reached

The researchers were deliberate about what they did not do. Opening one employee's Codex link triggered a single pull request in an internal repository. No source code was read, nothing was merged, and customer data was not touched.

The theoretical blast radius was considerably larger. Staff accounts connected to ChatGPT and Codex also had integrations with services like GitHub, Slack, and email. The researchers say the same session tokens could in principle have extended to all of those. They chose not to find out.

The Wider Campaign

OpenAI was one target in a broader project Hacktron calls HEIF Heist. Over roughly two months, the team hunted for the same class of image-decoding flaws across large technology companies, spending under $3,000 on AI compute in total. The campaign reportedly turned up issues at Slack, Meta, GitHub Enterprise, and the Next.js web framework.

The supporting evidence varies. Vercel confirmed the Next.js flaw in its own advisory. libheif's maintainers confirmed a working code-execution exploit for the bug linked to Meta. The broader claims of code execution across multiple applications have not been independently verified, a point The Hacker News flagged when it covered the Next.js finding in August.

For targets where the team had no prior knowledge, they used OpenAI's GPT-5.6 Sol rather than Claude. Only Shopify appears to have flagged the activity, even though its image processing infrastructure crashed repeatedly under thousands of test uploads.

What to Do About It

The Discourse-specific advice is above. The broader takeaways are more widely applicable.

If your service accepts user-submitted images and processes HEIC, HEIF, or AVIF through libheif, an unpatched build is exposed. Update to libheif 1.23.4 or your distribution's current security release. Where you do not need HEIF or AVIF decoding from untrusted sources, turn it off, or run image processing inside a sandboxed environment.

On the identity side: if a public-facing, lower-trust service shares single sign-on with internal tools, a compromise of that service is a compromise of everything the same session can reach. Audit which services your SSO trusts. Require fresh authentication before sensitive actions rather than relying on an existing session.

There is no evidence the OpenAI vulnerability was exploited outside this research. As of mid-September 2026 it did not appear on the U.S. government's list of actively exploited vulnerabilities. Whether already-patched organisations should look for signs of earlier access is an open question the available reporting does not answer.