When Anthropic shipped Claude Opus 5 in late July 2026, a small security research outfit called Hacktron had already been quietly hammering away at a stubborn bug for weeks. Within three hours of pointing the new model at the same problem, they had a working exploit. Days later, that exploit had turned into a foothold inside OpenAI’s own community forum, employee ChatGPT and Codex accounts, and a proposed change to OpenAI’s private source code repository.

The incident, disclosed responsibly through OpenAI’s bug bounty program, is a striking demonstration of how quickly frontier AI models can compress the distance between “theoretical vulnerability” and “working intrusion” — and a reminder that the infrastructure hosting even the most security-conscious AI labs is built on the same aging open-source components as everyone else’s.

A forgotten image format opens the door

The chain started somewhere unglamorous: the image upload pipeline on community.openai.com, which runs on the open-source Discourse forum platform. Discourse’s built-in image handling library, FastImage, doesn’t understand the HEIC and HEIF formats used by modern iPhones. When a user uploads one of these files, the server falls back to ImageMagick, which in turn calls a system utility that depends on a separate open-source library called libheif to actually parse the image data.

That fallback path turned out to be the weak link. The Discourse Docker image OpenAI’s forum ran on was built on Debian 12, which shipped a version of libheif — 1.19.7 — containing a heap-buffer overflow later catalogued as CVE-2026-32882. Debian’s own next release had already moved to a patched 1.19.8, but the forum’s container hadn’t caught up. Feed the parser a maliciously crafted HEIC file, and an attacker could potentially crash the service, leak memory contents, or in the worst case execute arbitrary code.

From auditing tool to exploit generator in three hours

Researchers Harsh Jaiswal, Mohan Pedhapati and Rahul Maini had used Claude Opus 4.8 to audit the vulnerability but stalled out against a Mac target hardened with address space layout randomization. According to Hacktron’s account, handing the identical problem to Claude Opus 5 the day it launched produced a working ARM64 proof-of-concept for a local Mac in about three hours — after which the team used the model again to port the exploit to the very different x86-64, jemalloc-based environment that Discourse’s Docker containers actually run.

By roughly 6:00 UTC on July 25, 2026, the team had confirmed remote code execution through nothing more exotic than a crafted image upload, verified against a proxied instance of Discourse’s own cloud service by recovering the contents of its /etc/hosts file — a classic “proof of impact” technique that avoids doing anything more destructive while still demonstrating real access.

From a forum bug to OpenAI’s private codebase

The forum compromise alone would have been a solid bug bounty submission. What elevated it was a second, unrelated weakness: sessions on OpenAI’s community forum could be escalated into access over employee ChatGPT and Codex accounts, because of how OpenAI had wired up identity between the services. Codex accounts, in turn, were connected to GitHub — including access to OpenAI’s private monorepo.

To prove the severity without doing real harm, the researchers went one step further than most bounty submissions and opened an actual pull request, numbered 1186742, against that private repository — evidence that a genuinely malicious actor following the same chain could have proposed or altered code inside one of the world’s most closely watched software companies. The Wall Street Journal later independently confirmed the account-takeover and repository-access claims.

OpenAI’s response, and the fallout

To its credit, OpenAI moved fast. Hacktron submitted its report through Bugcrowd between 08:00 and 10:00 UTC on July 25; OpenAI confirmed a fix roughly 14 hours later, at 22:49 UTC the same day. Discourse itself published a formal security advisory, GHSA-vhm9-85gw-x335, three days after that, and OpenAI paid Hacktron a $6,500 bounty — noting that testing against the production community.openai.com site technically fell outside the program’s stated scope, but rewarding the disclosure anyway given its severity.

What organizations running Discourse — or anything with HEIC support — should do

• Pull the current Discourse image and fully rebuild application containers; patching only the web-facing code without refreshing the underlying base image leaves the vulnerable libheif binary in place.
• Update to patched libheif and libde265 packages, and disable HEIC/HEIF/AVIF decoding entirely if it isn’t a business requirement.
• Isolate any third-party image or document conversion in a hardened, ephemeral sandbox rather than the main application container.
• Lock down ImageMagick’s security policy to only the file formats actually needed — GIF, JPEG and PNG for most forums — rather than leaving every coder and delegate enabled by default.
• Audit how identity and session trust are shared across internal tools; a single sign-on misconfiguration is often the difference between “a forum got popped” and “our source code was exposed.”

The episode doesn’t suggest Claude Opus 5 discovered some novel class of AI-specific vulnerability — the underlying bug was a fairly conventional memory-safety flaw in a C library. What it does suggest is that the manual, multi-week grind of porting a working exploit from one architecture and hardening configuration to a completely different one is now something a capable model can do in an afternoon, for defenders and attackers alike.