A malformed image reached OpenAI's internal monorepo — because an employee's ChatGPT login was also a write credential for GitHub

The chain

Hacktron lays it out as nine hops, and the list is worth reading in full because every single link is boring:

libheif → Debian → ImageMagick → Discourse → community.openai.com → OpenAI SSO → ChatGPT / Codex → GitHub → internal repos.

libheif 1.19.7 carried a heap buffer overflow in the handling of overlay image items, giving an out-of-bounds read/write primitive on specially crafted HEIF or AVIF files. Debian 12 shipped the affected version without the relevant security backport. ImageMagick calls libheif to convert formats. Discourse hands uploaded images to ImageMagick. OpenAI’s community forum runs Discourse.

So: upload an image to a support forum, get code execution on the forum.

That is a supply-chain-shaped bug, and on its own it is a bad day for one server. The escalation is the part OpenAI owned:

the vulnerability to escalate is not Discourse-specific. It is an OpenAI SSO issue that turned the forum compromise into access to ChatGPT and Codex.

With employee ChatGPT and Codex sessions in hand, the researchers looked at what those sessions were already connected to. One employee’s Codex held a connection to OpenAI’s GitHub organisation. They did not need to steal a token, escalate further, or find another bug. They sent the compromised Codex account a prompt asking it to open a pull request, and it did — in the internal monorepo.

Then they stopped, at 15:30 UTC on 25 July, having opened the pull request as proof and, by their own account, without allowing themselves to learn sensitive information.

The finding is the connector graph

The reason this belongs in a buyer’s briefing rather than only a security newsletter: no part of this was an AI vulnerability.

There was no prompt injection. No jailbreak. No model misbehaviour. No agent escaping a sandbox. The models on the defending side did nothing wrong at all.

What the AI product contributed was reach. An assistant account is, by design, a hub: it is one login that accumulates authenticated connections to source control, documents, calendars, ticketing and cloud consoles, because that accumulation is the product. When the login falls, the hub falls with it — and in this case the hub included write access to the organisation’s monorepo, reachable by sending the assistant an ordinary-looking instruction.

This is now a recurring shape rather than a one-off. In August, Microsoft fixed a one-click flaw in Copilot Personal where the damage ran through OAuth-connected Gmail and Drive access and memory poisoning that survived password changes and session revocation — again, the app was the entry point and the connectors were the blast radius. In September, mass exploitation of a Langflow RCE showed attackers going straight for OPENAI_API keys and AWS credentials in environment variables rather than deploying ransomware, because the credentials were worth more than the host.

Three incidents, one lesson: the thing worth defending is not the chat interface, it is the set of privileges hanging off it.

There is a design point here too. When OpenAI wired ChatGPT into Epic’s EHR earlier this month, the connector was deliberately read-only. That constraint looks conservative right up until an incident like this one, at which point it is the difference between an information disclosure and an attacker-authored commit.

The dated capability step

The second finding is narrower but sharper, and it comes with timestamps.

Hacktron started on 23 July 2026. On 24 July the team worked on the exploit using a version of Claude Opus 4.8 made available to cybersecurity researchers, and, in its own words, Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled.

Anthropic released Opus 5 that evening.

Within three hours, the new model produced a working ARM64 exploit for a local Mac. The team then tasked it with porting to x86-64 and to a jemalloc heap configuration. Local RCE was confirmed by 06:00 on 25 July. Remote code execution against community.openai.com followed between 05:00 and 06:00 UTC that morning.

Hacktron adds that across the wider campaign, GPT-5.6 Sol showed another clear jump on the harder variant of the problem — exploiting a target while knowing nothing about it beyond the fact that it is vulnerable.

Take the claim at its actual size: one team, one bug class, self-reported, no independent replication. But it is an unusually clean observation, because the control and the treatment are separated by hours rather than by methodology. The same researchers, the same bug, the same target, a different model version — failing, then solved.

This is the concrete form of what the labs have been describing in policy language. OpenAI classified Astra as the first model to cross its Critical cybersecurity threshold, and Anthropic’s approach has been to ship frontier security capability as a product you cannot prompt rather than as a model you can. It is worth noting that the gating worked as intended in one direction here — Hacktron was using a researcher-access build — and that the capability arrived anyway, on schedule, through the general release.

The thing that changed for defenders is lead time. The old implicit assumption was that a memory-safety bug in a common dependency takes real expertise and real weeks to weaponise against a specific deployment, and that patch windows could be sized against that. Hacktron’s economics say otherwise: the whole campaign across multiple companies ran on under $3,000 in tokens over two months with three researchers, typically one to two days per target, with the OpenAI portion consuming only a few hours of human time.

AI is reducing the amount of scarce expertise needed to develop exploits. Work that once took months can now take days.

That is the founder, Mohan Pedhapati, and the sentence is about supply of attackers rather than sophistication of attacks.

What the response tells you, and what it does not

The remediation numbers are good. Submission to OpenAI landed between 08:00 and 10:00 UTC on 25 July; OpenAI confirmed a fix at 22:49 UTC the same day, roughly fourteen hours later. Discourse was reported the same day, responded on 26 July, had a fix adding sandboxing to image processing ready on 27 July, and published advisory GHSA-vhm9-85gw-x335 on 28 July. The libheif issue was corrected upstream via a commit simplifying overlay overlap area computation; some secondary coverage has attached a CVE identifier that the researchers’ own account does not use, so that attribution should be treated as unconfirmed.

OpenAI paid $6,500 on 1 September, with a scoping note: testing against the Discourse-hosted community.openai.com was explicitly excluded from its bug bounty programme, and the award recognises the OpenAI-side finding rather than the actions against Discourse. That is a defensible line, and it also illustrates a gap worth checking in your own programme — the forum that turned out to be the front door was out of scope.

The temptation is to read fourteen hours as a vendor quality signal. It is not one. Across three coding-agent disclosures this desk tracked in September, no vendor’s patch latency held steady — Anthropic went from 16 days and a bounty to 44 days and no CVE; OpenAI went from closing a report as informational to fixing in a week. Responsiveness varies by incident far more than it varies by vendor, which means it cannot be procured.

What to do

For anyone running AI assistants with connectors — which by now is most organisations using the coding tools or any agent platform:

Inventory the connector graph. For every assistant account, list what it is connected to and whether each connection is read or write. The unit of risk is the account’s privileges, not the account.

Default to read-only, and scope writes. Where an agent needs repository write access, scope it to specific repositories rather than an organisation, and make agent-authored changes require a human approval that the same credential cannot produce.

Treat assistant sessions as privileged sessions. Session lifetime, step-up re-authentication on sensitive actions, and — the one most often missed — revocation that actually invalidates connected-app tokens rather than only the login.

Patch the periphery on the production schedule. Community forums, support portals, status pages and marketing sites are where image pipelines, file parsers and old dependency versions live. In this incident the forum was hop five of nine.

Size your patch window against a model release cadence. The gap between a public dependency bug and a working exploit against your deployment is no longer gated on scarce human expertise. That is not a reason to panic; it is a reason to stop budgeting weeks where the evidence now says days.

For developers specifically: the account you use to talk to a coding agent is a production credential. It has been for a while. This is the incident that makes the point unambiguous.

Sources: Hacktron AI — Hacking OpenAI (first-hand account and timeline); TechCrunch; The Register; CBS News; Discourse advisory GHSA-vhm9-85gw-x335. Model-capability claims (Opus 4.8 failing, Opus 5 succeeding in three hours) are Hacktron’s self-reported account and have not been independently replicated. The CVE identifier some outlets attach to the libheif flaw does not appear in the researchers’ writeup and is treated here as unconfirmed.

Questions or corrections? Email Pick Right. Want the full list? See all news.