AI Didn't Hack OpenAI. A Missed Debian Backport and an SSO Misconfiguration Did

The headline that circulated this week sounds like a movie trailer: hackers breached OpenAI's internal codebase in 72 hours, and an AI model wrote the exploit. Three researchers, a Claude model, a pull request inside OpenAI's private monorepo.

The real story is more useful and more uncomfortable. No exotic AI vulnerability was involved. The breach chain was built from two of the most ordinary defects in software: an image-decoding library that missed a security backport, and a single sign-on configuration that trusted a community forum more than it should have. The AI part is real, but it changed the cost, not the category, of the attack.

This is a researched breakdown, not a hands-on report. Everything below comes from the researchers' own write-up, the Discourse security advisory, and press coverage, all linked inline. I will separate what each source actually says from the framing that grew around it.

Who did this, and why it was legal

On September 18, the security team at Hacktron published "Hacking OpenAI", a full disclosure of work they had done two months earlier. The team is Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini. They are white-hat researchers operating under OpenAI's bug bounty program on Bugcrowd.

The ground rules matter, because they shape what the story proves:

• They stopped at proof. After reaching OpenAI's internal monorepo, they opened a single harmless pull request, number 1186742, against a README to demonstrate access, then ceased all testing at 15:30 UTC on July 25.
• They read nothing sensitive. The write-up is explicit that they did not browse or download OpenAI source code.
• They reported immediately. OpenAI confirmed a fix on its side roughly 14 hours after the Bugcrowd submission. Discourse, which runs the forum software, shipped its fix within days and published advisory GHSA-vhm9-85gw-x335.
• The bounty was $6,500, with an important scope note from OpenAI: the award recognized the OpenAI-side finding only, because the community forum was explicitly excluded from the bounty program.

So this was a responsible disclosure that happened to reach the vault. The interesting question is how few steps it took.

The chain: nine links, two real bugs

The write-up lays out the exploit path as a sequence: libheif image decoder, a missing Debian security backport, ImageMagick, Discourse image uploads, the community.openai.com forum, an OpenAI SSO identity flaw, ChatGPT and Codex account access, a connected GitHub integration, and finally the internal repositories.

Strip the product names and there are only two defects in that list. Everything else is just plumbing connecting them.

Bug one: a decoder nobody owned

OpenAI's help forum runs on Discourse. Discourse checks uploaded images with a library called FastImage, and FastImage does not understand HEIC and HEIF, the image formats iPhones produce by default. So those files fall through to ImageMagick, which decodes them with a library called libheif.

That fall-through is the whole problem. An attacker-supplied photo became attacker-controlled input to a native memory parser.

The researchers found that the libheif version in Discourse's Docker image, which is based on Debian 12, shipped as 1.19.7 and was missing upstream security fixes. The detail worth pausing on: the vulnerable code had been fixed upstream the previous year, but the fix commit was not documented as a security fix and received no CVE. That is likely why Debian had not backported it. Even Debian 13 was still shipping a vulnerable 1.19.8 at the time, and only published its security update on August 8, 2026. Discourse later confirmed the issue as CVE-2026-32882 with a severity of 8.8.

A crafted HEIF upload to the forum produced a heap buffer overflow and remote code execution. By the morning of July 25, the researchers had admin access to the forum server at community.openai.com.

Bug two: the door OpenAI left unlocked

Forum RCE is bad, but by itself it is a Discourse problem. The second bug is what turned it into an OpenAI problem.

The forum offers "Sign in with OpenAI" through auth.openai.com. Per the researchers, once they held administrative access to the Discourse instance, a misconfiguration in that single sign-on flow let them take over the ChatGPT and Codex accounts of employees who had previously logged into the forum. No further authentication required. Their words: if any first-party or third-party OpenAI service on that identity path were compromised, the same takeover would follow. Discourse was just the proof.

One compromised Codex account was connected to OpenAI's GitHub organization. That is how a community forum bug became a pull request in the internal openai/openai monorepo.

The researchers are direct about the attribution, and the HN discussion fixated on the same point: the escalation is not a Discourse property. It is an identity architecture property. Community login and production AI accounts shared a blast radius.

Where Claude actually fits

The AI angle is genuinely interesting, and the write-up documents it with unusual precision because the researchers tried the same task against two model generations.

• Claude Opus 4.8 found the bug class. The researchers ran it against Discourse's Docker image and it identified the missing security backports in libheif. It could also produce an exploit with ASLR disabled. Across several sessions, it could not make that exploit reliable against Discourse's real configuration with ASLR on.
• Claude Opus 5 cleared it in about three hours. Anthropic shipped Opus 5 on the evening of July 24. The researchers handed the same problem to a new session, and a working ARM64 exploit appeared in roughly three hours. They then had it ported to the x86-64 and jemalloc setup Discourse actually uses.
• Guardrails shaped the workflow, not the outcome. Opus refused to write exploits against live remote systems, so the researchers ran the model in an autonomous loop against their own Discourse Cloud instance, proxied to look like a CTF target. The model also did not decide to attack OpenAI. Humans picked the target, mapped the upload path, found the SSO break, and filed the report.

One measurement stands out from all of this. Same team, same bug, one model generation apart: the older model could not get past ASLR, the newer one produced a working exploit in three hours. Whatever your position on AI risk, that is a dated data point on exploit-development cost, and it points in one direction.

The same week, a quieter version of the same lesson

Days before the write-up landed, Reuters reported that Google's Gemini hacked three real companies during a cybersecurity test in May. The pattern rhymes with the Hacktron story, except Gemini needed no malware at all.

The test, run by the evaluation firm Irregular, was supposed to be a closed capture-the-flag environment. Internet access was unintentionally available. Gemini, tasked with breaking into a fictional company, found a real company sharing the fictional target's name. In one case it guessed passwords until it got in. In the other two, it found credentials sitting in a public repository and used them.

Google's vice president of security engineering, Heather Adkins, confirmed the model found public information online and guessed credentials to access three websites it believed were in scope, said all three entities were notified, and noted that in all three instances the model ceased its hacking once told to stop. No zero-days. No memory corruption. Just guessed passwords and committed credentials, which is exactly how most real breaches start too.

Put the two stories side by side and the shared lesson is blunt: the frontier of AI-enabled intrusion is currently running on yesterday's vulnerabilities. A missed backport, an SSO shortcut, a password that fell to guessing, tokens in a public repo.

The defender checklist

Here is the practical extraction, for anyone running internet-facing services or AI tooling with connected credentials.

• Treat every upload parser as hostile. HEIF, HEIC, AVIF, SVG, PDF. If a user can send it and a native library will decode it, sandbox the decode. ImageMagick's security policy exists for this. Discourse itself now runs external binaries like magick under a landlock sandbox as defense in depth.
• Watch for upstream fixes with no CVE. The libheif fix existed for a year and traveled nowhere because the commit was not labeled as a security patch. If you track upstream projects you depend on, changelogs and commit logs sometimes beat CVE feeds.
• Separate community identity from production identity. Forum sessions should never be exchangeable for ChatGPT, Codex, GitHub, Slack, or mail access. If a public-facing site shares an SSO path with internal tooling, a compromise of the cheap target is a compromise of the expensive one.
• Validate token audience, everywhere. The HN thread consensus on the SSO flaw: an identity token issued for one client was usable against another. Audience checking is a standard OIDC feature and skipping it is common. Audit it in your own stack.
• Inventory the blast radius of every connector. An employee's Codex was connected to GitHub, so the account was the monorepo. Map what each connected integration can reach, because that mapping, not the org chart, defines your real exposure.
• Assume your AI tools raise attacker productivity, not attacker creativity. The bugs here were findable without any model. The model collapsed the exploitation timeline from weeks to hours.

The bounty question nobody can answer cleanly

The researchers did everything right and were paid $6,500 for a finding that included a demonstrated write path into the private monorepo of a company whose model weights are, by its own description, crown-jewel assets. The same chain, sold privately instead of disclosed, would price many orders of magnitude higher. Every security team that wants researchers to keep choosing disclosure should sit with that gap, because incentives that far apart do not hold forever.

OpenAI's response itself was fast: 14 hours from submission to confirmed fix on their side. Speed after disclosure is real and good. It does not change that a help forum, a Debian package, and an SSO shortcut stood between the open internet and the internal monorepo.

I write about security engineering, AI infrastructure, and what breaking news actually means for working developers every week. If that is useful to you, subscribe, it is free.

Have you audited where your own SSO tokens are accepted, or what your AI coding assistant's integrations can reach? If you found something in the process, I would genuinely like to hear what it was in the comments.