⏱️ Lectura: 10 min
On July 25, 2026, two chained vulnerabilities gave a team of three researchers access to OpenAI employees’ ChatGPT and Codex accounts, and from there, to the company’s internal repositories. The entire process, from the initial finding to a pull request inside the openai/openai monorepo, took less than 72 hours.
📑 En este artículo
The entry point wasn’t an AI model or a malicious prompt: it was a classic libheif vulnerability, the library that decodes HEIF/HEIC images, exploited through OpenAI’s public support forum.
TL;DR
- On July 25, 2026, Hacktron chained an RCE in libheif with an OpenAI SSO flaw.
- The vector was a .heic image uploaded to community.openai.com, processed by ImageMagick via libheif.
- With admin access to Discourse and the SSO flaw in auth.openai.com, they took over employees’ ChatGPT and Codex accounts.
- They used the compromised Codex account to open PR #1186742 in the internal openai/openai monorepo as proof of concept.
- Less than 72 hours passed between the first RCE and access to internal repos.
- OpenAI confirmed the fix about 14 hours after the report, at 22:49:45 UTC on July 25.
- Discourse published advisory GHSA-vhm9-85gw-x335 on July 28 with a patch and image sandboxing.
- OpenAI paid a $6,500 bounty on September 1, clarifying that the Discourse finding fell outside its program.
What happened: the libheif vulnerability in OpenAI’s forum
The team behind the discovery is called Hacktron, and confirmed they achieved remote code execution (RCE) and full administrative access to the Discourse instance running at community.openai.com, OpenAI’s official support forum. That access happened between 05:00 and 06:00 UTC on July 25, 2026.
Between 08:00 and 10:00 UTC that same day, Hacktron reported the finding through OpenAI’s bug bounty program on Bugcrowd. Hours later, between 13:30 and 15:30 UTC, they demonstrated the real-world impact: they used the access to open a harmless pull request, identified as PR #1186742, inside the internal openai/openai monorepo. After that, they stopped all testing activity and notified OpenAI contacts.
OpenAI confirmed it had fixed the issue at 22:49:45 UTC, just 14 hours after the initial report. Discourse, the open-source forum software OpenAI uses, received a separate report through HackerOne that same day; it responded on July 26, had a patch ready on July 27, and published the advisory GHSA-vhm9-85gw-x335 on July 28, with patching guidance and an additional layer of sandboxing for image processing.
Formal closure came only on September 1, 2026: OpenAI paid a bounty of $6,500 and marked the case resolved, clarifying in its response that testing against the Discourse instance hosted at community.openai.com was explicitly out of scope for its bug bounty program. According to the company, the reward recognized only the finding on OpenAI’s side, the SSO flaw, not the exploitation of Discourse.
Background and history
Hacktron is a small team led by Harsh Jaiswal, alongside Mohan Pedhapati and Rahul Maini, focused on hunting vulnerabilities in frontier AI companies. Months before this finding, they had already spotted a configuration flaw in OpenAI’s identity infrastructure, the same SSO component that would end up being the second link in this chain.
The libheif finding on Discourse wasn’t an isolated event for the team: they folded it into a broader investigation called HEIF Heist, which has spent months tracking where else this image-decoding library is used. According to Hacktron, the trail leads to Slack, Meta, GitHub Enterprise, Ruby on Rails applications, and Node.js frameworks like Next.js, Astro, and Gatsby. The team’s conclusion is simple: a surprising amount of software depends on a single image library, and when that library fails, the blast radius is enormous.
Technical details of the exploit chain
The full chain has eight links, and each one looks minor on its own. Together, they allowed the team to take over OpenAI’s corporate accounts.
It all started with a .heic image uploaded as an avatar or attachment on community.openai.com. Discourse delegates image processing to ImageMagick, which in turn uses libheif to decode the HEIF format. The version of libheif bundled in Discourse’s Docker image had a known but unpatched heap buffer overflow: Debian never applied the corresponding security backport to that branch, so the fix never reached the package Discourse installs by default.
That heap overflow, triggered simply by processing the malicious image during upload, gave Hacktron remote code execution inside Discourse’s container, and from there, full administrative access to the forum.
The second link was independent of the first: OpenAI allows logging into the forum with Sign in with OpenAI, an SSO flow served from auth.openai.com. Hacktron already knew about a flaw in that identity flow from an earlier investigation. With administrative access to Discourse plus that SSO flaw, they were able to move from the forum into the real ChatGPT and Codex accounts of OpenAI employees. And since Codex can connect to GitHub, Slack, and corporate email, the theoretical exposure radius included all of those systems.
flowchart TD
A["Malicious .heic image"] --> B["Uploaded to community.openai.com"]
B --> C["Discourse invokes ImageMagick"]
C --> D["ImageMagick delegates to libheif"]
D --> E["Heap buffer overflow in libheif"]
E --> F["RCE and admin access in Discourse"]
F --> G["SSO flaw in auth.openai.com"]
G --> H["ChatGPT and Codex account takeover"]
H --> I[("Proof-of-concept PR in openai/openai")]For a developer running their own Discourse instance, the first practical step is to confirm whether their installation still depends on a vulnerable version of libheif. Inside the application container, you can run:
# inside the Discourse container (docker exec -it app bash)
dpkg -l | grep libheif
ldconfig -p | grep libheifIf the installed package predates Debian’s security backport for that branch, the installation remains exposed to the same kind of heap buffer overflow Hacktron used.
How to protect yourself if you self-host Discourse
Discourse-hosted, the managed version offered by the company itself, is already patched: no action is needed. The real problem is for those running Discourse on their own with Docker, which is most self-hosted installations.
The official advisory is explicit on a point that’s easy to miss: updating only from the web admin interface isn’t enough, because that path doesn’t replace the container’s base image where the vulnerable libheif lives. You need to rebuild the entire image:
cd /var/discourse
git pull
./launcher rebuild appThat command downloads the updated container definition and rebuilds the application from scratch, which does replace the vulnerable libheif. As an additional defense, Discourse also added sandboxing to the image-processing pipeline, so that a future decoding failure doesn’t translate directly into RCE on the main process.
| Installation | Status after July 28 | Recommended action |
|---|---|---|
| Discourse-hosted (official SaaS) | Patched by the provider | None |
Self-hosted, rebuilt with launcher rebuild | Patched if run after July 28 | Verify libheif version with dpkg -l |
| Self-hosted, only updated from the web panel | Likely vulnerable | Run git pull and ./launcher rebuild app from /var/discourse |
⚠️ Heads up: if you run your own Discourse instance and only applied updates from the web admin panel, your installation may still be running the vulnerable libheif. The advisory explicitly calls for rebuilding the entire image with ./launcher rebuild app.
Impact and analysis
What makes this case serious isn’t just the specific libheif vulnerability, but the surface it connected to. Community.openai.com is a support forum, a component many organizations would treat as low risk. But because it was integrated with the same identity system protecting ChatGPT and Codex, any compromise there escalated directly to real corporate accounts.
Codex, OpenAI’s coding agent, can connect to GitHub, and potentially to Slack and email. That means a flaw in a help forum ended up, in theory, one step away from private repositories, internal channels, and corporate inboxes. Hacktron deliberately stopped before exploring that full surface: they used the access only to demonstrate impact with a harmless PR, without reading sensitive information.
OpenAI’s response also leaves an editorial lesson for any bug bounty program: the company carefully separated which part of the finding it paid for, its own SSO flaw, from which part fell outside scope, the exploitation of a third-party service, Discourse, even though it was hosted under its own domain. It’s a reminder that a bug bounty’s scope doesn’t always follow the domain: it follows the code the company directly controls.
💡 Tip: if your product accepts user-uploaded .heic, .heif, or .avif images, it’s a direct candidate for Hacktron’s HEIF Heist investigation. The team offers help at [email protected].
What’s next
Hacktron noted that HEIF Heist is still active and that they’ve already traced libheif in Slack, Meta, GitHub Enterprise, and Node.js frameworks like Next.js, Astro, and Gatsby, as well as Ruby on Rails applications. More advisories related to the same library are likely to appear in the coming months, in products that don’t even know they use it transitively, through ImageMagick, libvips, or other image-processing tools.
For security teams, the case leaves a concrete task: audit which low-profile components, such as forums, wikis, or ticketing systems, are connected to the same identity provider protecting critical systems, and treat them with the same patching rigor.
📖 Summary on Telegram: View summary
Try it yourself: if you run your own Discourse instance, run dpkg -l | grep libheif inside the container today to check whether you’re still exposed before rebuilding the image.
Frequently Asked Questions
What is libheif and why is it so widely used?
It’s the open-source library that decodes images in HEIF/HEIC format, the default format iPhones have used since 2017. A huge number of applications that accept image uploads use it directly or transitively, through ImageMagick or other tools, which explains the blast radius documented in Hacktron’s HEIF Heist investigation.
Is community.openai.com still vulnerable?
No. OpenAI confirmed the fix on its SSO infrastructure side on July 25, 2026, and Discourse published its patch with additional sandboxing on July 28 in advisory GHSA-vhm9-85gw-x335.
Is my own Discourse instance at risk?
It depends on how you updated it. If you only applied changes from the web admin panel without rebuilding the full Docker image with ./launcher rebuild app, you’re likely still running the vulnerable libheif.
Why did OpenAI pay only $6,500 if the impact was so large?
Because OpenAI limited the payout to the finding it considered within its own scope: the SSO flaw in auth.openai.com. Even though the Discourse exploitation was hosted at community.openai.com, the company marked it as outside the scope of its bug bounty program on Bugcrowd.
Did Hacktron ever see sensitive OpenAI information?
According to their own account, no: they stopped after opening the proof-of-concept pull request PR #1186742 in the internal openai/openai monorepo, without reading internal data, and notified OpenAI immediately.
What other products could be affected by libheif?
Hacktron’s HEIF Heist investigation mentions traces of libheif in Slack, Meta, GitHub Enterprise, Ruby on Rails applications, and Node.js frameworks like Next.js, Astro, and Gatsby, among others.
References
- Hacktron: Hacking OpenAI: the original technical writeup with the full timeline of the finding.
- GitHub Security Advisory GHSA-vhm9-85gw-x335: Discourse’s advisory on the libheif vulnerability in image processing.
- OpenAI’s bug bounty program on Bugcrowd: the channel Hacktron used to report the OpenAI-side finding.
- Discourse Meta: the official community and documentation for the Discourse project.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de GuerrillaBuzz en Unsplash
0 Comments