One Pixel Too Many: A 0-Click Flaw in Apple's EXR Decoder

A security researcher at ironPeak has published a breakdown of a flaw that Apple classified as "0-click code execution via an iMessage EXR image payload" and patched in September 2026 as CVE-2026-86869.

A one-number bug

At its heart is a classic channel-count confusion. The libAppleEXR.dylib decoder, wired into the ImageIO subsystem, allocated a buffer for an RGB image: three channels, a 32-bit float each, twelve bytes per pixel. But the fill routine wrote four channels — red, green, blue and a hardcoded alpha of 1.0 — sixteen bytes in all. Every pixel spilled four bytes past its reserved space, and the overrun accumulated row after row. On a 448×448 image that is roughly 800 kilobytes of heap written beyond the allocation.

Worse still, twelve of those sixteen bytes came straight from the file's pixel data, meaning they were attacker-controlled; only the alpha stayed fixed. The overflow was not merely a crash but a steerable write into memory.

Zero clicks

The truly dangerous part was the path that triggered it. EXR is not on the list of formats handled by BlastDoor, the sandbox Apple built precisely to defend against such iMessage attacks. And the decode did not happen in message parsing at all. When an attachment arrived, the system saved it, indexed it for search, and handed it to the photo subsystem. A background worker generating thumbnails built its decode request with the standard-dynamic-range option hardcoded on — the very option that flipped the decoder onto the vulnerable path.

As a result, the overflow fired inside a privileged daemon before the notification banner had finished sliding in. The victim opened nothing and tapped nothing.

How it was found, and how bad it is

The author says he reached the bug through LLM-guided fuzzing: a model read the disassembly and proposed mutations that kept the file structurally valid. A static anomaly — a mismatch between the allocation size and the write stride — turned into a real crash, then into a controlled overflow and, on the bench, into program-counter control.

He is candid about the limits, though. On the newest silicon, hardware memory tagging and Pointer Authentication raise the bar for exploitation. But tagging is enabled only for a single daemon on the latest chips, while the vast fleet of older devices has no such protection. Until each device updates, it stays vulnerable. For that reason the post deliberately keeps the file-crafting and heap-grooming details at a conceptual level.

Source: Lobsters