Three researchers broke into OpenAI's internal code repository in under 72 hours 19. They did not attack a model. They uploaded a photo. According to Hacktron's September 13 11 disclosure, the entry point was libheif, a C library that decodes the HEIC images modern iPhones shoot by default.
OpenAI paid a $6,500 17 bounty, for its own sign-in finding only. The chain was reported to OpenAI and Discourse in July and fixed before the public heard a word, per VentureBeat. I will admit I skimmed past this story the first time because it read like a forum bug. That was a mistake.
The lesson is simple. Multimodal AI gets attacked through an image decoder, not a model. Every product with an "attach an image" button inherits the same problem, and most teams have never looked at it.
The Loading Dock Rule
Every AI product has a front door and a loading dock. The front door is the model: the prompt box, the safety layer, the thing your red team hammers all quarter. The loading dock is the upload pipeline, where raw bytes from strangers get unpacked by code written before your engineers learned to type. Attackers walk in wherever the oldest code touches untrusted input first.
What it cost to walk from an image upload into an internal monorepo.
Sort your upload path into three buckets. Modern managed code: decoders written in Rust, Go, or JavaScript with bounds checking built in. Wrapped legacy code: ImageMagick or libvips calling down into C parsers on your behalf. Naked legacy code: a C library linked straight into your app.
OpenAI's forum sat in bucket two, and bucket two is where most of the internet lives. Discourse itself is Ruby. The danger was one shell command deep, where magick handed a HEIC file to libheif 1.19.7 01 on Debian 12 06.
The cash side matters here. A community forum exists to deflect support tickets, so to a marketing team it is free convenience. It was also wired to OpenAI's sign-in, and that sign-in reached far beyond the forum. OpenAI's bounty covered that sign-in flaw alone; testing the forum was outside its program's scope.
The loading dock nobody red-teamed
Wrapped legacy code is where most of the internet lives.
A Ruby app on top does not make the C parser underneath safe. Many upload pipelines call a native image library the same way, and this one ran on Debian 12 06. Managed code on top does not neutralise a C parser underneath.
The bounty paid for one link, not the chain.
OpenAI's $6,500 covered its own sign-in flaw. Testing the forum was outside its bug bounty scope, so nothing was paid for the rest of the path.
A ticket-deflection tool became the front line.
A help forum looks low-stakes to the people who approve it. Its sign-in reached far more than the forum, and three researchers turned that into an internal code path in under 72 hours.
Audit the loading dock before someone else does.
- Inventory every upload entry point. List every place a stranger can hand your systems raw bytes: product uploads, support forums, avatar fields, email attachments. The OpenAI chain started in a community forum, not the core product.
- Sort each decoder into three buckets. Modern managed code with bounds checking, wrapped legacy code such as ImageMagick or libvips shelling into C parsers, and naked legacy C linked into your app. Anything in bucket two or three needs a named owner and a patch cadence.
- Pin and test your image library versions. Record the exact build in use, as Hacktron did with libheif 1.19.7 01 on Debian 12 06, then fuzz HEIC and other camera-native formats against it in a sandbox with no network and no repository credentials.
Your red team is guarding the front door while the loading dock stands open.
The July chain against OpenAI earned a $6,500 17 bounty and less than 72 hours 19 to build, and it never attacked a model. It went through libheif 1.19.7 01, C code sitting quietly behind a Ruby forum on Debian 12 06. That is the shape of multimodal risk: the newest interface on your product is wired to the oldest code in your stack, and prompt-injection drills will not find it. Map the upload path, name the owner of every decoder, and treat the attach-an-image button as untrusted input rather than free convenience.