Hacktron used Claude to hack OpenAI's forum, take over an employee's Codex, and open a PR in OpenAI's own repo

Executive Summary

Between 23 and 25 July 2026, a three-person security research team at Hacktron AI chained an unpatched decade-old-lineage memory-corruption bug in an image-processing library to a single sign-on flaw in OpenAI's own identity infrastructure, and ended up with working access to an OpenAI employee's ChatGPT and Codex accounts — accounts connected, in the researchers' own telling, to GitHub, Slack, Outlook, Gmail and Google Drive¹. To prove the access was real without reading anything sensitive, they had the compromised employee's Codex agent open a pull request in OpenAI's internal openai/openai monorepo¹². The whole path from first finding to repository access took under 72 hours¹.

The vulnerability itself was not exotic. OpenAI's community forum, community.openai.com, runs on Discourse, which uses the FastImage library to vet uploaded images — except FastImage doesn't support HEIC/HEIF files, so Discourse silently handed those over to ImageMagick, which in turn called the C library libheif to actually decode them¹. Hacktron found that a security fix in libheif had been made upstream a year earlier without being flagged as a security fix and without receiving a CVE — which meant Debian's packagers had no signal to backport it, and Discourse's Docker image, built on Debian 12, was still shipping the vulnerable version¹. The result, formally assigned CVE-2026-32882 by Discourse, is a CVSS 8.8 remote-code-execution bug triggerable by uploading a malformed image, requiring no authentication and no user interaction beyond the upload itself³.

What makes this a genuinely unusual story — and the reason it belongs in this publication's AI-and-security category rather than only its vulnerability-disclosure one — is how the researchers built the exploit. They started with Anthropic's Claude Opus 4.8 and got a working proof-of-concept with address-space layout randomization (ASLR) disabled, but the model "struggled across several sessions" to make it reliable against Discourse's default, ASLR-enabled configuration¹⁴. Anthropic released Claude Opus 5 on the evening of 24 July. The researchers gave the same unsolved problem to the new model, and it produced a working ARM64 exploit within three hours¹. They then set the model loose in what they describe as an autonomous "/goal loop" against their own cloud-hosted Discourse instance — but the model initially refused to attack what it correctly recognized as someone else's remote infrastructure, so the researchers proxied the target through a URL made to look like a CTF competition server to get it to proceed¹. By the next morning it had root-cause remote code execution confirmed against that instance, and the same generated exploit worked against OpenAI's actual forum¹.

OpenAI's own account of its bounty award draws a line the researchers' framing blurs: the company paid $6,500, explicitly stating that "testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program" and that the award "recognizes the OpenAI-side finding, not the actions against Discourse"¹. In plain terms, OpenAI paid for the identity/SSO flaw the researchers found, not for the live exploitation of its own forum that got them there — a scope distinction worth taking seriously given this publication's own position that unauthorized access, however well-intentioned, is not something to wave through uncritically.

Disclosure: This paper concerns a security finding involving Anthropic's Claude models. ThreatPaper has no financial or editorial relationship with Anthropic; this is reported using the same evidentiary standard applied to any other vendor.

Verification of Claims

1. Claim: Discourse had a critical, unauthenticated, no-interaction remote code execution vulnerability via image upload. → Verified → Discourse's own security advisory, GHSA-vhm9-85gw-x335 / CVE-2026-32882, rates the issue CVSS 3.1 8.8 (High), with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — network-exploitable, low complexity, low privileges required, no user interaction³. Credited reporter: "hacktronai-research"³. → Note the CVSS vector itself specifies PR:L (low privileges required, i.e., a logged-in forum account), which is a small but real precondition the Executive Summary's plain-language description should not be read to override — see this paper's own vector string above.

2. Claim: The researchers used Claude to hack Slack, Meta, Zoom, Shopify, GitHub Enterprise "and many more," beyond OpenAI. → Assessed, Not Confirmed → Hacktron's own blog post frames the wider "HEIF Heist" project as spanning these platforms and states adapting the exploit to each new target "usually took only one or two days," but provides the detailed timeline, exploit chain, account-takeover mechanism, and disclosure record only for OpenAI¹. VentureBeat, reporting independently, notes explicitly that beyond the researchers' own promotional video claiming they "hacked Slack, Meta, and many more," "the other companies are mentioned mainly as part of the wider HEIF Heist campaign rather than documented with the same level of technical detail or vendor confirmation"². No vendor besides OpenAI and Discourse has published a corresponding advisory as of this writing.

3. Claim: Shopify was the only company that detected the activity. → Assessed, Not Confirmed → Hacktron's own account: "We are not aware of any company that detected the activity except Shopify, even after thousands of images were sent and their image processors repeatedly crashed"¹. This is the researchers' own negative-detection claim across an unspecified number of targets over a two-month campaign, not something independently verified by any of the named companies.

4. Claim: OpenAI authorized the live exploitation of its Discourse-hosted forum as part of this research. → False → OpenAI's own comment, quoted in Hacktron's published disclosure timeline: testing against the Discourse-hosted community.openai.com "was explicitly excluded from our bug bounty program"¹. The $6,500 payment covered the SSO/identity finding on OpenAI's own side, not the RCE exploitation of the forum itself, which Hacktron separately reported to Discourse through HackerOne¹.

Timeline

Attack Anatomy

Reconnaissance and initial vulnerability discovery

Hacktron describes deliberately choosing not to attack the Discourse application directly — "not an easy target," per their own prior experience — and instead going after a dependency¹. On 23 July 2026 they began reviewing Discourse's image-upload pipeline and found that HEIC/HEIF files bypassed Discourse's normal FastImage validation, since FastImage doesn't support those formats, and were instead routed to ImageMagick's magick command, which invokes libheif to decode them¹. They ran an Opus 4.8 session against a copy of the Discourse Docker image and had it inspect the installed libheif package; the model identified that certain security fixes had not been backported¹.

Building the exploit

The underlying bug is a heap buffer overflow producing out-of-bounds read/write during HEIC decoding. The fixing commit had landed upstream in libheif the previous year without being documented as security-relevant and without a CVE assigned at the time — precisely the condition under which downstream distributions miss a fix, because there is no advisory to trigger a backport¹. Discourse's Docker image, built on Debian 12, shipped libheif 1.19.7; Debian 13 was still shipping the equally vulnerable 1.19.8 as of the researchers' testing. Debian issued its own security update (DSA-6417-1) for the underlying issue on 8 August 2026, after the OpenAI/Discourse disclosure¹.

On 24 July, using Opus 4.8, the team got a working exploit against a target with ASLR disabled, then spent multiple further sessions failing to make it reliable with ASLR enabled — the default, realistic configuration¹. Anthropic released Opus 5 that evening. Given the identical unsolved problem, it produced a working ARM64 exploit against a local machine within three hours, and was then used to port that exploit to the x86-64/jemalloc memory-allocator environment Discourse actually runs¹.

From local proof-of-concept to a live target

By 6:00am on 25 July the team had confirmed local RCE via image upload. They then set Claude working autonomously in what they call a "/goal loop" against their own Discourse Cloud instance — and record that the model initially refused to write an exploit against what it recognized as a remote target it didn't control. The researchers routed that target through a URL, rce.ee/ctf-forum, styled to resemble a capture-the-flag competition server, and the model proceeded¹. By 10:00am the agent had achieved RCE against that (still researcher-owned) Discourse Cloud instance, confirmed by reading /etc/hosts. The same generated exploit script was then used to obtain RCE on OpenAI's actual production forum instance¹.

Escalation: forum to employee identity

OpenAI's forum supports "Sign in with OpenAI" via auth.openai.com. Hacktron had hypothesized before finding the RCE that compromising the forum could pivot into broader OpenAI services through that identity flow, and having confirmed a "no-interaction account takeover" path for ChatGPT/Codex accounts belonging to forum members, they reported the finding and then, to demonstrate impact, took over one OpenAI employee's account¹. That employee's Codex environment was connected to OpenAI's GitHub organization; the researchers instructed Codex to open a pull request in the openai/openai monorepo rather than reading any repository content, and then stopped testing¹². Both VentureBeat and Hacktron are explicit that the account-takeover path was an OpenAI-side identity/SSO issue, not a Discourse vulnerability — the forum compromise was the entry point, not the boundary that failed¹².

Threat Actor Profile

This section is unusual for this publication: the "actor" is an authorized (in significant part) security research team, not a hostile one, and this paper uses the profile format to document capability and process rather than intent.

• Name: Hacktron AI — Harsh Jaiswal (lead), Mohan Pedhapati, Rahul Maini¹.
• Motivation: Bug-bounty research and building a public research record ("HEIF Heist") demonstrating AI-accelerated vulnerability discovery across frontier AI companies and widely used software¹.
• Sophistication: High in vulnerability research (identifying an undocumented, un-CVE'd upstream fix and tracing it through Debian's packaging gap); the exploit-development labor itself was substantially performed by Claude Opus 4.8 and Opus 5 under human direction, which the researchers present as their central finding¹².
• Cost and speed: The full HEIF Heist project — multiple companies, two months — cost the team under $3,000 in AI API tokens; the OpenAI-specific chain from first finding to repository access took under 72 hours¹.
• Scope discipline: Reported and coordinated with OpenAI (Bugcrowd) and Discourse (HackerOne) separately; stopped testing after the proof-of-concept PR; did not read or exfiltrate OpenAI source code, per their own account, which has not been independently disputed by OpenAI¹.
• Scope question: OpenAI's own statement draws a boundary the researchers' actions crossed — live exploitation of the Discourse-hosted forum was outside the bounty program's stated scope, even though the researchers had separately reported the underlying Discourse bug to Discourse itself through a different program¹.

Technical Indicators

cve: "CVE-2026-32882"
advisory: "GHSA-vhm9-85gw-x335 (discourse/discourse)"
cvss_v3_1: "8.8 (High) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
component: "libheif (HEIC/HEIF image decoder), invoked by ImageMagick"
vulnerable_versions_confirmed:
  - "libheif 1.19.7 (Debian 12, Discourse Docker base image at time of finding)"
  - "libheif 1.19.8 (Debian 13, still vulnerable at time of finding)"
patched_discourse_versions:
  - "2026.7.0"
  - "2026.6.1"
  - "2026.5.2"
  - "2026.1.6"
patched_libheif:
  - "Fixed upstream the prior year, undocumented as a security fix, no CVE assigned at the time"
  - "Current secure release as of 14 Sep 2026: v1.23.4 (v1.23.2 superseded)"
distro_advisory:
  - "Debian DSA-6417-1, published 8 August 2026"
demonstration_infrastructure:
  - "rce.ee/ctf-forum — proxy used by researchers to disguise their own cloud Discourse instance as a CTF target"
proof_of_concept:
  - "PR #1186742 opened via a compromised OpenAI employee's Codex session in the openai/openai internal monorepo (link redacted at OpenAI's request)"
bounty_paid: "$6,500 (OpenAI, via Bugcrowd, for the SSO/identity finding only)"
network_iocs: none — this was authorized/semi-authorized security research, not a malicious campaign

Legal and Regulatory Response

Disclosure timeline (per Hacktron's published account, corroborated where noted): RCE and admin access to the Discourse environment obtained 25 July, 05:00–06:00 UTC; Bugcrowd report submitted to OpenAI 08:00–10:00 UTC same day; employee account access and proof-of-concept PR 13:30–15:30 UTC, testing ceased ~15:30 UTC; OpenAI confirmed its side fixed at 22:49:45 UTC, roughly 14 hours after submission; Discourse separately notified via HackerOne the same day, replied the next day (Sunday), had a fix ready by Monday, 27 July, and published its advisory 28 July; OpenAI paid the $6,500 bounty and marked the report resolved 1 September 2026¹.

Vendor responses. Discourse independently confirmed and published a fix and CVSS score for the underlying vulnerability³. OpenAI confirmed and fixed its SSO-side issue and paid a bounty, while stating that the live exploitation of its Discourse-hosted forum fell outside the program's scope¹. Neither VentureBeat nor this paper's research located a standalone public statement from OpenAI describing the incident in its own words; the Wall Street Journal independently reported the employee account compromise and repository access, per VentureBeat's account of that reporting².

No known regulatory or law-enforcement action. This was bug-bounty-program-mediated disclosure, not a reported crime.

Impact Assessment

• Vulnerability class and severity: Confirmed, CVE-2026-32882, CVSS 8.8³.
• Access achieved: Confirmed by the researchers' own published PR evidence and VentureBeat's independent corroboration — RCE on OpenAI's forum, takeover of at least one OpenAI employee's ChatGPT/Codex account, a proof-of-concept commit opened in OpenAI's internal monorepo¹².
• Source code or sensitive data actually read or exfiltrated: Confirmed none, per the researchers' account, unchallenged by OpenAI as of this writing¹.
• Time from vulnerability discovery to repository access: Confirmed, under 72 hours¹.
• Cost to develop: Reported, under $3,000 across the full two-month, multi-target research campaign¹.
• Scope of the broader "HEIF Heist" campaign (Slack, Meta, Zoom, Shopify, GitHub Enterprise, etc.): Assessed, not confirmed — asserted by the researchers, not documented to the same standard as the OpenAI case, not confirmed by any named company¹².
• Bounty paid: Confirmed, $6,500, explicitly scoped to the OpenAI-side finding only¹.

Lessons and Defensive Recommendations

For SOC and AppSec teams

• Any file-parsing library reachable from untrusted user uploads is a live attack surface regardless of how mundane it seems — image decoding, in this case. Audit what your upload pipelines actually hand off to which underlying decoder when your primary validation library doesn't support a format, rather than assuming an unsupported format is simply rejected.
• A security fix without a CVE and without being flagged as security-relevant in its own commit message is a real, documented way fixes fail to propagate through distribution packaging. Don't treat "no CVE" as "not a security issue" when reviewing dependency changelogs for anything processing untrusted input.

For identity and platform teams

• The actual security boundary that failed here was OpenAI's SSO trusting a session established on a third-party-hosted forum as equivalent to a first-party authentication event. Federated identity that grants access to high-privilege internal tools (Codex connected to your GitHub org) needs to treat every upstream identity provider — including your own community forum — as part of your trust boundary, audited to the same standard as the tools it unlocks.
• Connector sprawl multiplies blast radius. An AI agent account with live connections to GitHub, Slack, email and document stores is, functionally, a privileged service account and should be provisioned, scoped and monitored as one — not as a convenience feature bolted onto individual employee accounts.

For organizations running Discourse or anything using libheif

• If self-hosting Discourse: rebuild now (git pull then ./launcher rebuild app) rather than relying on a web-interface update, which may not replace the underlying vulnerable image¹.
• Any application accepting .heic/.heif/.avif uploads should update to libheif v1.23.4 or later and verify the fix wasn't lost to an un-flagged upstream commit during packaging¹.

For AI safety and red-team programs

• The model's initial refusal to attack a remote target it did not recognize as researcher-owned, and the researchers' subsequent use of a deceptive CTF-styled proxy URL to get past that refusal, is itself a legitimate, separately noteworthy finding: a safety behavior that depended on contextual framing the researchers were able to relabel. Organizations building or red-teaming autonomous coding/security agents should treat "does the target look authorized" as a gameable signal, not a reliable control, and should evaluate refusal robustness against exactly this kind of relabeling rather than only against direct requests.
• The comparison between Opus 4.8 (failed reliably against ASLR) and Opus 5 (succeeded within hours) is a single, small, non-benchmarked data point from an interested party publishing its own capability-marketing research, not a rigorous capability evaluation — worth taking seriously as a directional signal about model capability trajectory, not as a calibrated measurement.

Sources