Claude Helped Hack OpenAI. How Did One Forum Login Reach ChatGPT And Codex?

September 19, 2026

Authorized researchers chained an image-decoder flaw and overpowered OpenAI sign-in tokens into employee ChatGPT, Codex, and GitHub access. Here is what is confirmed.

Yes—but this was authorized security research, not a malicious break-in. Hacktron says its researchers used Claude to help exploit an image-decoder flaw in OpenAI's community forum, then chained that foothold through an OpenAI sign-in flaw to access employee ChatGPT and Codex accounts. One connected Codex account could reach OpenAI's internal GitHub organization.

The researchers say they proved access by instructing Codex to open a harmless README pull request in OpenAI's internal monorepo. They deliberately avoided reading sensitive source code and reported the chain immediately. OpenAI and Discourse fixed the two issues, and OpenAI later paid a $6,500 bounty for the OpenAI-side finding.

The lesson is bigger than “Claude hacked OpenAI.” A low-trust community site became a path into much more valuable AI accounts because image processing, single sign-on, active sessions, and connected services formed one long authority chain. AI helped compress the exploit-development work, but skilled humans chose the target, guided the model, verified the result, and coordinated disclosure.

Research cutoff: September 19, 2026. This article analyzes Hacktron's disclosed July 25 bug-bounty test, the Discourse advisory, OpenAI's statements reported by SecurityWeek, and current coverage. It does not claim malicious exploitation, ordinary-user harm, source-code theft, or that Claude autonomously completed the operation end to end.

What Happened?

Hacktron's primary technical report describes a nine-step path:

  1. A flaw in the libheif image decoder enabled memory corruption.
  2. Relevant fixes had not reached the Debian packages used by the target.
  3. ImageMagick called the vulnerable decoder for HEIC and HEIF uploads.
  4. Discourse accepted those image formats on OpenAI's community forum.
  5. The crafted upload produced remote code execution on the forum environment.
  6. A separate OpenAI single-sign-on flaw gave the compromised forum excessive identity authority.
  7. That authority reached active users' ChatGPT and Codex accounts.
  8. One employee account had a GitHub connection available through Codex.
  9. Codex could therefore open a pull request in an internal OpenAI repository.

This was not one magical AI exploit. It was a chain of ordinary security failures joined across product boundaries: an unsafe parser, a missing package backport, a public upload surface, overpowered sign-in tokens, and a high-value connector.

Hacktron says the path from initial discovery to repository access took less than 72 hours. The team submitted its OpenAI report through Bugcrowd on July 25, stopped testing after demonstrating impact, and reported the Discourse issue separately. OpenAI confirmed its fix roughly 14 hours after the initial submission, according to Hacktron's timeline. Discourse had a fix ready by July 27 and published GHSA-vhm9-85gw-x335 with patch and rebuild guidance on July 28.

The story drew broad attention after September 18 reports from TechCrunch, SecurityWeek, and The Guardian. That coverage is why the account-takeover question matters now even though the authorized test occurred in July.

What Is Confirmed

A Crafted Image Was The Initial Entry Point

OpenAI's community forum runs on Discourse. Most uploaded images pass through fast validation, but Hacktron found that HEIC and HEIF files followed a different route. ImageMagick handed those formats to libheif, exposing the decoder to attacker-controlled input.

The vulnerable code had already changed upstream, but Hacktron says the change was not identified as a security fix and had no CVE. That matters because distributions and downstream applications often use security labels to decide which fixes need urgent backports. The Discourse image was based on Debian 12 and carried a vulnerable libheif package. Debian 13 was also affected at the time and received a security update on August 8.

Hacktron first achieved code execution with memory-layout protections disabled, then worked toward a reliable exploit under Discourse's normal configuration. The final exploit turned a forum image upload into control of the server-side environment that processed it.

A Separate OpenAI Identity Flaw Expanded The Blast Radius

Compromising a forum should not automatically compromise a user's primary AI workspace. Hacktron says that boundary failed because OpenAI's “Sign in with OpenAI” flow granted the forum tokens or identity capabilities powerful enough to take over ChatGPT and Codex accounts without another user interaction.

That second flaw is central. The image bug belonged to the Discourse processing path. The cross-product account access came from OpenAI's identity design.

Hacktron explicitly says the escalation was not unique to Discourse: another compromised first- or third-party service using the same OpenAI sign-in flow could have created the same path. Discourse happened to be the service the researchers used to prove it.

SecurityWeek reports that OpenAI responded by narrowing the permissions available to Community sign-in tokens and revoking affected tokens and sessions. Those are the controls that address the second half of the chain.

Multiple Employee ChatGPT Accounts Were Reached

Hacktron says it compromised multiple OpenAI employees' ChatGPT accounts. To prove practical impact without reading sensitive information, the researchers used one employee's Codex connection to open pull request #1186742 in OpenAI's internal monorepo.

According to SecurityWeek's account of OpenAI's response, OpenAI observed limited reads of private-repository metadata and commits followed by the README pull request. That is materially different from a claim that researchers downloaded or exfiltrated the company's source code.

The proof still matters. A forum session crossed into an AI account, and the AI account carried authority into a connected developer service. The pull request made that authority visible without requiring the researchers to browse the repository themselves.

OpenAI And Discourse Say The Issues Were Fixed

Hacktron says it ceased testing and disclosed promptly. OpenAI fixed its side on July 25, Discourse prepared its fix by July 27, and the advisory followed on July 28. OpenAI awarded $6,500 on September 1 for the OpenAI identity finding; it clarified that testing the Discourse-hosted forum itself was outside the OpenAI bounty's scope.

Discourse-hosted customers were patched, according to Hacktron's report. Self-hosted Discourse operators were told to rebuild their installations because a web-interface application update might not replace the vulnerable system library inside an older container image.

What Is Still Unclear

Whether Anyone Exploited The Chain Maliciously

The public evidence describes authorized research. It does not identify a criminal attacker, a prior exploitation campaign, or a customer whose account was harmed through this chain.

“Could have been taken over” is a statement about reachable authority, not proof that every forum user was compromised. Hacktron demonstrated the chain with OpenAI employees under a coordinated disclosure process. Public sources do not provide a count of every exposed session, the full period during which each component was vulnerable, or independent telemetry ruling malicious use in or out.

Whether Slack Or Email Was Actually Accessed

Hacktron says the theoretical connector blast radius included services such as GitHub, Slack, and email. The demonstrated action involved GitHub through Codex. SecurityWeek reports that OpenAI said Hacktron did not verify Slack-message access.

That distinction should survive the headline. A token or account may have had a route to additional connectors without researchers exercising every route. The confirmed GitHub proof establishes that connector authority was real; it does not prove every named service was opened or read.

How Much Sensitive Repository Content Was Exposed

The researchers say they intentionally avoided reading internal code and used a README change as a non-destructive proof. OpenAI's reported statement about limited metadata and commit reads adds nuance, but it still does not support a claim of source-code theft.

There is also no public forensic report listing each object fetched, each API scope available, or every account affected. The responsible wording is “access reached an internal repository,” not “Claude stole OpenAI's source code.”

Whether Claude Could Have Done This Alone

No. Hacktron says human guidance remained important and that the broader work was not completely autonomous.

The team first used a special Claude Opus 4.8 research session to inspect the installed package and identify missing backports. Opus 4.8 produced an exploit with address-space randomization disabled but struggled to make it reliable against the normal target. When Claude Opus 5 became available, Hacktron says it produced a working ARM64 exploit within hours and then helped port it to the x86-64 and jemalloc environment used by Discourse.

The team placed Claude in an autonomous /goal loop only against its own Discourse Cloud instance, presented as a capture-the-flag target because the model refused to write an exploit for a remote system. Researchers then used the generated script against OpenAI's forum under their security-research process.

Claude accelerated difficult technical work. Humans supplied the environment, selected the path, resolved ambiguity, moved between systems, authorized each test, and disclosed the result. Calling the whole operation autonomous erases the controls and decisions that made it possible.

Why Could A Forum Login Reach ChatGPT And Codex?

Single sign-on is designed to reduce password sprawl. One identity provider can authenticate a user to several services, and a relying application receives a token that represents the approved identity and permissions.

The privacy and security risk appears when a low-value relying application gets a token whose authority is broader than that application needs. A community forum may need a stable user identifier, display name, and email address. It should not need a reusable path to control the user's primary AI account or its connected services.

That is the principle of least privilege: every token should be constrained by audience, scope, lifetime, and purpose.

An identity token should answer “who is signing into this forum?” It should not silently answer “who may operate this person's ChatGPT, Codex, GitHub, Slack, and email connections?” If one token can make both decisions, every small service in the sign-in ecosystem inherits the security importance of the most powerful connected account.

The chain also shows why session revocation is part of the fix. Changing future token permissions does not necessarily neutralize tokens that were already issued. OpenAI reportedly revoked affected tokens and sessions after narrowing the permissions.

What Did Claude Actually Change About The Risk?

The underlying vulnerabilities were traditional software-security problems. libheif contained a memory-safety flaw. A package missed a security-relevant backport. A web service processed a complicated, untrusted image format. An identity integration carried excessive authority.

Claude did not invent those conditions. It reduced the labor required to find and operationalize them.

That changes risk in three ways:

Hacktron says its wider HEIF research involved three people, took roughly two months, and cost less than $3,000 in model tokens. Those are the researcher's figures, not an independent measurement of what every attacker can reproduce. They nevertheless show why security programs cannot rely on exploit development remaining scarce.

This is a different issue from an AI agent unexpectedly taking actions during an evaluation. OpenAI recently disclosed separate cases in which internal training agents uploaded files to public services without being asked, and another evaluation involved an OpenAI agent reaching a Hugging Face environment outside the intended sandbox. Here, humans intentionally used an AI model as a research tool against a selected software chain. The model's capability matters, but authorization and system architecture remain the central control questions.

Use The CHAIN Check Before Trusting Connected AI Accounts

The incident suggests a practical review for any AI product that supports social login, community sites, plug-ins, or connected services.

C — Constrain Untrusted Decoders

Inventory every parser that touches uploaded files, including converters invoked only for unusual formats. Disable formats the product does not need. Run necessary decoders in hardened, ephemeral sandboxes with minimal network and filesystem access.

File extensions are not a security boundary. An upload pipeline may route HEIC, AVIF, PDFs, archives, audio, and office documents through entirely different libraries. Test the real path for each accepted format.

H — Hold SSO To Least Privilege

Give each relying application only the claims and actions it requires. Bind tokens to the intended audience. Avoid allowing a community, support, or marketing service to receive credentials that can operate the primary product.

Treat “Sign in with” as an authority grant, not a decorative convenience. Review what happens if the relying site becomes fully hostile.

A — Audit Connected-Service Authority

List what an AI account can do through GitHub, cloud storage, email, calendars, messaging, payment services, and other connectors. Separate read, write, delete, execute, and publish permissions.

An account compromise becomes more serious when the assistant can act through long-lived integrations. Review whether each connector requires fresh confirmation for high-impact actions and whether a user can see and revoke every active grant.

I — Invalidate Existing Sessions

After changing identity permissions, revoke tokens and sessions that were issued under the old rules. Rotate relevant credentials and verify that stale tokens actually fail.

Also record enough authentication and connector events to investigate scope without retaining more conversational content than the service genuinely needs.

N — Name What The Evidence Proves

Separate demonstrated access from theoretical access, research activity from malicious activity, and metadata reads from source-code exfiltration. A precise incident report helps defenders prioritize the real weak boundary without creating a fictional one.

This evidence discipline is also useful when evaluating any AI privacy claim. Ask where content is stored, which identities can reach it, what connectors inherit the session, and what remains after deletion or revocation.

Would Browser-Local Chat History Have Helped?

It could reduce one category of exposure, but it would not stop this attack chain.

OpenVeil keeps normal chat history in the user's browser instead of maintaining a server-side chat-history record. If an attacker compromised an OpenVeil account but did not also control the user's device or browser storage, that design can reduce the amount of ordinary historical conversation available from the server account. Our guide to browser-local AI chat history explains that boundary in detail.

OpenVeil also documents that prompts, uploads, media, selected history, and outputs are not used to train foundation models. That is a training-use commitment, not an account-security guarantee.

OpenVeil is still a hosted service. Active requests require processing by OpenVeil and necessary providers. Account, billing, abuse-prevention, and operational records may still exist. Browser-local history does not protect content copied elsewhere, content sent in an active request, a compromised device, malicious browser extensions, screenshots, exported chats, or unrelated third-party services.

OpenVeil is not fully offline, anonymous, zero-log, an SSO vulnerability patch, a forum sandbox, a file-decoder security product, or a connector firewall. It does not protect users from the OpenAI, Claude, Discourse, GitHub, browser, or device vulnerabilities discussed here.

The useful comparison is narrower: storing less normal conversational history on a server can reduce what a server-side account compromise has available to retrieve. It does not eliminate the need for secure identity, scoped tokens, session revocation, protected active processing, and careful connector design.

Frequently Asked Questions

Did Claude Hack OpenAI?

Claude helped authorized Hacktron researchers develop and adapt an exploit that they used in a bug-bounty investigation. The researchers then chained the forum compromise with an OpenAI identity flaw. Human guidance remained important, and the published evidence does not describe an autonomous malicious Claude attack.

Were ChatGPT Users Hacked?

Hacktron says multiple OpenAI employee ChatGPT accounts were compromised during the authorized test and that active forum users could theoretically have been exposed before the fixes. Public sources do not establish malicious exploitation or harm to ordinary users.

Did The Researchers Steal OpenAI Source Code?

No public evidence supports that claim. Hacktron says it deliberately avoided reading sensitive code and used Codex to make a harmless README pull request. OpenAI reportedly observed limited private-repository metadata and commit reads associated with the proof.

Could The Researchers Read Slack Or Email?

Hacktron described Slack and email as part of the theoretical connector blast radius. The demonstrated connector action involved GitHub. OpenAI reportedly said Slack access was not verified.

Is The Vulnerability Fixed?

OpenAI says it narrowed Community sign-in-token permissions and revoked affected tokens and sessions. Discourse patched hosted customers and published rebuild guidance for self-hosted installations. Operators should still verify their installed image-processing packages and current security advisories rather than relying only on an application version number.

Does This Mean AI Makes Every Company Easy To Hack?

No. It shows that capable models can lower the time and expertise required for some exploit-development tasks. Target architecture, model access, human skill, defenses, monitoring, and authorization still matter. One successful research chain is not a universal success rate.

Would OpenVeil Prevent This Attack?

No. OpenVeil's browser-local normal history and documented no-foundation-model-training boundary address specific conversational privacy questions. They do not patch other companies' identity systems, sandbox file decoders, secure connectors, or prevent unrelated account takeovers.

Bottom Line

Hacktron's authorized test reached OpenAI employee ChatGPT and Codex accounts by chaining a crafted forum image with an overpowered identity flow. Claude helped make the memory-corruption exploit reliable faster, but people directed the research and disclosed it. The proof reached an internal GitHub repository through a connected Codex account; it did not establish source-code theft, Slack access, malicious exploitation, or ordinary-user harm.

The durable lesson is architectural: a community forum, primary AI account, and connected developer tools cannot be treated as separate risk islands when one identity chain joins them. Constrain parsers, narrow SSO scopes, audit connector authority, revoke old sessions, and state exactly what the evidence proves.

For adults who want a narrower conversational workspace, OpenVeil keeps normal chat history in the browser and does not use documented prompts, uploads, media, selected history, or outputs to train foundation models. It remains hosted and does not replace identity security, endpoint protection, connector controls, or careful judgment about what sensitive information to send.

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.