Researchers Chained a libheif Bug and an OpenAI SSO Flaw — With Claude

Security researcher s1r1us, working with Electrovolt and Hacktron AI, disclosed a nine-step exploit chain on September 18, 2026 that took over OpenAI employee ChatGPT and Codex accounts — reaching connected Slack, GitHub, and email access — in under 72 hours from first discovery to proof of impact. The technical chain itself (a heap overflow in an image-decoding library, chained with an SSO misconfiguration) is a solid, well-documented piece of security research on its own. What makes it worth explainx.ai's attention specifically: Claude Opus 5, released mid-investigation, built a working exploit from scratch in roughly three hours after Claude Opus 4.8 had struggled with the same problem across multiple sessions — a concrete, dated data point on how fast AI-assisted exploit development capability is moving.

TL;DR

The exploit chain, step by step

The full chain the researchers documented runs: a libheif vulnerability in the image decoder → a missing Debian security backport → ImageMagick (which OpenAI's Discourse forum used to process HEIC uploads, since Discourse's default image library, FastImage, doesn't support HEIF) → the vulnerable code path becoming reachable through ordinary forum image uploads → remote code execution on community.openai.com → a separate OpenAI SSO identity flaw → ChatGPT/Codex account takeover for forum members who'd logged in, including OpenAI employees → access to whatever external services those accounts had connected (Outlook, Slack, GitHub, and others) → a proof-of-concept pull request in OpenAI's internal repository, created via Codex using the compromised access.

The libheif bug specifically was a heap buffer overflow with out-of-bounds read/write primitives — a classic, serious memory-safety vulnerability class. What made it exploitable in production despite a fix technically existing upstream is the more instructive detail: the upstream patch was never flagged as security-relevant and received no CVE, which meant it never triggered the standard distribution security-backport pipeline. The vulnerable versions (1.19.7 on Debian 12, 1.19.8 on Debian 13) stayed live in production because nothing in the normal patching workflow told anyone the fix mattered — a real, structural gap in how open-source security fixes propagate, not a mistake specific to OpenAI.

The part worth tracking closely: what changed between Opus 4.8 and Opus 5

This is the detail that makes the disclosure worth covering here rather than treating it as a routine security bulletin. The researchers report that Claude Opus 4.8 found the libheif vulnerability and built a partial exploit, but struggled across multiple sessions specifically in environments with ASLR (address space layout randomization) enabled — a standard OS-level defense that randomizes memory addresses to make heap-overflow exploits much harder to land reliably, since an attacker can't predict where their payload will actually end up in memory.

Claude Opus 5 launched the evening of July 24, 2026 — mid-investigation. The researchers started a new session, and it produced a working ARM64 exploit on a local Mac within roughly three hours, then ported that exploit to the x86-64 and jemalloc configuration Discourse actually runs. By 6:00 a.m. on July 25 they had confirmed local RCE through an image upload. To get Claude to actually attack a remote target — Opus initially refused to write an exploit against a host it wasn't confident it owned — the researchers ran it in an autonomous /goal loop against their own Discourse Cloud instance, proxied through a URL made to look like a CTF challenge host, since Opus had refused to write an exploit for a remote instance directly. When they checked back at 10:00 a.m., the agent had achieved RCE on that Discourse Cloud instance and demonstrated access by reading /etc/hosts; they then used the resulting exploit script to get RCE on OpenAI's actual instance. In the researchers' own words: "within hours of Opus 5's release, we gave it the same problem and it succeeded," where Opus 4.8 had not. Later in the same campaign, they report a further jump from Opus 5 to GPT-5.6 Sol, which they used to exploit a target blind — with no information beyond the fact that it was vulnerable. That's a concrete, dated, two-step before/after comparison across a genuinely hard technical task (bypassing ASLR to land a heap-overflow exploit, then generalizing to an unknown target) — a more grounded capability signal than most vendor benchmark claims, precisely because it's an independent third party's own operational account of using successive model versions back to back on the same unsolved problem.

Responsible disclosure, done carefully

It's worth being explicit that this is defensive security research, disclosed through the normal channels, not an active attack. Once the researchers had working access to a real employee account connected to OpenAI's GitHub organization, they deliberately limited what they did with it: rather than reading any sensitive internal code, they had Codex — using that same compromised access — create a single, harmless pull request (#1186742, redacted at OpenAI's request) in OpenAI's internal openai/openai monorepo, sufficient to prove the access was genuinely real without exploiting it further or exposing proprietary code. They reported both the libheif/Discourse issue and the OpenAI SSO flaw the same day. OpenAI confirmed a fix for the SSO issue in roughly 14 hours; Discourse acknowledged the report the following day, shipped a fix by Monday, and published a public advisory (GHSA-vhm9-85gw-x335) days later. As a defense-in-depth follow-up beyond just patching libheif, Discourse also began running external binaries like ImageMagick's magick command through a Linux landlock sandbox, and says it's migrating away from ImageMagick to libvips (which runs out-of-process) — a structural fix aimed at the next unknown image-library bug, not just this one.

The bounty itself is a useful, if slightly awkward, data point: OpenAI paid $6,500, specifically for the SSO-side finding — testing against the Discourse forum itself was outside OpenAI's bug bounty program scope at the time, even though the forum compromise was the actual entry point that made the SSO flaw reachable in the first place. That scoping gap is worth any organization running a bug bounty program noting directly: a vulnerability in infrastructure technically outside your program's stated scope can still be the load-bearing first step of an attack against something that is in scope.

The broader pattern: "HEIF Heist"

The researchers describe this OpenAI finding as one result from a longer, multi-month investigation they call "HEIF Heist" — tracing the same underlying libheif dependency across other major platforms, including Slack, Meta infrastructure, GitHub Enterprise, and JavaScript frameworks like Next.js, Astro, and Gatsby. Per their own account, the entire multi-month, three-person effort cost under $3,000 in AI token spend. Combined with their own stated conclusion — "security assumptions must catch up with attacker capabilities," and that work previously requiring "months of effort can now be compressed into days" — the economics here are the real story: a single unglamorous, unflagged upstream fix in one widely-embedded image-decoding library turned into a cross-platform research campaign that would have required a well-resourced team to pull off manually, now achievable by three people for the cost of a modest cloud bill.

What Hacker News actually pushed back on

The disclosure reached the front page of Hacker News (199 points at time of writing), and the discussion surfaced several substantive technical and ethical points worth folding in, rather than treating this purely as a capability-demo story.

The jailbreak-via-framing detail drew direct concern. Several commenters focused on exactly how the researchers got Claude to attack a target at all, given that Opus initially refused to write an exploit against a remote host it wasn't confident it owned. The researchers' own workaround — proxying their own Discourse instance through a URL styled to look like a CTF challenge host — was read by one commenter as a genuinely notable jailbreak technique in its own right: "there are other methods to bypass the guardrails to have it attack remote hosts... you just have to prove to the model that you control the host or that it's a valid target, and there are plenty of ways to fake that." Another commenter connected this directly to the earlier, separately reported OpenAI-model-hacked-Hugging-Face incident, arguing that heavy CTF-style training may be producing models "so goal-oriented, and so capable, that they will do almost anything if they are convinced it is justified — or if they are playing a 'game' where there is no goal but to win," with an explicit nod to WarGames.

The redacted SSO flaw frustrated several readers. The post explains the libheif RCE in detail but doesn't specify the exact mechanism of the SSO misconfiguration that turned forum access into ChatGPT/Codex account takeover — "the juicy part," as one commenter put it. Another speculated the root cause was a token audience-check failure: "why can an ID token for a separate client application be used to read and write to GitHub? that's the story here" — a common and often-overlooked class of OAuth/OIDC misconfiguration where an application accepts a token issued for a different client than the one presenting it. A third commenter noted this specific failure mode ("not checking the audience of a token") is common enough that "a lot of applications don't actually check it."

The $6,500 bounty was the single most argued-over detail in the thread. Reactions ranged from calling it "beyond pathetic for a near $1.2T company" to more grounded pushback from a regular HN security commenter that there's likely no real black market for a bug like this at all — server-side vulnerabilities are low-value to attackers precisely because vendors don't compete to buy them, and once patched, a server-side exploit is simply worthless, unlike, say, a leaked credential or stolen data that retains value after discovery. One reply reframed the number usefully: $6,500 is what OpenAI was willing to pay for a bug covering account takeover across any service a user had connected — "let that sink in" — a framing that shifts the conversation from "is this bounty too small" to "is this pricing model coherent at all" for a vulnerability class with this much reach.

The libheif attack surface itself drew informed criticism. One commenter with direct familiarity with the patched commit argued the deeper issue is that HEIF supports far more complex features (image overlays, rotation, cropping, alpha channels, thumbnails) than a typical web forum's image-upload use case actually needs, making it "a much, much larger attack surface than plain old school JPEG" — and suggested that services accepting user uploads should default to simpler formats, or handle exotic format conversion client-side, rather than exposing a complex native parser server-side at all. A related reply from a Discourse team member (posted directly in the thread) confirmed the landlock sandboxing and libvips migration mentioned above, and added a broader operational warning for self-hosters: "the rate of CVEs this year across all open source software is through the roof... you need to have some routines set up to update monthly if not weekly."

Honest limitations

• This account is sourced to the researchers' own disclosure, published on their own blog and X thread — a credible, detailed, dated technical account, but not independently audited by a third party.
• Detection is a real concern raised by the researchers themselves — they state they're "not aware of any company that detected the activity except Shopify," across a campaign spanning multiple major platforms.
• The Opus 4.8 vs. Opus 5 comparison is one team's operational account on one specific task, not a controlled benchmark — a real and useful data point, but not a generalized claim about exploit-development capability across all vulnerability classes.
• The bounty scoping gap (forum testing excluded, SSO finding paid) is specific to OpenAI's program terms at the time and may not generalize to how other bug bounty programs are scoped.

What this means for builders

Two separate, practical takeaways here, independent of each other. First, for anyone maintaining infrastructure with image-processing pipelines: an upstream security fix with no CVE and no security flag is a real, structural blind spot in how most organizations track what needs patching — worth auditing your own dependency update process for whether it actually catches unflagged fixes, not just CVE-tagged ones. Second, and more broadly relevant to explainx.ai's ongoing coverage of AI-assisted security work: the specific, dated Opus 4.8-to-Opus-5 capability jump on a genuinely hard exploit-development task (bypassing ASLR) is exactly the kind of concrete evidence Anthropic's own R&D automation and safety-pacing measurements are trying to track systematically — independent, real-world confirmation that this capability curve is moving fast enough that security assumptions built around "this kind of exploit takes a skilled human team weeks" need active revisiting, not a one-time reassessment.

Related on explainx.ai

• Agent skills as a security threat: explainx.ai verification
• MCP security: a complete guide
• Anthropic says Claude now "leads" 26% of its own AI R&D
• Boris Cherny's GPT-6 Astra prompt injection benchmark
• Claude org-wide skill and plugin publishing — the security angle
• What is an embedded evaluator? AI safety, explained
• Primary source: s1r1us's X thread · Hacktron AI — Hacking OpenAI
• Hacker News discussion: "Hacking OpenAI" (199 points, 54 comments) — search "Hacking OpenAI hacktron.ai" on news.ycombinator.com

This post is sourced to the researchers' own public disclosure (X thread and the full Hacktron AI blog post, published September 13, 2026), describing events between July 23-25, 2026 and a bounty awarded September 1, 2026, plus the subsequent Hacker News discussion. Technical details, the AI-capability comparison, and the disclosure timeline are the researchers' own account; commenter speculation (such as the token-audience theory for the SSO flaw) is explicitly unconfirmed. explainx.ai has not independently reproduced or audited the underlying exploit.