AI & ML 6 min read

Claude Opus 5 Wrote the Exploit. Three People Aimed It.

A forum image upload led to an over-permissioned login token, and from there into employee accounts and an internal code repository.

Kenji Tanaka
Developer Tools & Cloud Analyst
Published 20 Sep 2026, 11:23 AM (SGT)
Share:
A partly closed laptop with its backlit keyboard glowing in a dark room A partly closed laptop with its backlit keyboard glowing in a dark room Photo by JoshuaWoroniecki on Pixabay
Advertisement

20 SEP 2026 — A bug-bounty report from three security researchers began with a crafted image uploaded to OpenAI's community forum, moved through an image library and a misconfigured login system, and ended inside OpenAI employees' ChatGPT accounts and a connected GitHub repository. The exploit that opened the path was written by Claude Opus 5 in about three hours, on the day it was released.

The researchers say plainly that this was not autonomous hacking. What changed is not who does the work but how long the work takes.

What the chain actually was

The entry point was ordinary. OpenAI's community forum runs Discourse. Discourse hands uploaded images to ImageMagick, and ImageMagick uses libheif to decode HEIC files. The Debian 12 version was libheif 1.19.7, with an unpatched heap buffer overflow because a security backport had not been applied.

Hacktron's own account describes uploading a crafted image to the forum and obtaining remote code execution on the server behind community.openai.com.

The second half was an identity problem, not a memory one. OpenAI's single sign-on gave the forum tokens more permission than the forum needed, and those tokens reached linked ChatGPT and Codex accounts. Codex was connected to GitHub, which led to an internal repository.

Where the model helped

The comparison is what makes this useful. Claude Opus 4.8 failed across multiple sessions to produce a reliable exploit with address space layout randomisation enabled. Opus 5 was released on 24 July. Within roughly three hours it produced a working ARM64 exploit on a Mac; the researchers then had it ported to x86-64 and to a different memory allocator. Remote code execution was confirmed early on 25 July.

The total token spend across the wider research project was under $3,000. Against what this class of exploit development normally costs in specialist time, that is a small fraction.

~3 hrsFrom model release to working exploit
14 hrsFrom report to OpenAI's fix
$6,500Bounty, paid 1 September
<$3,000Token cost for the wider project

What the researchers reached

Harsh Jaiswal, Mohan Pedhapati and Rahul Maini took over the accounts of OpenAI employees and reached the company's internal monorepo through the Codex to GitHub connection. The proof they left was a pull request, numbered 1186742, in the private openai/openai repository, which they describe as harmless.

They state that they did this to demonstrate impact without actually accessing internal code. The distinction they draw is that the door opened, not that the contents were read.

Remote code execution was confirmed in the early hours of 25 July. The report went in the same morning, the account access and proof-of-concept followed in the afternoon, and OpenAI fixed its side about fourteen hours after the report. The $6,500 bounty arrived on 1 September; The Hacker News reported that it recognises the OpenAI-side finding rather than the work against Discourse.

The caveat in their own words

The researchers wrote that this was not completely autonomous hacking, and that skilled human guidance remained important. The reporting has generally carried that caveat: one account describes it as human expertise remaining necessary to direct sessions, validate results and manage disclosure, while the model compressed exploit engineering that had previously demanded substantially more time and specialist labour.

The two readings lead to different places. If you can point a model at a target and walk away, offensive security becomes constrained by compute. If the model collapses the tedious part of exploit development for people who already know which bug to chain to which misconfiguration, the constraint remains expertise, and what changes is throughput.

The evidence supports the second reading. Three people who find bugs for a living chose the components, recognised that an over-permissioned token was worth following, and directed the porting. The model wrote the part that used to take days.

Advertisement

How this differs from an accident

We reported yesterday on a model reaching three real companies during an evaluation because the test environment leaked. That was a containment failure: nobody intended the target.

This work was the opposite. The target was chosen, the engagement was authorised through a bounty programme, the vendor was notified within hours and paid. The common element is capability, not intent, and only one of the two was an accident.

Neither establishes a rate. Two episodes in two months is not a trend line. The useful comparison would be how long this class of chain takes a comparable team without a frontier model, and nobody has published that.

Advertisement
Kenji Tanaka
Developer Tools & Cloud Analyst

Kenji Tanaka covers developer tools, cloud platforms, DevOps, CI/CD, and software supply-chain topics for RECATOOLS.

View author profile → · Editorial policy

About this byline Kenji Tanaka is a RECATOOLS editorial persona for developer tools, cloud, DevOps, and software supply-chain coverage. Articles are produced and reviewed under RECATOOLS editorial supervision.

Corrections policy

Advertisement