A security research exercise by Hacktron AI demonstrated how a vulnerability in a public facing application can become significantly more serious when it intersects with an organization’s identity infrastructure. The researchers began with OpenAI’s public community forum, where image uploads exposed a vulnerable image processing path involving the libheif library. They then investigated the authentication architecture surrounding the forum and identified an authorization boundary that could extend access into other OpenAI services.
The research also demonstrated how AI coding models can accelerate complex vulnerability research. Hacktron AI used Anthropic’s Claude models during the investigation, including work related to understanding and developing a reliable exploit for the image processing vulnerability. The important security issue, however, was not the use of AI by itself. The larger concern was the combination of a public application, a native parser vulnerability and insufficient isolation between identity contexts.
After gaining access to the forum environment, the researchers demonstrated access to employee ChatGPT and Codex sessions. They subsequently used a compromised Codex session to create a pull request in OpenAI’s private openai/openai repository. The pull request served as a proof of impact rather than an attempt to extract proprietary source code or model weights. The findings were disclosed through the appropriate security channels, and OpenAI subsequently addressed the reported identity issue.
The Anatomy of the Attack Chain
The attack chain is best understood as a sequence of trust boundary failures rather than as a single vulnerability. A public forum provided the initial attack surface. Image processing exposed native code to untrusted input. Access to the forum environment then provided an opportunity to examine the associated authentication context. From there, the researchers demonstrated that identity permissions could extend into employee services and ultimately into internal developer infrastructure.
Public forum → image processing → libheif vulnerability → server access → identity boundary weakness → employee ChatGPT and Codex sessions → internal repository proof of access
The Anatomy of the Attack Chain
How a public-facing image-processing vulnerability was combined with an identity-boundary weakness to demonstrate access to internal developer tooling.
OpenAI Community Forum
Researchers examined community.openai.com,
a public-facing forum using the Discourse platform. The
application accepted image uploads and relied on native
image-processing components.
HEIF Processing and libheif
Discourse’s image-processing path could reach a vulnerable
version of libheif. The underlying vulnerability
was tracked as CVE-2026-32882 and was later
associated with a Discourse remote-code-execution advisory.
HEIF upload → image processing → vulnerable native library
Claude Assisted Exploit Research
Hacktron researchers reported using Anthropic’s Claude models during their authorized security research. The model assisted with analysis and exploit-development work against the vulnerable image-processing environment.
SSO and Token Scope Weakness
After gaining access to the forum environment, the researchers investigated OpenAI’s authentication architecture. According to reporting on the research, authentication tokens could cross service boundaries and provide access to additional OpenAI services.
Public application access → identity boundary → downstream services
ChatGPT and Codex Sessions
The researchers reported that the authentication weakness allowed access to employee ChatGPT and Codex sessions. The significance of the chain came from the services and integrations available through those authenticated environments.
Internal Repository Pull Request
The researchers used the compromised development environment
to create a pull request in OpenAI’s private
openai/openai repository. The action was used
as a proof of access. Public reporting indicates that testing
stopped after demonstrating the impact.
Who Discovered the OpenAI Attack Chain?
The research was conducted by three Hacktron AI researchers: Harsh Jaiswal, Mohan Sri Rama Krishna Pedhapati and Rahul Maini. Their work sits within Hacktron AI’s broader security research around image processing vulnerabilities and AI assisted vulnerability discovery.
Harsh Jaiswal
Harsh Jaiswal is a security researcher associated with Hacktron AI and has publicly documented vulnerability research. His LinkedIn profile provides his professional background and security research history.
Mohan Sri Rama Krishna Pedhapati
Mohan Sri Rama Krishna Pedhapati is the co founder and CTO of Hacktron AI. His LinkedIn profile identifies his professional background and previous security research.
Rahul Maini
Rahul Maini is a security researcher associated with Hacktron AI. His LinkedIn profile provides his professional background and security research work.
How the Attack Chain Worked
The significance of the research lies in the way several otherwise separate security boundaries were connected. The initial issue was a vulnerability in software that processed untrusted image files. On its own, that is a conventional application security problem. The risk increased because the affected application was connected to an identity system that could provide access to higher value services.
This is a familiar pattern in mature security programs. Attackers rarely need a single catastrophic vulnerability when several smaller trust failures can be chained together. Public applications, authentication providers, developer platforms and cloud services increasingly operate as one connected environment. A weakness at one boundary can therefore have consequences well beyond the system where it was originally discovered.
1. OpenAI Community Forum
The researchers began by examining community.openai.com, OpenAI’s public community forum, which uses the open source Discourse platform. The forum accepted image uploads and therefore exposed an image processing pipeline to content supplied by external users. That made the image parsing layer an interesting security boundary because image formats such as HEIF require relatively complex native libraries to decode and transform their contents.
From a defensive perspective, this is an important distinction. An upload feature does not have to expose an operating system command directly to become a meaningful attack surface. If the server passes attacker controlled content into a native parser, a memory safety vulnerability in that parser can potentially cross from application data into server side execution.
2. The libheif Vulnerability
The research involved libheif, a library used to process HEIF and related image formats. The underlying vulnerability was assigned CVE 2026 32882. Public vulnerability records describe the issue as an out of bounds read. Discourse subsequently published security advisory GHSA vhm9 85gw x335, which describes a remote code execution condition involving malformed HEIF files processed through the application.
That distinction is important when describing the incident. CVE 2026 32882 should not simply be labelled as a heap buffer overflow or treated as an RCE vulnerability in isolation. The security impact arose from the way the vulnerable library was exposed through the Discourse image processing pipeline. For a technical audience, separating the underlying library defect from the application level attack path makes the analysis substantially more accurate.
3. Claude Assisted the Security Research
One of the more notable aspects of the research was the use of Anthropic’s Claude models during vulnerability analysis and exploit development. Public reporting describes the researchers using Claude to assist with the technical work required to turn a difficult memory corruption problem into a reliable result in the target environment.
That does not mean Claude independently attacked OpenAI. The work remained under the control of human security researchers operating within an authorized testing process. What the research demonstrates is the increasing ability of coding models to assist with tasks that historically required significant specialist time, particularly debugging, reasoning about program behaviour and adapting research to unfamiliar environments. For defenders, that means assumptions about the time and expertise required to operationalize complex vulnerabilities need to be reconsidered.
4. The Identity Boundary
Once the researchers obtained access to the forum environment, the investigation moved from application security into identity security. The forum was connected to OpenAI’s authentication infrastructure, creating a potential relationship between a public application and services used by employees.
According to reporting about the research, the authentication design allowed tokens associated with the community environment to cross service boundaries. In practical security terms, the issue was not simply that a token existed. The problem was that the authorization context attached to that token was broader than it should have been. Strong identity architecture requires services to validate the intended audience, permissions and context of every authentication token rather than treating possession of a valid token as sufficient proof of authorization.
5. Employee ChatGPT and Codex Sessions
The researchers demonstrated that the identity weakness could provide access to employee ChatGPT and Codex sessions. This was the point at which the original image processing vulnerability became an enterprise identity problem.
The security significance comes from the integrations available to authenticated developer environments. A compromised session does not necessarily stop at the application where authentication occurred. If the account has access to development systems, repositories or automation platforms, those downstream connections can extend the impact considerably. This is why identity security, application security and software supply chain security increasingly need to be assessed together rather than as isolated disciplines.
6. Internal Repository Proof of Access
The final stage of the research involved OpenAI’s private openai/openai repository. Rather than attempting to extract source code or model weights, the researchers used the compromised Codex environment to create a pull request as evidence that the authenticated session had reached an internal development resource.
That distinction matters when reporting the incident. Demonstrating write access to a private repository is significant, but it is not the same as claiming that an entire repository was downloaded or that proprietary model weights were obtained. The researchers stopped after demonstrating the impact and proceeded with coordinated disclosure.
The Complete Attack Chain
The research can therefore be summarized as a sequence of connected trust boundaries:
Public community forum
The initial attack surface was a public Discourse application.
Image processing
User supplied image content was processed by native image libraries.
libheif vulnerability
A memory safety vulnerability in the image processing stack created the opportunity for server side compromise.
Forum environment
The researchers demonstrated code execution within the affected environment.
Identity infrastructure
The compromised environment provided an opportunity to examine the authentication context associated with the service.
Employee services
A weakness in authorization boundaries allowed access to employee ChatGPT and Codex sessions.
Developer infrastructure
The authenticated Codex environment was connected to internal development resources.
Repository proof
The researchers created a pull request in the private repository to demonstrate the resulting access.
This sequence is more important than any individual component. It shows how a vulnerability that initially appears to belong to an image processing stack can ultimately become an identity and developer infrastructure problem.
Timeline
The research was conducted in July 2026, with the researchers demonstrating access to employee ChatGPT and Codex sessions and subsequently creating a test pull request in the private repository. The findings were then reported through coordinated disclosure channels.
Discourse published its security advisory for the HEIF image processing issue on July 28, 2026. The research became publicly discussed in September 2026 through Hacktron AI and subsequent media coverage.
Discourse and libheif Remediation
Discourse published GHSA vhm9 85gw x335 and provided patched releases for affected versions. Debian also published a security advisory covering libheif vulnerabilities, including CVE 2026 32882.
Organizations running Discourse or other software that processes HEIF content should check both application versions and the underlying operating system packages. Containerized environments require particular attention because updating the host system does not necessarily update a vulnerable library embedded inside an existing image. Security teams should rebuild affected images after dependency updates and verify the resulting library versions rather than assuming that an application upgrade resolved every transitive dependency.
OpenAI Response
According to public reporting, OpenAI revoked affected sessions and addressed the reported identity issue. OpenAI also awarded Hacktron AI a $6,500 bug bounty.
The response illustrates why coordinated vulnerability disclosure remains important for complex attack chains. Researchers can demonstrate the security impact without unnecessarily accessing sensitive information, while the affected organization has an opportunity to revoke credentials, correct authorization boundaries and investigate related activity before public disclosure.
Why This Attack Chain Matters
Public Applications Can Become Internal Attack Paths
Public forums, customer portals and collaboration platforms are often treated as lower risk systems because they do not directly contain sensitive corporate data. That assumption becomes dangerous when these applications connect to enterprise identity infrastructure.
A compromise of the public application may therefore provide more than access to the application itself. It can become a starting point for credential theft, session abuse or access to connected services. Security architecture should account for these relationships when assessing the true exposure of public facing systems.
SSO Token Scope Matters
Single sign on reduces authentication friction, but it also creates a dependency between services. Tokens should be narrowly scoped to their intended audience and service, with explicit authorization requirements for every downstream application.
Security teams should review token audience restrictions, permissions, lifetime, session binding and revocation controls. A valid token should never be treated as a universal credential simply because it was issued by a trusted identity provider.
Native Image Parsers Require Isolation
Image processing is an established security concern because formats such as HEIF, HEIC and AVIF can involve large and complex native codebases. Applications should keep these libraries patched and should avoid running untrusted image processing with unnecessary privileges.
A strong architecture places image conversion inside an isolated workload with restricted filesystem access, limited network connectivity and minimal operating system privileges. Monitoring should also cover parser crashes, unusual resource consumption and unexpected processes launched by image processing services.
Detection and Monitoring
The most useful defensive controls focus on the transitions between the stages of the attack chain. Web application monitoring should identify unusual image uploads, repeated parser failures, image conversion crashes and unexpected processes originating from image processing components. Endpoint and container telemetry can help determine whether an image processing process behaved outside its normal execution profile.
Identity monitoring should focus on authentication tokens being used outside their expected audience, unusual session creation and unexpected access to employee services. Developer environments require additional monitoring because an identity compromise may appear as legitimate activity. Unexpected pull requests, unfamiliar GitHub sessions, unusual repository changes and abnormal activity through developer integrations should therefore be investigated in context rather than treated as isolated events.
MITRE ATT&CK Context
The attack chain can be discussed using several MITRE ATT&CK concepts. T1190, Exploit Public Facing Application, is relevant to the initial compromise of a public application. The identity component can also be considered in the context of Valid Accounts, depending on the precise authentication mechanism and how the resulting session was used.
These mappings are useful for defensive analysis, but they should not be treated as evidence that every technique was independently confirmed in the public research. ATT&CK provides a framework for describing adversary behaviour; it does not replace the underlying technical evidence.
What Security Teams Should Do
Organizations should begin by identifying every public application that processes complex file formats and every native dependency used by those applications. Vulnerability management should extend beyond direct application packages to include operating system libraries, container images and transitive dependencies.
Identity teams should separately review whether tokens issued to public applications can be accepted by internal services. Token audiences, permissions, session lifetime and revocation behaviour should be tested as part of routine identity security assessments.
Developer platforms should receive the same level of attention. GitHub, coding agents, CI systems and other developer integrations can hold substantial privileges, so authentication events and repository changes should be correlated with identity telemetry. This makes it easier to distinguish normal automation from activity that follows an unexpected authentication event.
Frequently Asked Questions
Did Hacktron AI hack OpenAI?
Hacktron AI researchers demonstrated access to OpenAI employee ChatGPT and Codex sessions during authorized security research. They used the resulting access to create a test pull request in an internal repository and then disclosed the findings through the appropriate security channels.
Did Claude hack OpenAI?
No. Claude was used by human researchers as an AI assistance tool during the security research. The researchers controlled the testing process and the systems involved.
What vulnerability was involved?
The research involved CVE 2026 32882, a vulnerability affecting libheif. Discourse later published GHSA vhm9 85gw x335, describing a remote code execution issue involving malformed HEIF files.
Was CVE 2026 32882 itself an RCE vulnerability?
The underlying CVE is described as an out of bounds read. The RCE impact described by Discourse relates to how the vulnerable library was exposed through the application’s image processing pipeline. These should be described as related but distinct pieces of the attack chain.
What was the identity security issue?
According to reporting about the research, authentication tokens associated with the community environment could cross service boundaries. This created a risk that authentication obtained through one service could provide access to other OpenAI services.
Did the researchers steal OpenAI source code?
The public material supports a demonstration of access to an internal repository through a test pull request. It does not support a claim that the researchers downloaded OpenAI’s entire source code repository or obtained model weights.
How much was the bug bounty?
OpenAI awarded Hacktron AI a $6,500 bug bounty, according to public reporting.
Who were the researchers?
The researchers associated with the work were Harsh Jaiswal, Mohan Sri Rama Krishna Pedhapati and Rahul Maini. Their public LinkedIn profiles are listed in the researcher section of this article.
Conclusion
The Hacktron AI research is valuable because it demonstrates the practical consequences of connecting systems that are often assessed separately. A public forum, an image processing library, an identity provider and a developer environment may each appear manageable when considered on its own. When those systems share trust relationships, however, a weakness in one layer can become a route into another.
The defensive lesson is therefore broader than the libheif vulnerability itself. Organizations need to understand how public applications connect to identity infrastructure and how authenticated developer services connect to source repositories and automation platforms. Strong token isolation, least privilege, dependency management and workload isolation all reduce the chance that a local application vulnerability becomes an enterprise wide security incident.
AI assisted vulnerability research adds another factor. Coding models can reduce the effort required to investigate complex technical problems, which may shorten the time between vulnerability discovery and reliable exploitation. Security teams should respond by improving visibility, reducing unnecessary privileges and shortening remediation cycles rather than assuming that sophisticated attack chains will remain difficult and slow to develop.
References
- Discourse Security Advisory: GHSA vhm9 85gw x335
- Rapid7: CVE 2026 32882
- Debian Security Advisory DSA 6417 1
- Hacktron AI: HEIF Heist Research
- The Wall Street Journal: Hackers Used Anthropic’s Claude to Break Into OpenAI
- The Verge: OpenAI Hack and Claude Research
- Financial Times: OpenAI Security Research
- OpenAI Bug Bounty Program
