In less than 72 hours, Claude helped a white-hat hacker infiltrate OpenAI's internal system, and the mere $6,500 bounty has sparked widespread heated discussion.
OpenAI internal employees' ChatGPT accounts were hacked, and the "hero" that helped pull off the feat turned out to be none other than Claude from their arch-rival Anthropic. It sounds ironic, but this is exactly what happened.
Recently, a cybersecurity research firm called Hacktron AI disclosed on X that as early as two months ago on July 25, they successfully breached part of OpenAI's internal code repository and obtained access to ChatGPT and Codex accounts of multiple OpenAI employees.
From discovering the vulnerability to completing verification, the entire process took less than 72 hours. In the end, they also obtained a $6,500 bounty through OpenAI's vulnerability bounty program on Bugcrowd.
After the news broke, it quickly drew widespread public attention. After all, OpenAI is already a top-tier leading player in the AI race, yet researchers managed to sneak into its internal development environment with the help of a model from another AI giant.
So how on earth did they pull it off?
Two vulnerabilities strung together to form a chain of access into OpenAI
In fact, several months ago, three researchers from the Hacktron AI team, Harsh Jaiswal, Mohan Pedhapati and Rahul Maini, began conducting security vulnerability research targeting cutting-edge AI companies.
During one test, they accidentally discovered two seemingly unrelated vulnerabilities:
One appeared in OpenAI's identity infrastructure, which was an SSO configuration issue;
The other was hidden in libheif, a third-party component used by OpenAI's community forum, which had an exploitable remote code execution vulnerability.
Looking at these two vulnerabilities alone, it is hard to connect them to OpenAI's internal systems. But the researchers soon found that if they strung them together, they could form an attack chain that went all the way from the community forum into OpenAI's internal systems.
They then used this access chain to compromise the ChatGPT accounts of multiple OpenAI employees, and further discovered that one of the employees' Codex accounts was also connected to OpenAI's GitHub organization.
This means that the researchers no longer had access to just an ordinary ChatGPT account, but had the opportunity to further reach OpenAI's internal development environment.
The entry point was not OpenAI's main site, but its community forum
Looking back at the whole incident, it is worth noting that the starting point of this attack chain was OpenAI's community forum, not OpenAI's main site.
According to the researchers' disclosure, OpenAI's community forum is built with Discourse, an open-source web forum software, and supports logging in via auth.openai.com with "Sign in with OpenAI". That is to say, the forum is not a completely isolated site, and it is connected to OpenAI's identity authentication system.
As mentioned earlier, the researchers from Hacktron AI had previously discovered that there was an SSO configuration issue in OpenAI's identity infrastructure, so they came up with a hypothesis:
If they could first take over this community forum, it would be possible to further access other OpenAI services along the identity authentication chain.
The question was, how to obtain remote code execution (RCE) capabilities on this forum server?
Discourse itself is not an easy target to exploit, and the Hacktron team had previously conducted research on it. So they turned their attention to the third-party software that Discourse depends on.
On July 23, Hacktron AI researchers began examining Discourse's image upload and processing workflows, and noticed that images in HEIC and HEIF formats (commonly used on devices such as iPhones, similar to JPG) follow a different processing path from regular images.
Under normal circumstances, Discourse uses the image processing component FastImage to check images uploaded by users. But FastImage did not support HEIF at that time, so such images would be handed over to the magick command in another image processing tool ImageMagick for conversion. During the conversion process, ImageMagick would call libheif to parse HEIF images.
This means that the HEIF file uploaded by the attacker would eventually go directly to the underlying libheif image parser.
Claude Opus 4.8 got stuck while hunting for bugs, Opus 5 took over
At this stage of the research, the researchers next started to detect whether there were security issues in the libheif image parser.
Of course, in the AI era, they did not rely entirely on manual work to complete this task. In this process, they used Claude Opus 4.8 to analyze Discourse's Docker image, and asked the model to check whether the libheif software package installed in it had any security issues.
After a period of analysis, Claude found a key problem: some security patches that had been fixed upstream had not been backported to the libheif software package in use at that time in a timely manner.
This problem exists during the HEIC image decoding process, which can cause a heap buffer overflow, and further create out-of-bounds read and write capabilities, creating conditions for code execution. Worse still, the relevant vulnerable code had been modified by the upstream project the previous year, but the commit at that time was not clearly marked as a security fix, nor did it get a CVE number.
The Hacktron researchers believe that the reason why this vulnerability still exists in the stable version of Debian may be that the upstream has fixed it, but Debian did not promptly "port back" this fix patch to the old version it was using.
The Docker image used by Discourse at that time was based on Debian 12, and the installed libheif version 1.19.7 was vulnerable. Even Debian 13 was still using the vulnerable version 1.19.8 at that time.
After finding the vulnerability, the researchers continued to let Claude Opus 4.8 try to exploit the vulnerabilities in ImageMagick/libheif to see if it could further make the program execute code specified by the attacker.
On July 24, with ASLR (Address Space Layout Randomization) turned off, Claude had already helped the researchers build a working code execution exploit.
But the real problem was that Discourse's default environment had ASLR enabled. The researchers then launched multiple independent Claude sessions, trying to get the model to further adjust the exploit so that it could work stably under the default configuration.
This attempt did not yield ideal results.
The turning point came that night. Anthropic happened to release Claude Opus 5 at that time, and the researchers used this new model to start a new round of tests.
According to Hacktron AI, the new model first generated a set of working ARM64 exploits for the local Mac environment in less than 3 hours. Then the researchers asked Claude to port this exploit to the x86-64 environment where Discourse actually runs, and adapt it to the jemalloc memory allocator configuration it uses.
By around 6 a.m. on July 25, they had confirmed that remote code execution (RCE) could be achieved locally by uploading images.
Next, the researchers put Claude in an automated loop, letting it continuously test the Discourse Cloud instance they had built. To make the target environment more similar to a CTF range, they also proxied the test environment through rce.ee/ctf-forum.
There is another detail worth noting here. The Hacktron researchers had previously tried to get Claude Opus 4.8 to write an exploit directly for the remote instance, but the model rejected this request. Therefore, the researchers first let the model complete the vulnerability exploitation in their own environment, and then gradually migrated it to a configuration close to the real target.
At around 10 a.m., when the researchers checked again, Claude had successfully achieved RCE on Discourse Cloud, and proved execution permissions by reading the /etc/hosts file.
With this verified exploit, the researchers then applied it to OpenAI's Discourse instance, and finally obtained remote code execution permissions.
From forum RCE to OpenAI employee accounts
After obtaining execution permissions on the forum server, the researchers further verified their previous assumptions about OpenAI Single Sign-On (SSO).
They found that active users on the forum could be further associated with ChatGPT and Codex accounts under certain conditions. This means that the security issue that initially seemed to be just an image upload vulnerability could actually become an entry point to other OpenAI services.
The researchers then confirmed that they were able to take over an OpenAI employee's account, and that employee's Codex was connected to OpenAI's GitHub organization.
To prove that this permission could indeed reach OpenAI's internal development environment, while avoiding directly reading internal code, the researchers adopted a relatively restrained verification method: they issued instructions through this employee's Codex account, asking Codex to create a Pull Request (PR) in OpenAI's internal Monorepo.
This PR itself was not intended to modify or steal code, but to serve as proof that "operation permissions on the internal repository have been obtained". After completing this verification, the researchers immediately stopped further testing.
OpenAI completed the fix in about 14 hours and also paid a $6,500 bounty
They then added this part of the impact proof to the BugCrowd vulnerability report submitted to OpenAI, and notified the OpenAI security team again.
According to the research team's disclosure, OpenAI completed the fix for the issues on its side about 14 hours after receiving the report. By September 1, OpenAI paid Hacktron a $6,500 vulnerability bounty.
OpenAI further explained the scope of this bounty in a statement shared through Hacktron:
"To be clear, the scope of this reward is limited: testing against community.openai.com hosted by Discourse is explicitly not within the scope of our vulnerability bounty program. This reward recognizes the issues the researchers discovered on OpenAI's side, not the actions taken against Discourse."
At the same time, Hacktron researchers also separately reported the Discourse vulnerability to its HackerOne project.
According to the researchers, Discourse received the report on Saturday, responded on Sunday, and completed the fix on Monday. At the same time, Discourse also began to add sandbox isolation to the image processing process of ImageMagick, to reduce the risk of similar vulnerabilities being exploited and further affecting the server.
Hacktron specifically emphasized that what is really worth paying attention to in this attack chain is not Discourse itself, but OpenAI's SSO configuration.
In their view, Discourse is just an entry point used to verify this issue. If other first-party or third-party services that use OpenAI SSO have similar exploitable vulnerabilities, then a similar access chain could theoretically be formed. In other words, the forum was just a breakthrough found in this research, and it was OpenAI's identity authentication mechanism that extended the forum permissions to ChatGPT and Codex.
When using AI to hunt for vulnerabilities...
After the news was disclosed, a large number of discussions quickly appeared on X.
Some netizens said: "Completing a full RCE attack chain in 72 hours is absolutely insane."
Others focused their attention on the $6,500 bounty: "They only ended up giving you $6,500. Even though this discovery is pretty good, the reward is really a bit shabby. That said, great job on the research!"
Other netizens believe that the impact of such a vulnerability is obviously worth far more than $6,500: "Honestly, I feel bad for these researchers. Compared to the rewards they could have gotten, this is almost just pocket change, because the sensitivity level of this vulnerability goes way beyond that."
Another netizen shared his past experience of using AI Agents.
He said, "Their stuff was super rough. Back when GPT-4o was still the main model, I convinced my Agent in the web chat to access its sandbox Jupiter. It wrote a script that stayed on the server to keep the VM session alive, then started browsing and explaining everything inside and outside the sandbox, and even gave me the IP. I even got the ls output for every file in the environment, and the VM hard drive. It handed everything over bit by bit."
There is no doubt that this incident has once again exposed the new changes brought by AI-powered cyberattacks.
This time, the AI Agent did not just help researchers analyze vulnerabilities, but participated in multiple links from vulnerability discovery, exploit construction, to full attack chain verification, and the entire process took less than 72 hours.
In response to this, the researchers also warned: "Work that used to take a well-resourced team months to complete can now be compressed into just a few days. The original assumptions in the security field must also keep up with the changes in attackers' capabilities. Today, a more realistic threat model should consider what changes have taken place in the economic cost of exploiting vulnerabilities, instead of relying on outdated assumptions that only specific groups of people have the ability to carry out complex attacks."
References:
https://www.theregister.com/security/2026/09/18/researchers-used-claude-to-hack-openai-employees-chatgpt-accounts/5297517
https://www.tomshardware.com/tech-industry/cyber-security/hackers-breach-openai-using-claude-tools-gaining-access-to-employee-accounts-and-the-companys-internal-codebase-initiating-a-harmless-pull-request-as-proof-of-the-hack