Opus 5 wrote the exploit Opus 4.8 couldn't, and it ended in OpenAI's monorepo
Hacktron published the write-up on September 18: an unpatched heap buffer overflow in libheif 1.19.7, reached through the Discourse image upload pipeline on community.openai.com, chained with an OpenAI SSO misconfiguration into account takeover. A malicious HEIC upload gave remote code execution. The SSO flaw turned that into employee ChatGPT and Codex accounts, plus the GitHub, Slack and email integrations hanging off them. To demonstrate impact without touching anything sensitive, they opened a harmless proof-of-concept pull request in OpenAI's internal monorepo using a compromised employee's Codex account.
The timeline is tight enough to be worth reading as a capability measurement. July 23 to 24, research and initial exploit development. July 25 at 05:00 UTC, confirmed RCE. Report submitted via Bugcrowd by 10:00. PoC pull request demonstrated by 15:30. OpenAI confirmed the fix at 22:49:45 the same day. Under 24 hours from working exploit to patched.
Here is the line that matters and it has nothing to do with OpenAI. Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5's release, it succeeded. Same researchers, same target, same unbackported CVE, and the variable that moved was the model. Memory-corruption exploitation with ASLR is about as clean a capability threshold as offensive security has, because it either works or it does not, and there is no partial credit and no benchmark contamination to argue about. A model generation boundary landed exactly on it.
The bounty was $6,500, awarded for the OpenAI-side SSO finding only, since Discourse testing was explicitly out of scope. That is a funny number next to an internal monorepo commit, and it is also the part of the story with the least signal. The signal is that a security-agent company now has a reproducible before-and-after on a task that used to take a specialist weeks, and the after happened within hours of a model release. Write-up at https://www.hacktron.ai/blog/hacking-openai.
Related: the ZCode git-history upload https://clauday.com/article/a811ecfd-0075-4572-ae4e-9704fbfe7323
← Back to all articles
The timeline is tight enough to be worth reading as a capability measurement. July 23 to 24, research and initial exploit development. July 25 at 05:00 UTC, confirmed RCE. Report submitted via Bugcrowd by 10:00. PoC pull request demonstrated by 15:30. OpenAI confirmed the fix at 22:49:45 the same day. Under 24 hours from working exploit to patched.
Here is the line that matters and it has nothing to do with OpenAI. Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5's release, it succeeded. Same researchers, same target, same unbackported CVE, and the variable that moved was the model. Memory-corruption exploitation with ASLR is about as clean a capability threshold as offensive security has, because it either works or it does not, and there is no partial credit and no benchmark contamination to argue about. A model generation boundary landed exactly on it.
The bounty was $6,500, awarded for the OpenAI-side SSO finding only, since Discourse testing was explicitly out of scope. That is a funny number next to an internal monorepo commit, and it is also the part of the story with the least signal. The signal is that a security-agent company now has a reproducible before-and-after on a task that used to take a specialist weeks, and the after happened within hours of a model release. Write-up at https://www.hacktron.ai/blog/hacking-openai.
Related: the ZCode git-history upload https://clauday.com/article/a811ecfd-0075-4572-ae4e-9704fbfe7323
Comments