A Security Team Used Claude Opus 5 to Reach OpenAI's Internal Repositories in Under 72 Hours

Three researchers at Hacktron AI chained two vulnerabilities on July 25, 2026 to take over OpenAI employee ChatGPT accounts and open a pull request in the internal monorepo openai/openai as proof of access. The whole path from first discovery to repository access took less than 72 hours, and the working exploit came from Claude Opus 5 on the evening it shipped. OpenAI confirmed the fix at 22:49:45 UTC on July 25, roughly 14 hours after the initial submission, and paid a $6,500 bounty on September 1. ASAP reads this as a story about the collapsing cost of exploit development rather than a story about one bug.

One uploaded image reached the internal repository through nine steps

The attack path Hacktron AI published runs nine steps from an image decoder to an internal repository. It starts at libheif and passes through a missing Debian security backport, ImageMagick's use of libheif, Discourse image uploads, OpenAI's official forum at community.openai.com, an identity flaw in OpenAI SSO, ChatGPT and Codex accounts, a connected GitHub integration, and the OpenAI monorepo.

The team began reviewing Discourse's image-upload pipeline on July 23, 2026 and found that HEIC and HEIF files followed an unusual route. Discourse normally checks images with FastImage, but because FastImage does not support HEIF it handed those files to ImageMagick's magick command for conversion, which exposed the underlying libheif parser directly to attacker-controlled input.

The bug itself was a heap buffer overflow. The researchers gave an Opus 4.8 session the Discourse Docker image and asked it to inspect the installed libheif package, and the model found that certain security fixes had never been backported. The upstream code had been changed the previous year, but that commit was not documented as a security fix and received no CVE. Because the Discourse Docker image was based on Debian 12, it installed the vulnerable libheif 1.19.7, and Debian 13 still shipped the vulnerable 1.19.8 at the time. Debian's own security update, DSA-6417-1, did not arrive until August 8.

The last step belonged to OpenAI rather than Discourse. The researchers stated explicitly that the escalation vulnerability is not Discourse-specific but an OpenAI SSO issue that turned a forum compromise into access to ChatGPT and Codex. Any first-party or third-party service using OpenAI SSO would have produced the same result, and Discourse was merely one way to prove it.

Opus 4.8 failed at a problem Opus 5 solved three hours after release

The densest stretch of dates in the report covers the model swap. On July 24 the team used Opus 4.8 to build a working ImageMagick and libheif code-execution exploit with ASLR disabled. They then launched several separate sessions to make it reliable against Discourse's default configuration with ASLR enabled, and none of them worked.

That evening Anthropic released Claude Opus 5. The team started a fresh session, and the model produced a working ARM64 exploit for a local Mac within three hours. They then asked it to port the exploit to the x86-64 environment and jemalloc configuration Discourse uses, and by 6:00 a.m. on July 25 local remote code execution through an image upload was confirmed.

The next stage used an autonomous loop. The researchers placed Claude in an autonomous /goal loop against their own Discourse Cloud instance, proxied through rce.ee/ctf-forum so the target looked like a CTF challenge, because Opus refused to write an exploit for remote instances. When they checked again at 10:00 a.m., the agent had achieved remote code execution on Discourse Cloud and demonstrated it by reading /etc/hosts. The generated script then produced remote code execution on OpenAI's instance.

The team reported to OpenAI as soon as the account-takeover hypothesis was confirmed. They then took over one OpenAI employee account whose Codex was connected to the OpenAI GitHub organization and, to demonstrate impact without reading any internal code, sent a prompt to that Codex account to open a harmless pull request in the monorepo. Then they stopped testing.

A $6,500 bounty and a $3,000 campaign do not belong in the same table

The economics of this incident sit in the contrast between two numbers. OpenAI paid a $6,500 bounty on September 1. The full two-month HEIF Heist campaign, which traced libheif across Slack, Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro, and Gatsby, consumed under $3,000 in tokens and was run by three researchers, with each new company typically taking one or two days of exploit adaptation.

Inverting that ratio exposes the defender's arithmetic. A single company's payout exceeds the total compute cost of a campaign aimed at many companies at once. For an attacker, the marginal cost of adding one more target is two days of human time and a few hundred dollars of tokens, while for a defender the cost of protecting one target does not move. Once the cost of reusing a single vulnerability across many deployments collapses, techniques once reserved for high-value targets reach ordinary companies.

The bounty figure also needs its context. OpenAI clarified the scope of the award by noting that testing against the Discourse-hosted community.openai.com was explicitly excluded from its bug bounty program, and that the award recognized the OpenAI-side finding rather than the actions against Discourse. The $6,500 is therefore the price of the SSO flaw, not of the chain. That a bounty scope drawn along asset boundaries diverges from the actual attack path is itself a demonstration of why supply-chain vulnerabilities are hard to surface through reward programs.

Thousands of images arrived, image processors kept crashing, and almost nobody noticed

The heaviest sentence in this report is not a number but a detection result. The researchers reported that they are not aware of any company that detected the activity except Shopify, even after thousands of images were sent and image processors repeatedly crashed.

This matters because it separates attack sophistication from detection difficulty. An image-processing worker crashing repeatedly is not a hidden signal. It is the kind of metric an ordinary operations dashboard already collects, and a spike in crashes is worth investigating even when nothing malicious is happening. That nearly every organization missed it suggests the failure came from treating crashes as a performance issue rather than a security signal, not from sophisticated evasion.

The practical conclusion is to rewire signals you already have before buying new tooling. Abnormal termination rates in image-conversion workers, spikes in uploads of a specific extension, and segmentation fault logs in conversion pipelines are already being collected in most organizations. Moving them from the performance side to the security side requires no new budget.

Bypassing the model's refusal with a proxy leaves an open question

The report's note about guardrails is short, and it is the single most consequential paragraph in the September 13, 2026 writeup. Because Opus refused to write an exploit for remote instances, the team proxied the target through rce.ee/ctf-forum to make it look like a CTF challenge, and the autonomous loop then proceeded.

That bypass is closer to relabeling context than to a sophisticated jailbreak. It indicates the model's refusal keyed on the shape of the target rather than the nature of the act, which means the signal separating legitimate security research from attack depends heavily on context the user supplies. Drawing a line inside a model that blocks unauthorized attacks without blocking lawful penetration testing and CTF work has always been hard, but the weight of that line changes once an autonomous loop carries the work to a finished artifact.

The researchers' own caveat belongs beside it. They wrote that this was not completely autonomous hacking and that skilled human guidance remained important for privilege escalation, lateral movement, and bypassing defenses. What changed is not that humans became unnecessary but that the amount of work a small team could perform increased dramatically. Their note about another clear jump from Opus 5 to GPT-5.6 Sol points the same direction, and it showed up precisely where the exploit had to be built with no knowledge of the target system beyond the fact that it was vulnerable.

Any service accepting iPhone photos has something specific to check today

Services that process user-uploaded images and accept .heic, .heif, or .avif files are highly likely to be affected, the Hacktron AI team wrote in its September 13, 2026 report. Given that iPhones save HEIC by default, that description covers commerce sites, communities, insurance claims, resale marketplaces, and support ticketing systems across the board.

Remediation splits in two directions. The first is package updates. As of September 14, 2026 the latest upstream libheif security release is v1.23.4, v1.23.2 has been superseded by further security fixes, and libde265 needs updating alongside it. Distribution packages may carry backported fixes under an older upstream version number, so the package security advisory needs checking too. Self-hosted Discourse installations need a rebuild, because a web-interface update alone may not replace the underlying image: run git pull followed by ./launcher rebuild app from /var/discourse.

The second direction is architectural. Citing the complexity of the ISO base media file format and the pace of decoder updates, the researchers expect future memory-safety flaws and recommend disabling untrusted HEIF and AVIF decoding where it is not needed, or isolating image-processing pipelines inside hardened, ephemeral sandboxes. They also note that ImageMagick's security policy supports restricting accepted formats and resource usage. Discourse shipped image-processing sandboxing alongside its fix as defense in depth.

What the report leaves open

Four items in the Hacktron AI report are left unanswered, and each one bounds how far the published findings can be generalized. First, the technical detail of the OpenAI SSO identity flaw was not published, only its character as an SSO issue. Second, the introduction describes multiple compromised employee accounts while the impact demonstration used one, and the exact count is not given. Third, what was actually confirmed at Slack, Meta, GitHub Enterprise and the other HEIF Heist targets falls outside this post. Fourth, the link to the pull request opened in the monorepo was redacted at OpenAI's request.

What can be taken from this incident with confidence is the timeline rather than the vulnerability list. A commit fixed quietly upstream without a CVE passed through two Debian releases, that package went into a Docker image, an image-conversion path exposed the parser to user input, and an identity flaw turned one forum into full account access. Every step is a known category of problem, and the only new condition is that wiring the chain into working code now takes days. What defenders need to update is not a tool list but their assumptions about how much work an attacker can afford.

Source: Hacking OpenAI (Hacktron AI, Harsh Jaiswal, Mohan Pedhapati, Rahul Maini, September 13, 2026)