A Forum Image Bug Opened a Path Into OpenAI Employee Accounts
Researchers exploited a Discourse image bug and shared OpenAI SSO trust to access employee accounts and an internal code repository.
Text generated by artificial intelligence, published without human review. AI transparency
Illustrative image generated with AI
Three Hacktron researchers turned a flaw in Discourse’s image-processing stack into access to OpenAI employee accounts and an internal code repository. The security research combined memory-corruption exploitation, AI-assisted development, and an undisclosed weakness in OpenAI’s single sign-on architecture.
The initial target was OpenAI’s public help forum, which runs on Discourse. Specially crafted HEIC or HEIF files reached ImageMagick and its libheif decoder, allowing the researchers to compromise the forum server.
That foothold alone did not explain the full impact. Because the public forum shared a “Sign in with OpenAI” trust relationship with more sensitive services, the researchers could take over ChatGPT and Codex accounts belonging to OpenAI staff who were forum members. No action from those employees was required.
Hacktron stopped after creating one harmless pull request in an internal repository. The team said it did not read source code, merge changes, deploy anything, or access customer information.
A vulnerable decoder inside the Discourse image pipeline
The affected forum accepted uploads in HEIC and HEIF formats. Discourse sent those images to ImageMagick, which used libheif to decode their contents.
The vulnerable deployment ran libheif 1.19.7 in an image based on Debian 12. Its server environment used x86-64 and the jemalloc memory allocator, details that mattered when converting the underlying memory bug into a working exploit.
Public records do not describe the direct effect in exactly the same way. The issue, tracked as CVE-2026-32882, has been characterized as an out-of-bounds read that can crash a process or expose adjacent memory. Another account describes a heap buffer overflow capable of accessing data outside the intended region.
Discourse classified the resulting risk as remote code execution and assigned a severity score of 8.8 out of 10. Separately, verified vulnerability data assigns CVE-2026-32882 a CVSS 3.1 score of 7.1, with the vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H
These descriptions are not necessarily equivalent claims about a single primitive. Hacktron reportedly combined the libheif memory weaknesses with additional exploitation techniques. Memory disclosure helped defeat address space layout randomization, or ASLR, before the researchers established code execution.
The upstream correction was released in libheif 1.22.0 in May 2026, according to The Hacker News’ account of the research. However, that fix had not reached the Debian package embedded in the forum’s server image when it was examined in July.
This gap illustrates a recurring deployment problem: updating an application does not necessarily replace a vulnerable native library packaged inside its container or operating-system image.
Claude accelerated exploit development, but humans directed the work
Hacktron initially gave the exploitation problem to Anthropic Claude Opus 4.8. Across several sessions, the model could not produce a functional exploit once ASLR was enabled.
Anthropic released Claude Opus 5 on the evening of July 24. Using the same task in a new session, the researchers obtained a working exploit against a local Mac in about three hours, according to Security Affairs.
The model did not autonomously conduct the full operation. Human researchers defined the objective, built the testing environment, adapted the exploit to the server’s architecture and allocator, and supervised each stage.
There was also a safety-boundary issue. Opus 5 reportedly declined to attack a system it recognized as live. The researchers therefore reproduced the target conditions on cloud infrastructure they controlled and presented it as a capture-the-flag environment. On that system, the model achieved root-level access and demonstrated it by reading /etc/hosts.
The team then adapted the result to OpenAI’s real forum instance. The complete chain—from initial investigation to access to an internal repository—took less than 72 hours.
Hacktron’s broader “HEIF Heist” work took approximately two months, involved three researchers, and cost less than $3,000 in AI usage. OpenAI’s GPT-5.6 Sol was also used later in the project when the researchers began without prior knowledge of a target environment.
Claims about other affected technologies require qualification. Similar image-processing paths were examined in Slack, Meta products, GitHub Enterprise, Next.js, and Shopify-related infrastructure. A Next.js issue was confirmed through a Vercel advisory, while libheif maintainers confirmed working code execution for the issue associated with Meta. Code execution across every examined application has not been independently established.
Shared SSO transformed server access into identity compromise
After compromising the forum, the researchers used its OpenAI login relationship to access employee ChatGPT and Codex accounts. Staff members did not have to click a malicious link, open a file, or approve a prompt.
The key escalation point was therefore not confined to Discourse. Hacktron characterized it as a trust-boundary failure in OpenAI’s identity architecture: a lower-trust public service could confer access affecting higher-value employee resources.
OpenAI employees may connect services such as GitHub, Slack, and email to ChatGPT or Codex. Hacktron said the same account access could theoretically have extended into those integrations, although the team deliberately did not exercise those permissions.
To prove the consequence, the researchers used one employee’s Codex connection to submit a single pull request to an internal OpenAI repository. They reported that they:
- did not inspect the repository’s source code;
- did not merge the pull request;
- did not ship or deploy any modification;
- did not access customer data;
- did not enter connected GitHub, Slack, or email resources beyond what was needed for validation.
The research indicates that compromising another first-party or third-party service using the same OpenAI SSO relationship could potentially have produced a similar escalation. Discourse provided the entry point, but shared identity determined the blast radius.
OpenAI and Discourse closed separate parts of the chain
Hacktron disclosed its findings to both OpenAI and Discourse. OpenAI confirmed a fix approximately 14 hours after receiving the report.
On September 1, OpenAI paid the researchers a $6,500 bounty for the OpenAI-side finding. The payment did not cover testing against the Discourse-hosted community.openai.com environment, which OpenAI said was outside its bounty scope.
The technical details of OpenAI’s login flaw have not been publicly disclosed. Its remediation and bounty payment confirm the finding, but the organization has not described the account-takeover mechanism in enough detail for independent architectural analysis.
Discourse prepared its patch by the following Monday and added sandboxing around image processing. Hosted Discourse sites were reportedly updated. Fixed releases for self-managed installations are:
- Discourse 2026.7.0
- Discourse 2026.6.1
- Discourse 2026.5.2
- Discourse 2026.1.6
As of mid-September 2026, CVE-2026-32882 was not included in the U.S. government’s Known Exploited Vulnerabilities catalog. Consequently, there was no CISA KEV remediation deadline associated with it. Its absence does not establish that no unauthorized exploitation occurred.
No public indicators of compromise have been provided for either OpenAI’s environment or affected Discourse systems.
Defenders must address both parsing and identity exposure
Operators of self-hosted Discourse instances should install one of the fixed releases and rebuild deployments from a current image. Merely updating the web application may leave libheif 1.19.7 or another vulnerable package in the runtime environment.
The latest security release identified as of early September 2026 was libheif 1.23.4. Administrators should use that release or the patched package supplied by their operating-system distributor, then verify which library is actually loaded at runtime.
Where HEIC, HEIF, or AVIF support is unnecessary, disabling those formats removes the exposed decoding path. Image processors should also run in a sandbox with tightly restricted filesystem, network, and privilege access.
Monitoring should cover repeated image-processing crashes, unusual volumes of malformed uploads, unexpected child processes, and unexplained server-side execution. Shopify reportedly detected the research activity after thousands of test uploads repeatedly crashed its image processors.
Identity controls require separate attention. Public forums and support systems should not share unrestricted SSO trust with employee, administrative, or development services. Sensitive operations should require fresh authentication rather than accepting a session inherited through a lower-trust application.
Organizations should also inventory connected-service permissions across ChatGPT, Codex, GitHub, Slack, and email systems. Unnecessary integrations should be revoked, while remaining connections should receive only the minimum required privileges.
Patching the decoder closes the initial route. Restricting SSO trust limits what an attacker can reach if another public-facing service is compromised.
Sources
This article is an original reworking based on the sources below.
