--- title: "A Broken Image Library, an AI-Written Exploit, and Your TYPO3 Uploads" canonical: "https://dmitry-dulepov.com/a-broken-image-library-an-ai-written-exploit-and-your-typo3-uploads/" language: "en-US" content_type: article --- # A Broken Image Library, an AI-Written Exploit, and Your TYPO3 Uploads A crafted photo, an image library nobody thought about, and an AI agent that wrote the exploit. The chain that reached inside OpenAI runs through software a lot of TYPO3 sites quietly rely on too. In September 2026 the security research firm [Hacktron published a write-up](https://www.hacktron.ai/blog/hacking-openai) describing how they gained remote code execution on infrastructure belonging to OpenAI. The entry point was almost mundane: they uploaded an image to a forum. What makes the story worth reading — and worth acting on — is *where* the bug actually lived, and how it was weaponised. If your TYPO3 site accepts image uploads and processes them with ImageMagick or GraphicsMagick, the same class of exposure applies to you. Here is what happened, why the usual mental model of "it's ImageMagick's fault" is wrong, and what to do about it. ## How it happened OpenAI, like thousands of organisations, runs a [Discourse](https://www.discourse.org/) community forum. Discourse lets users upload images. To read image dimensions it normally uses a lightweight Ruby library called FastImage. But FastImage does not understand Apple's HEIC/HEIF photo format — so, according to Hacktron's account, Discourse handed those files off to ImageMagick's `magick` command instead. That handoff is the whole story. ImageMagick does not decode HEIC on its own. It delegates to a separate library called **libheif**. And the version of libheif shipping on the server — pulled in from the base operating system image — contained a heap buffer overflow that could be triggered simply by parsing a malicious HEIC file. From there it is the classic memory-corruption ladder: a buffer overflow that yields out-of-bounds read and write primitives, turned step by step into control of the process. The attacker uploads a picture; the server tries to make a thumbnail of it; the picture executes code. Hacktron reported using the resulting foothold to reach internal repositories through compromised employee accounts. **The vulnerability was never in ImageMagick. ImageMagick was just the front door that led to the library with the actual hole.** ## The part that should worry you: it wasn't ImageMagick's bug This is the detail people get wrong, so it is worth stating plainly. ImageMagick and GraphicsMagick are *orchestrators*. For anything beyond the simplest formats they call out to specialist libraries — libheif for HEIC/AVIF, Ghostscript for PDF and EPS, a renderer for SVG, and so on. When one of those delegate libraries has a memory-safety bug, the tool that called it inherits the vulnerability wholesale. Two consequences follow, and both matter for how you defend yourself: - **Updating ImageMagick does not fix this.** The patch you need lives in libheif (and its codecs), delivered through your operating system, not in the image-processing tool itself. - **Switching to GraphicsMagick does not fix it either.** GraphicsMagick is a fork of ImageMagick with the same architecture and, in the HEIC case, the same delegate library underneath. It has a reputation for being more conservative — it ships fewer exotic decoders by default and dodged the infamous 2016 "ImageTragick" flaws — but on this class of bug it stands in exactly the same place. It also lacks ImageMagick's `policy.xml`, so it is actually harder to lock down by configuration. Hacktron went on to trace the same libheif exposure across a long list of well-known platforms and frameworks — a follow-up they called "HEIF Heist." The point is not that one forum was unlucky. The point is that a single fragile C library sits, unnoticed, under an enormous amount of software that accepts user-uploaded images. ## The AI angle Here is the twist that makes this more than another CVE story. Hacktron is an AI security company, and the exploit was developed with the help of a large language model acting as an autonomous agent. By their account the interesting friction was ASLR — address space layout randomisation, the standard defence that scatters memory so an attacker cannot predict where anything lives. They first built a working exploit with ASLR switched off. Making it reliable against a default configuration with ASLR *on* is a genuinely hard, fiddly research task. Hacktron reported that one model generation could not get there reliably, while the next one — released while they were still working — cracked it within hours. Read that with the appropriate caution: it is a vendor telling a good story about their own tools, and the fine-grained claims are theirs, not independently verified. But the direction of travel is real and worth sitting with. Exploit development against memory-corruption bugs has always been a specialist, labour-intensive craft — the thing that kept many theoretically-exploitable bugs from becoming practical attacks. If AI agents keep compressing that effort, the gap between "a bug exists" and "a bug is being used against you" gets shorter. The unglamorous work of patching promptly stops being optional. ## Why this lands on TYPO3 TYPO3 does structurally the same thing Discourse did. It accepts files through the backend and, on many sites, through frontend forms. It processes images — resize, crop, thumbnails — through an external processor you configure under `GFX` in the system settings, with `processor` set to ImageMagick or GraphicsMagick and a `processor_path` pointing at the binary. Every uploaded image that gets scaled runs through that pipeline, which runs through the same delegate libraries. A few things shape how exposed a given site really is: - **Which formats you actually accept and process.** Plain JPEG/PNG/GIF/WebP go through relatively battle-hardened decoders. The risk climbs sharply with exotic inputs — HEIC/AVIF, JPEG XL, and especially PDF, EPS and SVG, whose delegates (Ghostscript, SVG renderers) have a long history of remote code execution. - **Who can upload.** If uploads are limited to trusted backend editors, the attack surface is narrow. If an anonymous frontend form accepts images — avatars, contact forms, comments — you are in the same position Discourse was. - **What the worker runs as.** If your PHP-FPM pool runs as the same user that owns the site's files and holds its database credentials, code execution in the image parser means full compromise of that site. **A fair caveat.** Out of the box, a stock TYPO3 site will not necessarily hand HEIC files to its processor the way Discourse did — the exact HEIC vector depends on your formats and configuration. But the underlying pattern (untrusted file → external decoder → memory-unsafe C library) is exactly what TYPO3's image pipeline is, and the delegate libraries it leans on are the same ones under scrutiny here. Treat this as a class of risk, not a single CVE. ## What to actually do The fix is boring, which is the good news. In rough order of impact: 1. **Patch the delegate libraries through your OS security channel — not ImageMagick.** The bug was in `libheif` and its codecs (`libaom`, `libde265`). On Debian/Ubuntu that means keeping unattended security updates enabled, or applying them promptly by hand. Verify the installed version with `dpkg -l | grep libheif`. 2. **If you run in Docker, rebuild the image — don't just restart it.** This was Discourse's actual problem: a vulnerable libheif frozen inside a container image. A plain restart keeps the old, cached layer. Rebuild from a fresh base so the patched library is baked in. 3. **Restrict formats in ImageMagick's**`policy.xml`**.** Disable what you don't need — `PDF`, `PS`, `EPS`, `MVG`, `MSL`, and HEIC/AVIF/JXL if your site never handles them. This removes whole categories of delegate before any attacker-supplied file reaches them. (GraphicsMagick users: you don't get this lever, so lean harder on the next two.) 4. **Limit who can upload, and validate real file types** — the actual MIME signature, not the extension — especially on any upload path reachable by anonymous users. 5. **Isolate the processing.** Run each site under its own unprivileged user and PHP-FPM pool so that code execution in one site's image parser cannot reach another site or escalate to root. This turns "one bug = the whole server" into "one bug = one site" — the single most valuable structural mitigation you can have. None of this is a one-time task. New libheif vulnerabilities have kept surfacing throughout 2026; several security updates landed over the summer alone. The realistic goal is not "patched forever" but "patched quickly, and contained when a fresh one lands before the patch does." Prompt updates close the known holes; isolation limits the blast radius of the ones nobody has found yet. ## How my own setup handles this I run the web server and every site gets its **own unprivileged Linux user with its own PHP-FPM pool**. That is the isolation point in practice: if a crafted image ever executes code in one site's processing pipeline, it runs as that site's user and nothing more. It can ruin that one site — its files, its database credentials — but it cannot reach the neighbour next door or climb to root without a second, separate vulnerability. "One bug = one site," not "one bug = the whole box." For patching, I lean on unattended security updates, scoped to the `-security` pocket only, with automatic reboots switched off. Ordinary feature updates I still apply by hand after a glance, but the security fixes — the ones that matter for this exact threat — install themselves overnight. When I actually checked the logs while writing this, the machine had auto-installed `libaom` just days earlier: the AV1 codec that libheif uses to decode AVIF. The pipeline was quietly patching the very image-decoding chain this whole story is about, without me touching it. The original research is Hacktron's: [Hacking OpenAI](https://www.hacktron.ai/blog/hacking-openai).