JPEG XL auto-decodes in the iOS Messages preview path

A delivery-surface finding for CVE-2026-28956 (AppleJPEGXL), plus the patch-diff attribution and a reliability reality-check on the public PoC.

TL;DR — Conventional wisdom (and our own prior measurement with EXR) is that iOS Messages renders non-JPEG/PNG/HEIC attachments as generic file blobs without decoding them. JPEG XL breaks that assumption: a .jxl attachment is handed to the decoder in the Messages preview path. We observed ImageIO inside MobileSMS attempt to decode JXL content on receipt, with no user interaction. That makes AppleJPEGXL a live zero-click attack surface in a way EXR-class formats are not.

Contents

The finding

Three attachments were sent over iMessage (blue transport, byte-intact per sender chat.db) to a physical iPhone on iOS 18.6.2, with idevicesyslog watching the decode surfaces:

1. poc.jxl (UTI public.jpeg-xl)
2. poc_brand.heic (same bytes, brand heic)
3. poc_mif1.heic (brand mif1)

Device log (MobileSMS):

MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]

Two things stand out:

• The decoder ran at all. For comparison, an EXR attachment in the same setup produces no decode activity — Messages shows a file icon and never invokes the decoder. JXL is treated as an image worth decoding in preview.
• Content sniffing beats the declared brand. The .heic-branded variants were also sniffed as 'JXL ' by magic bytes and routed to the JXL decoder, so a .heic filename does not steer the parse to the HEIF reader — and conversely a plain .jxl attachment already reaches AppleJPEGXL. No container trickery is needed for delivery.

The -58 errors are the older (iOS 18.6.2) decoder rejecting the malformed duplicate-jxlc structure; the point is that the parse happened.

The reality check (honest)

The surface being open does not make the public PoC a working zero-click:

• The 149-byte public trigger does not crash on iOS 26.4.2, iOS 18.6.2, or macOS 26.3.1 through a bare CGImageSource decode (10/10 runs under MallocScribble, plus an 8× duplicated-trigger variant).
• A battery of purpose-built hostile-frame files (crafted frame_origin offsets, targeting the low-memory-render-pipeline path the actual upstream fix hardens — libjxl PR #4495) also decode cleanly on iOS 26.4.2.
• The author's own writeup notes their root-cause analysis may be incomplete and their crash evidence was produced in macOS Safari with an interpose library.

So: delivery 0-click is proven; reliable triggering is not. The bug Apple patched is real (see DIFF.md — the low-memory pipeline Plane/float copy was rewritten and hardened), but turning it into a deterministic memory-corruption on iOS is a weaponization problem the public artifact does not solve.

Why publish anyway

Everyone we asked (and our own EXR experiment) assumed non-JPEG/PNG/HEIC attachments don't get decoded in Messages preview. JXL does. That is a concrete, testable expansion of the zero-click attack surface, and it means AppleJPEGXL bugs deserve to be hunted with iMessage delivery in mind, not only WebContent.

For educational and defensive research purposes. Test only on hardware you own.