An SSO misconfiguration, not the AI, turned a forum image bug into OpenAI repository access

One bug, two scores, 1.7 points apart

The National Vulnerability Database record for CVE-2026-32882 was published on 19 May 2026. The GitHub CNA scored it CVSS 3.1 base 7.1, with the vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H. Read the two letters that matter: confidentiality impact Low, integrity impact None. The description says a crafted HEIF file can cause "a denial of service (crash) or potentially disclose adjacent heap memory". CISA's own ADP entry on the same record marks technical impact as partial and automatable as no.

On 28 July 2026, Discourse published GHSA-vhm9-85gw-x335 for the same CVE in its own product. Its score is 8.8, with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Confidentiality High, integrity High, availability High, and no user interaction required. Its one line summary is that the upstream libheif flaw "allows for remote code execution via Discourse image uploads".

Nothing about the defect changed between those two records. The code was identical. What changed in the intervening ten weeks is that three researchers at Hacktron AI, helped by a language model, turned a bug that the public record described as a read into working code execution, used it to get administrative control of OpenAI's community forum, chained that to a misconfiguration in OpenAI's single sign on, took over an OpenAI employee's ChatGPT and Codex account, and had that account open a pull request in OpenAI's internal monorepo. From first look at the code to a pull request inside OpenAI took under 72 hours.

What actually happened, in order

OpenAI runs its help forum, community.openai.com, on Discourse, and offers "Sign in with OpenAI" through auth.openai.com. The researchers, Harsh Jaiswal, Mohan Pedhapati and Rahul Maini, say they started from a hypothesis rather than from a bug: that compromising the forum could create a path into broader OpenAI services through that identity flow. Discourse itself is a hard target, so they went after a dependency.

On 23 July 2026 they reviewed Discourse's image upload pipeline and found that HEIC and HEIF files took an unusual route. Discourse normally uses FastImage for image checks, but FastImage does not support HEIF, so those files were passed to ImageMagick's magick command for conversion. That put the libheif parser directly in front of attacker supplied files. In other words, the format that iPhones produce by default was the one that bypassed the cheap check and reached the expensive one.

Timeline as stated by the researchers, with the vendor records that corroborate each step

When	What happened	Corroborated by
5 May 2025	Upstream libheif commit "simplify overlay overlap area computation" lands, with no security label	The commit itself, authored 5 May 2025
19 May 2026	CVE-2026-32882 published: heap over-read in HeifPixelImage::overlay(), fixed in libheif 1.22.0	NVD record, CWE-125, CVSS 7.1 from the GitHub CNA
23 July 2026	Researchers review Discourse's image upload path and find HEIF files routed to ImageMagick	Researchers' write-up only
24 July 2026	Opus 4.8 produces an exploit with ASLR disabled; later sessions with ASLR enabled fail. Anthropic releases Claude Opus 5 that evening	Anthropic's Opus 5 announcement, dated 24 July 2026
25 July, 06:00 UTC	Local code execution via image upload confirmed; by 10:00 an autonomous loop has RCE on the team's own Discourse Cloud instance	Researchers' write-up only
25 July, 08:00 to 10:00 UTC	Report submitted through OpenAI's Bugcrowd programme	Researchers' write-up only
25 July, 13:30 to 15:30 UTC	Employee account taken over, pull request opened in openai/openai, all testing stopped	Researchers' write-up only
25 July, 22:49:45 UTC	OpenAI confirms the issue is fixed, roughly 14 hours after submission	Researchers' write-up; OpenAI told the FT it had fixed the issues
27 to 28 July 2026	Discourse has a fix ready, adds Landlock sandboxing for image processing, publishes GHSA-vhm9-85gw-x335	Discourse commit dated 27 July 2026; advisory published 28 July 2026
8 August 2026	Debian issues DSA-6417-1 for libheif on Debian 13, covering twelve CVEs including this one	Debian security announcement and security tracker
1 September 2026	OpenAI awards 6,500 US dollars and marks the report resolved	OpenAI's own comment quoted on the researchers' page

The arithmetic on the first two rows is worth doing. The upstream change the researchers cite as the fix landed on 5 May 2025. The CVE that eventually described a flaw in that same function appeared 379 days later. From the CVE's publication to working code execution on OpenAI's forum was a further 67 days. As of today, 18 September 2026, the whole story is 501 days old counted from that commit.

Whether the 2025 commit and CVE-2026-32882 describe the same defect is not established by anything reachable. The commit message is a refactoring note. The CVE describes a stride confusion between the alpha plane and the colour planes. Discourse attributes the remote code execution to that CVE number. The researchers describe out of bounds read and write primitives, where the CVE describes only a read. Treat the exact provenance as open, and the operational lesson as closed: a memory safety defect in a widely embedded image decoder went unlabelled for over a year, and the labelling system is what most organisations use to decide whether to patch.

Separating what the model did from what the humans did

The headlines are "researchers used Claude to hack OpenAI". That sentence is true and it is also carrying a great deal of weight it has not earned. The researchers themselves are careful about this, and their own summary is that skilled human guidance "remained important". The specific division of labour, as they describe it, is more useful to a defender than the headline.

A model inspected the libheif package installed in the Discourse Docker image and found that security fixes had not been back-ported. A model wrote the exploit: Opus 4.8 managed it with ASLR disabled, failed across several sessions with ASLR enabled, and Opus 5, released that evening, produced a working ARM64 exploit for a local Mac in about three hours before being asked to port it to the x86-64 and jemalloc environment Discourse actually uses. A model, placed in an autonomous goal loop, achieved code execution against the team's own Discourse Cloud instance overnight and proved it by reading a file.

Humans chose frontier AI labs as a research target. Humans formed the hypothesis that the forum was a route into OpenAI's identity layer, which is the entire idea. Humans read the image upload pipeline and noticed the HEIF detour. Humans found the single sign on misconfiguration, or at least no source says otherwise. Humans took over the employee account, wrote the prompt that made Codex open the pull request, decided to stop at 15:30 UTC, and ran two coordinated disclosures.

Division of labour as described in the researchers' write-up. "Not stated" means no source reviewed for this briefing addresses it

Step in the chain	Attributed to the model	Attributed to a human or not stated
Choosing the target and the hypothesis	No	Human
Spotting the HEIF detour in the upload pipeline	No	Human
Finding the missing libheif backport	Yes, an Opus 4.8 session inspecting the Docker image	Human framed and ran the session
Writing a working exploit with ASLR enabled	Yes, Opus 5, after Opus 4.8 failed repeatedly	Human supplied the porting targets
Reaching RCE on a live Discourse instance	Yes, in an autonomous loop against the team's own instance	Human built the proxy that got past the model's refusal
Finding the OpenAI SSO misconfiguration	Not stated	Not stated, but presented as the team's hypothesis
Taking over the employee account	Not stated	Human, in the first person plural
Opening the pull request	Yes, the victim's Codex executed it	Human wrote the prompt
Deciding to stop and disclose	No	Human

A classifier is a label, not a boundary

Anthropic published the Claude Opus 5 announcement on 24 July 2026, the same evening the researchers switched models. It states that Opus 5 "does not advance the frontier in risky, dual-use capabilities", that it "remains substantially behind" a more restricted model on exploitation, and that its cyber classifiers allow the model to find vulnerabilities in source code but block "binary-based" vulnerability scanning, penetration testing and exploit generation.

Within hours of that publication, the model generated a working binary exploit for a heap corruption bug, and then ported it to a different architecture and allocator. The researchers also describe putting it into an autonomous loop against a remote target, which required a workaround: they proxied their own Discourse Cloud instance through a domain that made it look like a capture the flag challenge, because the model refused to write exploits for remote instances.

Be precise about what this shows and what it does not. The researchers were attacking their own infrastructure at that point, which is exactly what a security team should be able to do. The classifier did fire. But it keyed on the apparent context of the request, not on the nature of the artefact being produced, and a change of hostname was enough to change the context. "Cyber classifier" is a comforting name. On this evidence it is a friction control that shapes who bothers, not a boundary that determines what is possible.

Vendor statements from the Opus 5 announcement of 24 July 2026 against what the researchers report doing with the model

Stated in the announcement	Reported by the researchers
Classifiers block binary-based vulnerability scanning, penetration testing and exploit generation	A working ARM64 binary exploit in about three hours, then ported to x86-64 with jemalloc
Opus 5 does not advance the frontier in risky, dual-use capabilities	Opus 4.8 failed across several sessions on the same problem; Opus 5 succeeded
Opus 5 remains substantially behind a more restricted model on exploitation	Not contradicted, and the researchers report a further jump to a rival model later in the campaign
No public statement on refusal bypass	A CTF-styled proxy domain was used because the model refused remote instances

What was authorised, and what was not

This matters more than the coverage suggests, and the clearest statement on it comes from OpenAI, quoted on the researchers' own page alongside the bounty award. OpenAI says that "testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program", and that the award recognises the OpenAI side finding, not the actions against Discourse.

So the step that produced remote code execution, the one the headlines are about, was outside the programme's scope. The step that was in scope, paid, and fixed in about 14 hours was the identity misconfiguration. Discourse was notified separately through its own HackerOne programme, on a Saturday, and had a fix ready by the Monday. The autonomous exploitation loop ran against an instance the researchers owned. Nothing in the record suggests malice, and both vendors have behaved well, but a UK security leader reading this as a template should notice where the authorisation actually sat.

Authorisation as recorded in OpenAI's comment and the researchers' timeline

Action	Authorisation on the record	Outcome
Exploiting Discourse on community.openai.com	Explicitly excluded from OpenAI's bounty scope	Not rewarded; reported to Discourse via HackerOne
The OpenAI SSO finding	In scope, submitted via Bugcrowd	Fixed same day; 6,500 US dollars awarded on 1 September
Taking over an OpenAI employee's account	Not stated as separately authorised	Testing stopped at about 15:30 UTC the same day
Opening a pull request in the internal monorepo	Not stated as separately authorised	Link later redacted at OpenAI's request
Autonomous exploitation loop	Against the team's own Discourse Cloud instance	RCE achieved and demonstrated by reading a file

Where the coverage drifts from the primary source

The researchers are notably disciplined about impact. They say they opened the pull request "to demonstrate impact without actually accessing any internal code", and that they deliberately avoided learning anything sensitive. Several pieces of coverage say something stronger. The Financial Times report syndicated by Ars Technica says the account "permitted them to read private software information and suggest changes" and its standfirst refers to sensitive GitHub data. Aggregated coverage has gone further still, describing access to internal GitHub, Outlook and Slack, where the write-up describes those only as the theoretical scope of what connectors could reach.

This is not a complaint about journalists. It is a reminder that if you are briefing your board on this story next week, the primary source and the secondary coverage support different claims, and the difference is precisely the part your board will ask about.

Primary source against secondary coverage, for the claims most likely to reach a board paper

Claim	Researchers' write-up	Secondary coverage
Internal code read	Explicitly not accessed	FT via Ars Technica refers to reading private software information
Systems reached	GitHub demonstrated; Slack and email named as theoretical connector scope	Aggregators list GitHub, Outlook and Slack as reached
Cost in tokens	Under 3,000 US dollars for the whole two month campaign across many targets	Attributed by aggregators to this operation alone
Customer data and model weights	Not addressed	Some outlets report an OpenAI confirmation; no primary statement found
The Opus 4.8 build used	Not specified	TechCrunch describes a special version for security researchers

The part nobody has described, and why it should worry you anyway

No source states what the SSO misconfiguration was. Not the write-up, not OpenAI, not any of the coverage. Given that it has been fixed and that the researchers say any service using OpenAI SSO would have produced the same result, the reticence is defensible. It does mean that the single most transferable lesson in the story has to be reconstructed from its shape rather than read off a patch note.

The shape is familiar to anyone who has run an enterprise identity estate. A low assurance property, a community forum, was wired into the same identity flow as high assurance ones, the product accounts of staff and customers. Compromising the low assurance property yielded sessions on the high assurance ones with no user interaction. The researchers state plainly that this was an OpenAI identity flaw rather than a Discourse one.

That pattern has several ordinary causes, and it is worth checking yours against all of them. A single OAuth or OIDC client shared between a marketing or community property and a staff or product property, so that one client secret or one redirect URI governs both. Over-permissive redirect URI matching, where a wildcard or a path prefix lets a compromised host receive authorisation codes. An identity provider that treats any successful authentication as equivalent, so a session minted for a forum carries the same assurance as one minted at a hardware key prompt. And a connector model in which an assistant, having been granted access once, acts continuously with the user's full authority.

The last of those is the one most UK organisations have acquired in the past eighteen months without deciding to. When an employee connects an AI assistant to a source control organisation, that assistant holds a standing grant to act as that employee. It appears in your logs as the employee. It survives the employee's next password change. It is rarely in the scope of a joiners, movers and leavers review, because it is not a person, not a service account in your CMDB, and not a machine identity your PAM tool knows about. In this incident it is the thing that turned a stolen session into a commit in a monorepo.

There is also a detection lesson buried in the researchers' wider campaign. They report sending thousands of crafted images at a range of large companies, repeatedly crashing image processors, and say they are aware of only one company that detected the activity. Repeated crashes in an image conversion worker are not a performance problem. They are the loudest signal this class of attack produces, and almost nobody is alerting on it.

The patch picture, including the part that is still open

Discourse's advisory lists patched versions 2026.7.0, 2026.6.1, 2026.5.2 and 2026.1.6, and warns self-hosters that updating through the web interface may not replace the underlying Docker image. The rebuild is the fix. Discourse also added defence in depth on 27 July 2026 by routing all ImageMagick calls through a Landlock sandbox, which the commit notes requires Linux kernel 5.13 or above.

Debian issued DSA-6417-1 on 8 August 2026 for Debian 13, bringing libheif to 1.19.8-1+deb13u1 and covering twelve CVEs at once, which is itself a statement about how much unlabelled work had accumulated in this decoder. Debian 12 bookworm is a different matter: on 18 September 2026 the Debian security tracker still lists bookworm as vulnerable to CVE-2026-32882, at 1.15.1-1+deb12u1. That is 41 days after the Debian 13 fix and 501 days after the upstream commit.

One wrinkle to note rather than resolve. The researchers say the Discourse image was based on Debian 12 and carried libheif 1.19.7, but bookworm's archive version is 1.15.1. The reasonable inference, and it is an inference, is that the image obtained libheif from somewhere other than the default bookworm archive. If you run container images built on a stable base, that is the question to ask of your own builds: which channel did this library actually come from, and does your distribution's security feed cover that channel.

What to do, in the order worth doing it

Two of those deserve emphasis because they are cheap and almost nobody does them. Restricting accepted image formats costs a configuration change and removes an entire parser from your attack surface. Reviewing assistant connector grants costs an afternoon and closes the specific gap that took this incident from a public forum to an internal monorepo.

Interests declared, including ours

Hacktron sells an AI security platform: pull request review, automated security workflows and what it markets as whitebox pentests in hours rather than weeks. The write-up ends with an invitation to frontier labs and other operators of internet critical systems to work with the company, and a contact address for anyone who thinks they are affected. That does not make the research less real, and the disclosure conduct on the record is good: two coordinated reports, a fast stop, a redacted link at OpenAI's request. It does mean the framing, that expertise is becoming compute and your threat model is out of date, is also the company's sales argument. Read the evidence, discount the conclusion by the usual amount, and note that the evidence here is unusually checkable.

Anthropic is named throughout this story as the maker of the model that wrote the exploit, and Anthropic is a direct competitor of OpenAI. Anthropic declined to comment to the Financial Times. This briefing was researched using Claude, which is made by Anthropic. Readers should weigh that, and can check every load bearing claim in it against the primary records listed in the sources, which is the point of listing them.

The question this exposes

Most vulnerability management in UK organisations is a function of two inputs: does a CVE exist, and what is its CVSS score. Apply that process honestly to this defect. For 379 days there was no CVE at all, because the upstream fix was filed as a refactor. For the next 67 days there was a CVE that said integrity impact None and a CISA assessment that said technical impact partial and automatable no, which in most triage queues means a backlog ticket. On day 68 someone spent a few hours of human time and under 3,000 US dollars of tokens and it became remote code execution at 8.8.

So the question is not whether you would have patched libheif. It is this: on which day would your process have patched it, and what is sitting in that same gap in your estate right now, fixed upstream, unlabelled, and waiting for somebody to point a model at it?