eddinos2/cve-2026-28956-jxl-messages-surfaceJPEG XL si auto-decodifica nel percorso di anteprima di iOS Messages — risultato sulla superficie di consegna per CVE-2026-28956 (AppleJPEGXL), con attribuzione tramite diff delle patch (libjxl 0.10.4->0.10.5) e una verifica onesta dell'affidabilità del PoC pubblico.
Un risultato sulla superficie di consegna per CVE-2026-28956 (AppleJPEGXL), oltre all'attribuzione tramite patch-diff e una verifica realistica di affidabilità sul PoC pubblico.
TL;DR — La saggezza convenzionale (e la nostra stessa precedente misurazione con EXR) sostiene che iOS Messages renda gli allegati non-JPEG/PNG/HEIC come blob di file generici senza decodificarli. JPEG XL infrange questa assunzione: un allegato .jxl viene passato al decoder nel percorso di anteprima di Messages. Abbiamo osservato ImageIO all'interno di MobileSMS tentare di decodificare contenuto JXL alla ricezione, senza alcuna interazione da parte dell'utente. Questo rende AppleJPEGXL una superficie di attacco zero-click viva in un modo che i formati di classe EXR non sono.
| file | cosa |
|---|
PROBE_RESULT.md | La sonda sulla superficie di consegna: configurazione, prove dal mittente, syslog del dispositivo che mostra i tentativi di decodifica, livelli di verdetto |
DIFF.md | Patch-diff iOS 26.4.2 vs 26.5: CVE-2026-28956 attribuita ad AppleJPEGXL (libjxl 0.10.4 → 0.10.5); candidati CVE-2026-43661 in ImageIO |
pocs/poc.jxl | Il trigger pubblico da 149 byte (dal writeup dell'autore), usato come payload della sonda |
pocs/poc_brand.heic, pocs/poc_mif1.heic | Gli stessi byte con il brand ftyp cambiato in heic / mif1 — usati per testare il content-sniffing rispetto all'UTI dichiarato |
pocs/jxldec.m | Harness minimale di decodifica CGImageSource (cross-compila per iOS), usato per i test di decodifica su dispositivo |
Tre allegati sono stati inviati tramite iMessage (trasporto blu, byte-intatti secondo il chat.db del mittente) a un iPhone fisico con iOS 18.6.2, con idevicesyslog a osservare le superfici di decodifica:
poc.jxl (UTI public.jpeg-xl)poc_brand.heic (stessi byte, brand heic)poc_mif1.heic (brand mif1)Log del dispositivo (MobileSMS):
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]
Due cose risaltano:
.heic
sono state anch'esse identificate come 'JXL ' tramite magic bytes e instradate al decoder JXL,
quindi un nome file .heic non indirizza il parsing al lettore HEIF — e
viceversa un semplice allegato .jxl raggiunge già AppleJPEGXL. Nessun
trucco sul contenitore è necessario per la consegna.Gli errori -58 sono il decoder più vecchio (iOS 18.6.2) che rifiuta la struttura
malformata con jxlc duplicato; il punto è che il parsing è avvenuto.
Che la superficie sia aperta non rende il PoC pubblico uno zero-click funzionante:
frame_origin
modificati, mirati al percorso della pipeline di rendering a bassa memoria che la
correzione upstream effettiva indurisce — libjxl PR #4495) decodifica anch'essa senza errori su iOS 26.4.2.Quindi: la consegna zero-click è provata; il trigger affidabile no. Il bug che Apple
ha corretto è reale (vedi DIFF.md — la copia Plane/float della pipeline a bassa memoria è stata
riscritta e indurita), ma trasformarlo in una corruzione di memoria deterministica
su iOS è un problema di weaponization che l'artefatto pubblico non risolve.
Tutti quelli a cui abbiamo chiesto (e il nostro stesso esperimento EXR) assumevano che gli allegati non-JPEG/PNG/HEIC non vengano decodificati nell'anteprima di Messages. JXL invece sì. Questa è un'espansione concreta e testabile della superficie di attacco zero-click, e significa che i bug di AppleJPEGXL meritano di essere cacciati pensando alla consegna via iMessage, non solo a WebContent.
A scopo di ricerca educativa e difensiva. Testa solo su hardware di tua proprietà.