eddinos2/cve-2026-28956-jxl-messages-surfaceJPEG XL auto-decodes im iOS-Messages-Vorschau-Pfad — Delivery-Surface-Fund für CVE-2026-28956 (AppleJPEGXL), mit Patch-Diff-Zuordnung (libjxl 0.10.4->0.10.5) und einem ehrlichen Zuverlässigkeitscheck des öffentlichen PoC.
Ein Delivery-Surface-Fund für CVE-2026-28956 (AppleJPEGXL), plus die Patch-Diff-Zuordnung und ein ehrlicher Realitätscheck zum öffentlichen PoC.
TL;DR — Die allgemeine Annahme (und auch unsere eigene frühere Messung mit EXR) ist,
dass iOS Messages Nicht-JPEG/PNG/HEIC-Anhänge als generische Datei-Blobs rendert,
ohne sie zu dekodieren. JPEG XL durchbricht diese Annahme: Ein .jxl-Anhang
wird im Messages-Vorschau-Pfad an den Dekoder übergeben. Wir haben beobachtet, dass
ImageIO innerhalb von MobileSMS beim Empfang versucht, JXL-Inhalte zu dekodieren, ohne
jegliche Benutzerinteraktion. Das macht AppleJPEGXL zu einer aktiven Zero-Click-Angriffsfläche,
anders als Formate der EXR-Klasse.
| Datei | Inhalt |
|---|
PROBE_RESULT.md | Die Delivery-Surface-Sonde: Aufbau, Sender-Nachweise, Geräte-Syslog mit den Dekodierungsversuchen, Bewertungsstufen |
DIFF.md | Patch-Diff iOS 26.4.2 vs. 26.5: CVE-2026-28956 AppleJPEGXL zugeordnet (libjxl 0.10.4 → 0.10.5); CVE-2026-43661-Kandidaten in ImageIO |
pocs/poc.jxl | Der öffentliche 149-Byte-Trigger (aus dem Writeup des Autors), verwendet als Sonden-Payload |
pocs/poc_brand.heic, pocs/poc_mif1.heic | Dieselben Bytes mit geändertem ftyp-Brand auf heic / mif1 — zum Testen von Content-Sniffing vs. deklarierter UTI |
pocs/jxldec.m | Minimaler CGImageSource-Dekodierungs-Harness (Cross-Compile für iOS), verwendet für On-Device-Dekodierungstests |
Drei Anhänge wurden über iMessage (blauer Transport, byte-intakt laut
Sender-chat.db) an ein physisches iPhone mit iOS 18.6.2 gesendet, während
idevicesyslog die Dekodierungsflächen beobachtete:
poc.jxl (UTI public.jpeg-xl)poc_brand.heic (gleiche Bytes, Brand heic)poc_mif1.heic (Brand mif1)Geräte-Log (MobileSMS):
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]
Zwei Dinge fallen auf:
.heic-gebrandeten
Varianten wurden ebenfalls per Magic-Bytes als 'JXL ' erkannt und an den JXL-Dekoder
weitergeleitet, sodass ein .heic-Dateiname den Parse nicht zum HEIF-Reader lenkt — und
umgekehrt erreicht ein schlichter .jxl-Anhang bereits AppleJPEGXL. Für die Zustellung
ist keine Container-Trickserei nötig.Die -58-Fehler stammen vom älteren (iOS 18.6.2) Dekoder, der die fehlerhafte
duplizierte jxlc-Struktur ablehnt; der Punkt ist, dass der Parse stattfand.
Dass die Fläche offen ist, macht den öffentlichen PoC noch nicht zu einem funktionierenden Zero-Click:
frame_origin-
Offsets, die auf den Low-Memory-Render-Pipeline-Pfad zielen, den der eigentliche
Upstream-Fix härtet — libjxl PR #4495) dekodieren ebenfalls sauber auf iOS 26.4.2.Also: Zustellung 0-Click ist bewiesen; zuverlässiges Triggern nicht. Der von Apple
gepatchte Bug ist real (siehe DIFF.md — die Plane/Float-Kopie der Low-Memory-Pipeline
wurde neu geschrieben und gehärtet), aber ihn in eine deterministische Speicherkorruption
auf iOS zu verwandeln, ist ein Weaponization-Problem, das das öffentliche Artefakt nicht löst.
Jeder, den wir gefragt haben (und unser eigenes EXR-Experiment), nahm an, dass Nicht-JPEG/PNG/HEIC-Anhänge in der Messages-Vorschau nicht dekodiert werden. JXL tut es. Das ist eine konkrete, testbare Erweiterung der Zero-Click-Angriffsfläche, und es bedeutet, dass AppleJPEGXL-Bugs mit Blick auf iMessage-Zustellung gejagt werden sollten, nicht nur auf WebContent.
Für Bildungs- und defensive Forschungszwecke. Nur auf Hardware testen, die dir gehört.