eddinos2/cve-2026-28956-jxl-messages-surfaceJPEG XL se décode automatiquement dans le chemin d'aperçu de Messages sur iOS — constat de surface de livraison pour CVE-2026-28956 (AppleJPEGXL), avec attribution par diff de correctif (libjxl 0.10.4->0.10.5) et une vérification honnête de fiabilité sur le PoC public.
Une découverte de surface de livraison pour CVE-2026-28956 (AppleJPEGXL), plus l'attribution par diff de correctif et une vérification de fiabilité sur le PoC public.
TL;DR — La sagesse conventionnelle (et notre propre mesure antérieure avec EXR) veut
que Messages sur iOS rende les pièces jointes non-JPEG/PNG/HEIC comme des blobs de fichiers
génériques sans les décoder. Le JPEG XL brise cette hypothèse : une pièce jointe .jxl
est transmise au décodeur dans le chemin d'aperçu de Messages. Nous avons observé
ImageIO dans MobileSMS tenter de décoder du contenu JXL à la réception, sans
aucune interaction utilisateur. Cela fait d'AppleJPEGXL une surface d'attaque zero-click
vivante, d'une manière que les formats de classe EXR ne sont pas.
| fichier | description |
|---|
PROBE_RESULT.md | La sonde de surface de livraison : configuration, preuves de l'expéditeur, syslog de l'appareil montrant les tentatives de décodage, niveaux de verdict |
DIFF.md | Diff de correctif iOS 26.4.2 vs 26.5 : CVE-2026-28956 attribuée à AppleJPEGXL (libjxl 0.10.4 → 0.10.5) ; candidats CVE-2026-43661 dans ImageIO |
pocs/poc.jxl | Le déclencheur public de 149 octets (issu du writeup de l'auteur), utilisé comme charge utile de la sonde |
pocs/poc_brand.heic, pocs/poc_mif1.heic | Les mêmes octets avec la marque ftyp changée en heic / mif1 — utilisés pour tester le sniffing de contenu par rapport à l'UTI déclarée |
pocs/jxldec.m | Harnais minimal de décodage CGImageSource (cross-compilé pour iOS), utilisé pour les tests de décodage sur appareil |
Trois pièces jointes ont été envoyées via iMessage (transport bleu, octets intacts selon
le chat.db de l'expéditeur) vers un iPhone physique sous iOS 18.6.2, avec idevicesyslog
surveillant les surfaces de décodage :
poc.jxl (UTI public.jpeg-xl)poc_brand.heic (mêmes octets, marque heic)poc_mif1.heic (marque mif1)Journal de l'appareil (MobileSMS) :
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]
Deux choses ressortent :
.heic
ont également été détectées comme 'JXL ' par octets magiques et routées vers le décodeur JXL,
donc un nom de fichier .heic n'oriente pas l'analyse vers le lecteur HEIF — et
inversement, une pièce jointe .jxl ordinaire atteint déjà AppleJPEGXL. Aucune
astuce de conteneur n'est nécessaire pour la livraison.Les erreurs -58 proviennent du décodeur plus ancien (iOS 18.6.2) rejetant la structure
malformée jxlc dupliquée ; le point est que l'analyse a eu lieu.
Le fait que la surface soit ouverte ne fait pas du PoC public un zero-click fonctionnel :
frame_origin
élaborés, ciblant le chemin du pipeline de rendu basse mémoire que le correctif
amont réel durcit — libjxl PR #4495) se décodent également proprement sur iOS 26.4.2.Donc : la livraison zero-click est prouvée ; le déclenchement fiable ne l'est pas. Le bug
qu'Apple a corrigé est réel (voir DIFF.md — le pipeline basse mémoire de copie Plane/float a été
réécrit et durci), mais le transformer en corruption mémoire déterministe
sur iOS est un problème d'armement que l'artefact public ne résout pas.
Tous ceux à qui nous avons demandé (et notre propre expérience EXR) supposaient que les pièces jointes non-JPEG/PNG/HEIC ne sont pas décodées dans l'aperçu de Messages. JXL l'est. C'est une expansion concrète et testable de la surface d'attaque zero-click, et cela signifie que les bugs d'AppleJPEGXL méritent d'être chassés en gardant la livraison iMessage à l'esprit, pas seulement WebContent.
À des fins de recherche éducative et défensive. Testez uniquement sur du matériel que vous possédez.