Anatomy of HEIF Heist: How Hacktron Used Claude to Break Into OpenAI, Slack, and GitHub Enterprise

This week, security startup Hacktron AI disclosed HEIF Heist, a vulnerability research campaign that ran for several months and ended with breaches at OpenAI, Slack, Meta, and GitHub Enterprise. The list of victims is striking, but the method is what stays with me. Hacktron says Anthropic’s Claude Opus models helped find the first vulnerability and build the exploit for it, which makes this a concrete case of AI-assisted exploitation working against heavily defended targets.

This teardown covers the HEIF Heist attack chain, the memory corruption flaws in native image parsers behind it, and the defenses that matter for any web application that leans on native dependencies.

The OpenAI breach: from a forum upload to the internal monorepo

The entry point was community.openai.com, OpenAI’s public support forum. It runs on Discourse, a widely used open-source community platform. The Hacktron team, Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini, went after the forum’s image upload pipeline, and in particular the High Efficiency Image File Format (HEIF) and Apple’s HEIC variant.

The first obstacle was image validation. Discourse, like many Ruby on Rails applications, uses the fastimage gem to check uploads by reading only the file headers. fastimage has no support for HEIF or HEIC magic bytes, so a crafted .heic file never got a meaningful check. It went straight to the server’s heavier native image stack for resizing and optimization.

That stack relies on libheif and libde265, native C/C++ libraries that decode the ISO Base Media File Format. The researchers built a file with a malformed payload in the HEIF metadata and grid image structures. It triggered a heap overflow in the C++ decoder and gave them remote code execution (RCE) on the Discourse server that hosts OpenAI’s forum.

The SSO pivot: stealing employee identities

RCE on a peripheral community forum is a real result, but the lateral movement is what made this serious. OpenAI’s Discourse instance used single sign-on (SSO), so employees and users signed in with their main OpenAI accounts. With root or application-level access to the server, the attackers could read environment variables, memory dumps, and session stores, and pull active OAuth and SAML authentication tokens out of them.

Those tokens let them impersonate OpenAI employees who had recently signed in to the forum. A modern ChatGPT or Codex account is wired into a lot of enterprise infrastructure through API integrations, including Gmail, Outlook, Slack, and internal GitHub repositories. The SSO bypass therefore gave the attackers a direct route into OpenAI’s corporate network.

To show how bad it was without doing damage, the researchers used a compromised employee’s Codex environment to open a harmless pull request in OpenAI’s private internal monorepo. OpenAI’s security team patched the SSO flaw within 14 hours of the report and paid the researchers a $6,500 bug bounty.

Claude as an exploit developer

The part of the disclosure that unsettles me most is how much of the exploit work Claude did. According to the researchers, Claude Opus 4.8 first analyzed the libheif codebase and found the underlying memory corruption bug. Once the flaw was identified, the team used the newly released Claude Opus 5 to produce the version-specific payload needed for reliable RCE, with the researchers steering the process.

Turning a heap overflow in a native C++ parser into a dependable exploit has traditionally taken weeks of manual reverse engineering, debugging, and work to defeat ASLR (Address Space Layout Randomization). Hacktron says an agentic AI workflow shrank what would normally be a month of effort to a three-hour exploit development window, and that it had full access to OpenAI’s internal repository within 72 hours of first probing.

If that timeline holds up, frontier LLMs are doing more than helping write code. They are taking part in the weaponization of zero-day and n-day vulnerabilities, and that changes the economics of offensive security.

The blast radius: GitHub Enterprise, Slack, and web frameworks

The OpenAI breach got the headlines, but HEIF Heist was really an investigation into the dependencies nobody sees. The vulnerable code sits below the application layer, inside native C/C++ decoders that reach production through wrappers such as ImageMagick, libvips, Sharp, and standard Linux distribution packages.

CVE-2026-19118: a TOCTOU flaw in GitHub Enterprise

One of the most serious findings was a vulnerability in GitHub Enterprise Server, tracked as CVE-2026-19118. It is a Time-of-Check to Time-of-Use (TOCTOU) race condition rated high severity, with a CVSS score of 7.5.

Enterprise applications like GitHub process assets and images asynchronously. A TOCTOU bug appears when the application checks a file’s state or permissions (the time of check) and acts on the file later (the time of use), and an attacker changes the file in the gap between the two. By timing the upload and replacement of crafted image files, the Hacktron team bypassed access controls and triggered remote code execution inside the GitHub Enterprise environment.

Next.js and the AVIF optimization endpoint

The campaign also turned up an unauthenticated RCE in Next.js, through its built-in AVIF image optimization API. Next.js optimizes images on the fly and serves modern formats like AVIF, which depends on the same libavif and libheif decoding infrastructure. That endpoint is often public and unauthenticated.

An attacker can fingerprint the target’s libheif version by uploading assorted malformed .avif files and reading the error responses. Once the exact version is known, a tailored n-day payload gives unauthenticated RCE and control of the whole hosting environment, with no valid user account required.

Why native image parsers keep failing

HEIF Heist hit everything from Meta’s product suite to Ruby on Rails apps because of how image processing is built. The ISO Base Media File Format (ISOBMFF) underneath HEIF, HEIC, and AVIF is complicated. It uses nested “boxes” to define metadata, color profiles, and image grids.

Parsers like libheif and libde265 are written in C and C++, so they manage memory and pointer arithmetic by hand as they walk those nested structures. One bad calculation on a grid image’s width or height can cause an integer overflow and an undersized buffer. When the decoder then writes decompressed pixel data into that buffer, the result is a heap buffer overflow. Rust and Go check bounds for you. C and C++ do not, so the overflow silently corrupts neighboring memory, and an attacker who controls the overwrite can hijack function pointers or return addresses and redirect execution.

Most web developers never touch libheif directly. They call wrappers such as Sharp in Node.js or CarrierWave in Ruby, which hide the native complexity and inherit its memory unsafety. When a framework accepts an upload, it hands the bytes to the wrapper, and the wrapper calls the native library. A bug in one low-level decoder can therefore compromise thousands of applications that look unrelated.

Mitigation and defense in depth

DevSecOps teams, architects, and sysadmins should act now. Waiting on upstream patches is a weak strategy, because a fix for a native library can take a long time to reach the global package ecosystem.

Patch and audit dependencies

Start by finding every native image decoder in your infrastructure, libheif and libde265 included. Upgrade to libheif 1.23.2 or later and apply the latest libde265 security patches through your distribution’s security channels or from source. Because upstream package managers lag, add automated software composition analysis (SCA) to catch indirect dependencies buried in container base images and wrapper libraries.

Isolate and sandbox image processing

Assume your native image parsers will eventually be compromised. Image processing should never share a memory space or execution context with the core web application. Run untrusted uploads in hardened, ephemeral sandboxes: locked-down Docker containers with strict seccomp profiles, AppArmor policies, or microVMs such as Firecracker. If an attacker gets RCE inside the sandbox, the damage stays in an ephemeral container and cannot spread to the host network.

Disable unneeded decoders and use atomic operations

If your application does not need HEIF, HEIC, or AVIF uploads, turn decoding off at the application layer. Validate image magic bytes with a memory-safe parser before any file reaches a native processing engine. For asynchronous file handling in enterprise applications, use strict file locking and atomic file operations to close the window that race conditions like CVE-2026-19118 depend on.

What to do next

HEIF Heist shows that your software supply chain is only as strong as its most obscure, deeply nested C++ dependency. It also shows that frontier AI models can now do much of the exploit development work that used to take specialists weeks. If AI agents keep getting better at finding memory corruption flaws and generating reliable payloads, the time you have to patch could shrink from months to hours.

Enforce zero-trust architecture, isolate native dependencies, and put automated AI-driven vulnerability scanning into your CI/CD pipeline before attackers do it for you.