A team of security researchers took over OpenAI employee accounts by chaining two separate flaws: an image-processing bug in a library used by ImageMagick, and a weakness in the single sign-on linking several internal services. The exploit was built with help from Claude Opus 5, used as an offensive research copilot to speed up the analysis and the chaining of the two vulnerabilities.
A crafted HEIF image as the entry point
OpenAI’s public help forum, hosted on Discourse, accepts HEIF and HEIC images uploaded by users. Those files are then processed by ImageMagick, which hands off decoding to the libheif library. A memory-corruption flaw in that library let a specially crafted image compromise the server that parsed it, a classic case of untrusted content being deserialized server-side.
This kind of image pipeline remains a frequent blind spot: converting exotic file formats is often delegated to third-party libraries that get far less scrutiny than the core application code a security team watches most closely.
Single sign-on, the weak link in the chain
Compromising the forum server would have had limited impact on its own if it hadn’t opened access to the shared identity used by other OpenAI services. According to Hacktron’s researchers, the second flaw was less a bug in the forum software than a design problem: any first- or third-party service tied to the same identity provider could have granted the same level of access.
| Step | Component affected | Nature of the flaw |
|---|---|---|
| 1 | Discourse → ImageMagick → libheif | Memory corruption when decoding a crafted HEIF image |
| 2 | OpenAI single sign-on | Excessive trust granted to a third-party service on the same SSO |
| 3 | An employee’s ChatGPT / Codex account | Session takeover through the compromised SSO |
| 4 | Internal GitHub repository | A pull request opened via the employee’s Codex link |
Claude Opus 5 as an offensive copilot
Hacktron used Claude Opus 5 to explore the attack surface and chain the two vulnerabilities faster than a fully manual analysis would allow. The model helped qualify the impact of the memory bug and map out the services connected to the SSO, work that usually takes far longer by hand. The researchers noted that the pull request triggered on the internal repository never read the source code, never merged or shipped anything, and never touched customer data.
Using a model as a research accelerator in security work reflects a trend already visible elsewhere in offensive and defensive tooling, as the same models gain more autonomy on long-running production tasks well beyond security research alone.
# Simplified sketch of a server-side image conversion pipeline,
# the kind of chain the libheif flaw targeted
convert uploaded-image.heic -resize 800x800 -quality 85 output.jpg
identify -verbose uploaded-image.heic
OpenAI shipped a fix fourteen hours after the report, an unusually fast turnaround for a flaw touching authentication shared across several services.
Worth flagging: any self-hosted service that delegates image conversion to ImageMagick or a third-party decoding library (libheif, libraw, libwebp) inherits that dependency’s security posture. A minimal hardening baseline includes keeping these libraries current, independently of the core application.
OpenAI’s response and the patch timeline
OpenAI confirmed a fix roughly fourteen hours after Hacktron’s initial report, then paid the team a $6,500 bounty on September 1. The tight timeline stands in contrast with the chain’s complexity: the flaw touched a barely visible third-party component, and a full fix meant reworking how much trust the SSO extended to external services, not just patching a line of code in libheif. The case also raises, in passing, questions about increasingly autonomous models joining technical teams’ toolkits, on both the offensive and defensive sides.
Key takeaways
A third-party image-decoding library can become the entry point for a breach that reaches far beyond the service that uses it, once a shared single sign-on connects that service to more sensitive systems. Assistance from a model like Claude Opus 5 shortened the time needed to qualify and chain the two flaws, without changing the underlying problem: auditing file-processing dependencies and mapping which services trust the same SSO remain the two blind spots that are most expensive to ignore.
Chains like this are a reminder that a security review stopping at application code always leaves a file-conversion library off the radar. On infrastructure under ongoing management, updating image-processing dependencies (ImageMagick, libheif, libwebp) gets the same priority as a CMS patch itself, precisely because it’s the kind of component that’s easy to forget to list — Simon Janvier.
Further reading: the full account on The Register.
