How Hacktron Hacked OpenAI in Under 72 Hours: A HEIC Upload to Internal Repo Access

Full credit up front: this is our summary of security research published by Hacktron — Harsh Jaiswal (@rootxharsh), Rahul Maini (@iamnoooob), and Mohan Pedhapati. The full technical writeup, with code and screenshots, is on Hacktron's own blog — read that for the primary source. We're covering it here because the story is a compact, real-world case study in two things every security leader should be tracking right now: AI-accelerated exploit development, and connected-app blast radius.

The headline numbers

• Under 72 hours from first bug to proven internal-repo access
• 2 chained vulnerabilities — an image-parsing library bug and an SSO flaw
• ~14 hours for OpenAI to ship a fix after report
• $6,500 bounty paid
• 1 harmless pull request (#1186742) as end-to-end proof

The full exploit chain

At a high level, per Hacktron's account, this was the chain:

1. HEIC/HEIF image upload to community.openai.com
2. Discourse routes the file to ImageMagick for processing
3. Heap buffer overflow in libheif during decoding
4. Remote code execution on the Discourse forum
5. A critical OpenAI SSO flaw turns forum access into identity access
6. ChatGPT and Codex account takeover for SSO users, including employees
7. Access to whatever those accounts had connected via Codex/ChatGPT integrations — GitHub among them
8. A proof-of-concept pull request, #1186742, opened in OpenAI's internal monorepo

Bug one: a known fix that was never flagged as security-relevant

Discourse's image pipeline sends HEIC/HEIF uploads to ImageMagick, because its default fast-path image library doesn't support the HEIF format. That routes attacker-controlled files straight into libheif, the underlying HEIC/HEIF decoder. According to Hacktron, the specific heap buffer overflow they used had already been fixed upstream in libheif the previous year — but the commit was never documented as a security fix and received no CVE. That's exactly the kind of fix that doesn't show up in a dependency-scanning tool tuned to CVE feeds, and it shipped unnoticed in the libheif build (1.19.7, as packaged with Debian 12) that OpenAI's forum was running. Uploading a crafted HEIC file was enough to get remote code execution on community.openai.com.

It's a pattern worth internalizing on its own: "patched upstream" is not the same as "flagged as a security fix." A dependency tree can carry a fixed-but-unlabeled bug for a year, invisible to every scanner that keys off CVE identifiers rather than diffing actual code changes.

Bug two: the one that made it serious

The Discourse RCE alone would have been a solid forum compromise. What turned it into an OpenAI-wide incident was a separate, critical flaw in OpenAI's SSO: because the forum, ChatGPT, and Codex all trusted the same centralized identity layer, compromising the forum let Hacktron pivot into ChatGPT and Codex accounts belonging to anyone who had signed into the forum through SSO — including OpenAI employees, plus some unaffiliated users. Hacktron's own framing of the underlying issue is blunt: if any first-party or third-party OpenAI service using that SSO were compromised, it would lead to the same level of access. The forum was simply the door that happened to be unlocked first.

This is the part that should worry every security leader reading this, independent of whether you run OpenAI's stack: a single-sign-on layer is a blast-radius multiplier by design. It's supposed to be — that's the whole point of SSO. But it means the security posture of your least defended connected service becomes the effective security posture of every service behind that identity.

Why the connected apps mattered more than ChatGPT itself

The compromised ChatGPT/Codex accounts weren't just chat history and prompts. Some were connected to Outlook, Gmail, Google Drive, Slack, GitHub, and other services through Codex or ChatGPT's own connector integrations. That's the actual impact multiplier: an attacker with one compromised identity doesn't just read chat logs, they inherit every integration a user has authorized — email, source code, internal chat, documents. Hacktron used one employee account connected to OpenAI's GitHub org specifically to demonstrate this: Codex, acting through the compromised account, opened a genuinely harmless pull request in OpenAI's internal monorepo, proving the access chain worked end-to-end without Hacktron ever reading proprietary code.

That's a disciplined way to demonstrate impact — enough to prove it's real, deliberately not enough to cause harm. It's also a preview of exactly the kind of blast-radius question every organization now has to answer about its own AI-agent connector sprawl: if one user's AI assistant gets taken over, what does it have write access to?

AI did a meaningful share of the exploit work

This is the detail that makes the story more than a routine (if serious) bug chain. Per Hacktron's account, Claude Opus 4.8 independently found the libheif vulnerability and built a partial exploit, but struggled across multiple sessions to make it reliable against ASLR. Hours after Opus 5 launched — the evening of July 24 — it adapted the exploit to Discourse's environment and reached a working remote-code-execution proof of concept against Hacktron's own test instance, reportedly producing a working ARM64 exploit within about three hours of the new model's release and a ported x86-64 version within six.

Hacktron frames their own takeaway plainly: AI is reducing the amount of scarce expertise needed to develop exploits. Work that used to require a well-resourced team and months of effort is compressing into days — and this chain was reportedly part of a broader two-month research effort ("HEIF Heist") spanning Slack, Meta, GitHub Enterprise, and Node.js frameworks, run for under $3,000 in total AI token costs. We've covered this exact trend from the defender's side before, in a recent npm supply-chain infostealer where AI-accelerated obfuscation and delivery chains showed up on the attacker's side too — and it's a big part of why we wrote about what an autonomous AI pentesting agent means for your security program: the tooling gap between attackers and defenders is closing from the attacker's side first.

Timeline

What this means if you're not OpenAI

Three things to take from this, whether or not your stack looks anything like theirs:

1. "Fixed upstream" isn't a security control unless someone tracks it. A patched-but-unflagged dependency bug can sit invisible in your supply chain for a year. If your vulnerability management leans entirely on CVE-keyed scanning, you have exactly this blind spot. It's the same root-cause pattern behind the Langflow flaw now being exploited en masse to steal OpenAI and AWS keys and the recently-disclosed CVSS 10.0 auth bypass in Cisco ISE — unpatched or under-tracked auth-adjacent components turning into full-severity incidents.
2. Centralized SSO needs its own threat model, separate from "is login secure." The question isn't just whether your SSO provider is trustworthy — it's what the blast radius looks like if the least-hardened service trusting that SSO gets popped. A community forum, a support portal, an internal wiki: any of them can become the door.
3. AI-agent connector sprawl is now part of your attack surface, not just your productivity story. Every AI assistant a user connects to Slack, GitHub, email, or cloud storage inherits that user's blast radius the moment the assistant's own account is compromised. Inventory what your ChatGPT/Codex/Copilot-equivalent accounts are actually connected to before an incident forces you to find out.

Put your own SSO blast radius to the test

PlayCISO's free Identity Risk Calculator scores a human, service, or AI identity 0–100 across blast radius, authentication strength, exposure, and governance — built for exactly the question this incident raises: what happens if this identity gets compromised? For a hands-on version of the incident itself, the Cyber War Room lets your team run a live breach-response simulation under the clock, and the free CISO Readiness Scorecard covers identity governance and incident-response posture as scored dimensions in about two minutes.

Frequently asked questions

What two bugs did Hacktron chain to hack OpenAI? First, a heap buffer overflow in libheif (an HEIC/HEIF image-decoding library) — fixed upstream but never flagged as security-relevant, so it shipped unnoticed in the Debian 12 package OpenAI's Discourse forum used. Uploading a crafted HEIC file to community.openai.com gave remote code execution. Second, a critical OpenAI SSO flaw: since the forum, ChatGPT, and Codex all trusted the same SSO, compromising the forum let Hacktron take over ChatGPT/Codex accounts for anyone who had signed in through it, including employees.

How did Hacktron prove the access was real without reading sensitive data? They used one compromised employee account connected to OpenAI's GitHub org via Codex, and had Codex open a harmless pull request — #1186742 — in OpenAI's internal monorepo, proving the chain worked end to end without reading proprietary source code.

What role did AI play in finding and building the exploit? A large one. Claude Opus 4.8 found the libheif vulnerability and built a partial exploit but struggled against ASLR. Hours after Opus 5 launched, it adapted the exploit to Discourse and achieved working remote code execution on Hacktron's test instance.

How fast did OpenAI and Discourse fix the bugs? OpenAI fixed the SSO flaw roughly 14 hours after the initial report. Discourse received a separate report Saturday, replied Sunday, and shipped a fix Monday. OpenAI paid a $6,500 bounty for the SSO issue.

What's the broader lesson for security leaders? AI is compressing exploit-development timelines that used to require months of expertise down to days, and centralized SSO plus connected-app integrations mean one compromised identity can cascade into email, source code, and internal chat. Defenders need to patch faster and architect for blast-radius containment, not just faster patching alone.