Claude Opus 5 turned a libheif bug into RCE on OpenAI's forum in hours

What actually happened

A three-person team at security startup Hacktron AI — Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini — chained two vulnerabilities to compromise OpenAI's community forum and reach employee ChatGPT and Codex accounts. The entry point was a heap buffer overflow in libheif v1.19.7, the library that decodes HEIC/HEIF image files, triggered by uploading a crafted image that Discourse's forum software passed through ImageMagick on an unpatched Debian 12 image. From there, a second flaw in OpenAI's SSO and employee-validation setup let the team escalate from the compromised Discourse server to employee accounts with connected GitHub and Codex access, reaching internal repositories.

This is not a hypothetical. Hacktron published a timestamped log: review started July 23, 2026; exploit development with Claude Opus 4.8 began July 24; remote code execution and admin access on community.openai.com were confirmed on July 25, 2026 between 05:00 and 06:00 UTC, with employee account access and an internal repo pull request demonstrated the same day. OpenAI confirmed a fix by 22:49:45 UTC that evening. The story broke publicly on September 18, and TechCrunch, The Register, NBC News and VentureBeat all covered it independently the same day — a sign of how much the security and AI communities care about what this run represents, not just what it breached.

Why this matters beyond the headline: the interesting part isn't that OpenAI got hacked. It's the model-capability delta captured mid-engagement, and the specific class of infrastructure — third-party media decoders and SSO escalation logic — that turned out to be exploitable end to end by an agentic coding model in a single day.

The capability jump, in the researchers' own numbers

The team's original tooling, Claude Opus 4.8, could not bypass the target's ASLR (address space layout randomization) protection — a standard defense that randomizes memory addresses specifically to make heap overflow bugs like the libheif one hard to turn into working exploits. That's normally where an attack chain stalls without a specialist human exploit developer spending days or weeks on it.

After Claude Opus 5 was released, the team says it produced a working ARM64 exploit within about three hours, then ported it to x86-64. That's the number worth sitting with: the same vulnerability, the same team, the same infrastructure — but a model upgrade turned "blocked" into "working exploit, then a second architecture port" inside a single afternoon. This is the clearest public, dated case so far of a frontier model doing autonomous offensive security work at a pace no human red team matches.

Gray Swan CEO Matt Fredrikson, quoted by TechCrunch, put the accessibility angle bluntly: "For $200 a month, anyone can use these tools and hack into a company like OpenAI." That's a paraphrase of the tools' cost, not a claim that everyone will succeed — the researchers here had real exploit-development skill directing the model. But the marginal cost of getting from "found a bug" to "working exploit" just dropped by orders of magnitude for anyone who already knows what to point the model at.

Hacktron also says the technique wasn't a one-off: the same approach surfaced vulnerabilities across other major targets including Slack, Meta and GitHub Enterprise, and later engagements required minimal reconnaissance when paired with GPT-5.6 Sol. Read plainly, that's a claim that this is now a repeatable technique, not a lucky one-time chain.

OpenAI's response, and why it's a reasonable one

OpenAI paid a $6,500 bounty, awarded September 1, 2026, and stated the award recognized "the OpenAI-side finding, not actions against Discourse" — a distinction worth noting because it draws a line between the vendor's own SSO logic (OpenAI's responsibility to fix) and the third-party forum software's decoder bug (Discourse's, or ultimately libheif's, upstream responsibility). OpenAI told reporters: "We thank the researchers for contacting us and sharing their findings."

That response is standard, and the fix turnaround — same-day confirmation within about 18 hours of the RCE being demonstrated — is genuinely fast. But it also underlines the asymmetry this story is really about: the defenders needed a coordinated patch-and-confirm cycle across two organizations' software; the attackers needed an afternoon and a subscription.

The actual attack chain, as a threat model

Strip away the "AI hacked OpenAI" framing and what's left is a normal, if fast, exploit chain that maps directly onto infrastructure most engineering teams run somewhere:

1. Untrusted media upload — a forum, support portal, or any user-facing surface that accepts image uploads.
2. Third-party decoder in the path — ImageMagick invoking libheif to process HEIC/HEIF, running on an unpatched base image.
3. Memory-safety bug in the decoder — a heap buffer overflow, the kind of bug decades of C/C++ image and media libraries are riddled with.
4. ASLR bypass — previously the bottleneck step requiring specialist skill; now something an agentic model can produce in hours given a capable enough base model.
5. RCE on the service host — full compromise of the application server, in this case the Discourse instance.
6. SSO/identity escalation — a separate, unrelated flaw in employee-validation logic that turned "we own the forum server" into "we can reach employee-linked GitHub and Codex accounts."
7. Internal repository access — the actual target, reached two hops away from the original upload form.

Every one of those seven steps is ordinary. What changed is the time between step 3 and step 5. If your organization runs any user-facing upload path through ImageMagick, libvips, libheif, or a similar decoder chain, and if a compromise of that service could plausibly reach an identity system with broader access, this chain is your chain with different library versions.

What to do about it

Treat this as a deadline, not a data point. "We'll patch that CVE next sprint" was already a risky posture; a same-day exploit turnaround from bug report to working RCE makes it an unaffordable one for anything internet-facing.

Concretely: audit every service that decodes user-uploaded media — image, video, document, or archive formats — and check what library versions are actually running in production, not what's pinned in a manifest. Isolate decoder processes with strict sandboxing (seccomp, gVisor, or a dedicated unprivileged container) so a heap overflow in the decoder doesn't hand an attacker the host. Separate your SSO and employee-validation logic from any service that touches untrusted input, so a compromised forum server is a dead end rather than a stepping stone to internal repos. And if your team red-teams its own infrastructure, assume the adversary now has access to the same class of agentic coding models you do — budget defensive testing cycles in hours and days, not the weeks a purely human red team would need.

The uncomfortable part of this story isn't that OpenAI got hacked; competent, well-resourced companies get hacked. It's that the bottleneck step in a real intrusion — bypassing a standard memory protection — collapsed from "blocking" to "three hours" between two model releases, with a public, timestamped log to prove it.