Hacktron used Claude to breach OpenAI in under 72 hours

Three security researchers reported that they breached OpenAI's infrastructure in under 72 hours, using Claude to help build the exploit, and then told OpenAI about it through its own bug bounty program. The breach itself — a bug in an image-upload pipeline that ends in a pull request against an internal repository — is a solid piece of security research. The detail worth sitting with is smaller: an earlier Claude model couldn't finish the exploit, and the next one did, in the same afternoon it shipped.

That's not a story about Claude "hacking OpenAI." It's a story about what happens to your threat model when the tool your adversary — or you — are using gets meaningfully better overnight.

TL;DR

The exploit chain

Research began July 23, 2026, when Hacktron's team started examining the image-upload pipeline on OpenAI's community forum, community.openai.com, which runs on the Discourse platform. Discourse normally validates uploaded images with FastImage. FastImage doesn't support HEIC/HEIF files, so Discourse's code path handed those files to ImageMagick's magick command instead — exposing the underlying libheif parser directly to attacker-controlled input (Tom's Hardware).

That single routing decision — send the unsupported format to a different, less-scrutinized parser — is the kind of gap that's easy to miss in code review and easy to find once you're specifically looking at how a validation library's format list doesn't match what the application actually accepts.

From there, the chain moved in a straight line:

1. HEIF upload → libheif heap overflow. A crafted HEIC/HEIF image triggered memory corruption in libheif.
2. Heap overflow → remote code execution. The corruption was developed into working RCE on the server handling the upload.
3. RCE → employee account access. Combined with a separate flaw in OpenAI's SSO identity flow, the researchers took over ChatGPT and Codex employee accounts. Hacktron stresses that this second flaw is not specific to Discourse: any first-party or third-party OpenAI service using the same SSO, if compromised, would have led to the same access.
4. Employee account → GitHub access. One of those accounts had a connected GitHub account, giving the researchers reach into source control.
5. GitHub access → internal repository. The team opened a pull request against an internal, private OpenAI repository — described as harmless — purely as proof that the chain worked end to end (TechCrunch, NBC News).

Total elapsed time from the original discovery to reaching an internal repository: under 72 hours.

Why an old fix still left the forum exposed

Hacktron's own write-up explains how a decoder bug survived in production. When the team started an Opus 4.8 session with the Discourse Docker image and asked it to inspect the installed libheif package, the model found that particular security fixes had not been back-ported. The result was a heap buffer overflow that gave out-of-bounds read and write primitives during HEIC decoding.

The vulnerable code had been changed upstream the year before, Hacktron says, but the commit "was not documented as a security fix and received no CVE." That may be why Debian 12 and 13 did not receive the backports in time. Discourse's Docker image was based on Debian 12, which shipped libheif 1.19.7. Debian 13 still shipped 1.19.8 at the time, and Debian published its security update for Debian 13 on August 8, 2026. TechCrunch's summary of the bug is that libheif miscalculated where one image sat on top of another, an overlay-area computation that was enough to hijack the server.

The part that matters: Opus 4.8 stalled, Opus 5 finished

Here's the detail that separates this from a routine (if impressive) bug bounty writeup. Hacktron's team had access to a special version of Claude Opus 4.8 made available to cybersecurity researchers. On July 24 it got a code-execution exploit working with ASLR (address space layout randomization) disabled. The team then launched several separate sessions to make the exploit reliable against Discourse's default configuration with ASLR on, and those attempts failed.

Then, that evening, Anthropic released Opus 5. A new session first produced a working ARM64 exploit for a local Mac within three hours. The team asked it to port the exploit to the x86-64 and jemalloc configuration Discourse uses, and by 6:00 a.m. UTC on July 25 they had confirmed local RCE through an image upload. In Hacktron's words:

"Opus 4.8 struggled across several sessions to produce a working exploit... Within hours of Opus 5's release, we gave it the same problem and it succeeded." — Hacktron, via SoFX

Nothing else changed between those two attempts — same researchers, same target, same bug. The only variable was which model version sat behind the tool. That's the mechanism worth remembering: a task can be out of reach for a model one week and routine for its successor the next, with no warning in between and no change on the defender's side.

The goal loop, and the refusal workaround

The write-up's account of the next step matters for anyone running agents. The researchers placed Claude in an autonomous /goal loop against their own Discourse Cloud instance. They proxied it through a domain made to look like a capture-the-flag target, because, in their words, "Opus refused write exploit for remote instances." When they checked at 10:00 a.m. UTC the agent had achieved RCE on Discourse Cloud and demonstrated access by reading /etc/hosts. They then used the generated exploit script against OpenAI's instance. Hacktron adds that this was not completely autonomous hacking and that skilled human guidance remained important, while the amount of work a small team could do "increased dramatically." The refusal was real, and it was sidestepped by changing how the target was presented, not by a technical trick.

Cost and scale

Hacktron says the Discourse and OpenAI work took a few days of agent time and a few hours of human time. It places the wider HEIF Heist project, which traced libheif across services such as Slack, Meta, GitHub Enterprise and several web frameworks, at two months, three researchers and less than $3,000 in tokens. It reports that adapting the exploit to a new company usually took one or two days, and that it knew of no company that detected the activity other than Shopify, even after thousands of images were sent and image processors crashed repeatedly. Those are the researchers' own figures and claims, not independently verified numbers.

Response and timeline

The dates below come from Hacktron's published timeline and Discourse's advisory.

Malwarebytes and the news outlets reported the story in mid-September, about two months after the research window.

OpenAI's comment on the award, quoted by Hacktron, is worth reading plainly: "testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program. The award recognizes the OpenAI-side finding, not the actions against Discourse." So the $6,500 paid for the OpenAI-side finding, and the forum compromise itself fell outside the program's scope. Both sides moved quickly, and the scope wrinkle is one the researchers chose to publish.

Update (October 20, 2026): the advisory and patch details

The original version of this post did not carry version numbers. Discourse's advisory GHSA-vhm9-85gw-x335, "RCE via malformed HEIF file," is rated High with a CVSS score of 8.8, and attributes the issue to an upstream libheif vulnerability, CVE-2026-32882. It lists patched Discourse versions 2026.7.0, 2026.6.1, 2026.5.2 and 2026.1.6, and says the latest Docker image includes the patched libheif and that updating "as normal via ./launcher rebuild app" applies it. The latest supported versions also add sandboxing around image processing, where the system kernel supports it.

Hacktron's patch notice adds a warning for self-hosters: older Docker images may contain a vulnerable libheif, and a web-interface update alone may not replace the underlying image. Run git pull and then ./launcher rebuild app from /var/discourse. Discourse-hosted customers were already patched.

On the library side, Hacktron says the HEIF Heist is "not tied to a single version" and covers multiple release families (1.19.x, 1.20.x, 1.22.x, 1.23.x). As of September 14, 2026, it listed v1.23.4 as the latest upstream libheif security release and noted that v1.23.2 had been superseded by further security fixes. Distribution packages may carry backports under an older version number, so check your distribution's security advisory and not only the version string.

What developers are saying

The Hacker News thread on Hacktron's post drew over 200 comments. A few reports with technical content:

• User sams99 wrote an update from the Discourse side: Discourse now runs external binaries, including magick, inside a Landlock sandbox, using a Ruby gem it published, and is in the process of moving from ImageMagick to libvips. The commenter said they expect more buffer overflows in native image libraries and recommended defense in depth.
• nikcub read the libheif patch and described the bug as a bounds-checking problem in image overlays, arguing that HEIF's large feature set (rotation, cropping, alpha channels, thumbnails) is far more attack surface than a forum needs. Their suggestion was to keep server-side formats simple and convert in the client where possible.

These are opinions and reports from commenters, not findings from Hacktron or OpenAI.

What to check in your own systems

Hacktron's recommendations and the advisory translate into a short list for anyone who accepts image uploads:

1. Find every place that decodes HEIC, HEIF or AVIF. Hacktron says that if an application processes user-controlled images and accepts those formats, it is highly likely to be affected by this library family.
2. Update libheif and libde265 through your distribution's security channel, and check the package's security advisory because backports keep old version numbers.
3. Disable untrusted HEIF and AVIF decoding where you do not need it. Hacktron's guidance is to do this or to isolate image processing in hardened, ephemeral sandboxes. ImageMagick's security policy supports restricting accepted formats and resource usage.
4. Rebuild self-hosted Discourse images, not only the web-interface update.

What this means for AI agent security

Two things are true at once here, and it's worth separating them cleanly.

Claude wasn't the vulnerability. The weak points in this chain were OpenAI's own infrastructure choices — a format-mismatch bug in how Discourse routed image validation, and a separate flaw in employee SSO. Claude was the capability multiplier that let three researchers move through exploit development faster than they otherwise could have. That's a meaningfully different claim than "an AI model broke into OpenAI."

The capability jump is the real signal, not the breach details. If you run Claude Code, Codex, or a similar agent against your own infrastructure — your own upload handlers, your own auth flows, your own internal tooling — the lesson isn't "watch out for HEIC uploads." It's that the ceiling on what an agent can help build or find moves with every model release, sometimes discontinuously. An attack surface you dismissed as "too hard for a model to exploit in practice" is a moving target, not a settled fact.

That's also the argument for local visibility into what your own coding agents actually touch. Per apps/sentinel-collector/README.md, Beam is a local prototype that pairs with a running Claude Code or Codex session, ingests normalized events over a PreToolUse/PostToolUse hook or the /ingest and /v1/logs endpoints, and stores them under apps/sentinel-collector/.data with known credential formats, auth headers, and URL query parameters redacted before persistence. Its skill and MCP scanner runs 11 heuristic patterns — including credential-delivery and downloaded-and-executed code shapes — against a SKILL.md or MCP config before you run it.

None of that would have stopped Hacktron's chain — it targeted OpenAI's own servers, not a local agent session. Beam's enforce mode can deny matching tool calls in Claude Code and Codex sessions on your machine through PreToolUse hooks, but that is a hook-based check, not a kernel sandbox, and it is fail-open if cached policy is missing; it has no effect on a remote exploit. What it's built for is a narrower, honest job: if your own agent is the one touching credentials, running commands, or fetching untrusted content on your machine, you get a local record of what happened and a heuristic first pass on anything you're about to install — not a guarantee, a first look.

Summary

Hacktron's researchers turned a HEIC-upload routing bug in OpenAI's Discourse-based community forum into a full chain — heap overflow, RCE, employee account takeover, GitHub access, and a proof-of-access pull request against an internal repository — in under 72 hours, and reported it for a $6,500 bounty. The detail that should stick with anyone running AI coding agents is narrower than the breach itself: a special build of Claude Opus 4.8 could not make the exploit reliable with ASLR on across several sessions, and Claude Opus 5 succeeded within hours of its release, on the identical problem. Model upgrades change what's feasible for both attackers and defenders, often without warning, which is its own argument for keeping a local record of what your own agents are actually doing.

Related reading: What is AI agent monitoring? · MCP security: a practical guide · AI agent security incidents: a timeline · Anthropic's Sept 2026 threat report: agents as orchestrators · Agentjacking: how a Sentry MCP integration hijacks coding agents · Cursor's MCP config poisoning: CurXecute and MCPoison

Sources: Tom's Hardware · TechCrunch · NBC News · SoFX · Malwarebytes

This account reflects Hacktron's write-up, Discourse's advisory and public reporting as of October 20, 2026. Details attributed to Hacktron and to OpenAI's and Discourse's responses may be updated as more information becomes available.