eddinos2/cve-2026-28956-jxl-messages-surfaceJPEG XL se auto-decodifica en la ruta de vista previa de Mensajes de iOS: hallazgo de superficie de entrega para CVE-2026-28956 (AppleJPEGXL), con atribución de diff de parche (libjxl 0.10.4->0.10.5) y una verificación honesta de fiabilidad sobre el PoC público.
Un hallazgo sobre la superficie de entrega para CVE-2026-28956 (AppleJPEGXL), además de la atribución mediante diff de parches y una verificación de fiabilidad sobre el PoC público.
TL;DR — La sabiduría convencional (y nuestra propia medición previa con EXR) sostiene que Mensajes de iOS renderiza los adjuntos que no son JPEG/PNG/HEIC como blobs de archivo genéricos sin decodificarlos. JPEG XL rompe esa suposición: un adjunto .jxl sí se entrega al decodificador en la ruta de vista previa de Mensajes. Observamos que ImageIO dentro de MobileSMS intentaba decodificar contenido JXL al recibirlo, sin interacción del usuario. Eso convierte a AppleJPEGXL en una superficie de ataque zero-click viva, de una manera que los formatos de clase EXR no lo son.
| archivo | qué es |
|---|
PROBE_RESULT.md | La sonda de superficie de entrega: configuración, evidencia del remitente, syslog del dispositivo mostrando los intentos de decodificación, niveles de veredicto |
DIFF.md | Diff de parches iOS 26.4.2 vs 26.5: CVE-2026-28956 atribuido a AppleJPEGXL (libjxl 0.10.4 → 0.10.5); candidatos a CVE-2026-43661 en ImageIO |
pocs/poc.jxl | El disparador público de 149 bytes (del writeup del autor), usado como payload de la sonda |
pocs/poc_brand.heic, pocs/poc_mif1.heic | Los mismos bytes con la marca ftyp cambiada a heic / mif1 — usados para probar el content-sniffing frente a la UTI declarada |
pocs/jxldec.m | Harness mínimo de decodificación CGImageSource (compila de forma cruzada para iOS), usado para pruebas de decodificación en el dispositivo |
Se enviaron tres adjuntos por iMessage (transporte azul, bytes intactos según el chat.db del remitente) a un iPhone físico con iOS 18.6.2, con idevicesyslog observando las superficies de decodificación:
poc.jxl (UTI public.jpeg-xl)poc_brand.heic (mismos bytes, marca heic)poc_mif1.heic (marca mif1)Registro del dispositivo (MobileSMS):
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]
Dos cosas destacan:
.heic también fueron detectadas como 'JXL ' por los magic bytes y enrutadas al decodificador JXL, así que un nombre de archivo .heic no dirige el parseo al lector HEIF — y, a la inversa, un adjunto .jxl simple ya llega a AppleJPEGXL. No se necesita ningún truco de contenedor para la entrega.Los errores -58 son el decodificador más antiguo (iOS 18.6.2) rechazando la estructura malformada de jxlc duplicado; el punto es que el parseo ocurrió.
Que la superficie esté abierta no convierte al PoC público en un zero-click funcional:
frame_origin elaborados, apuntando a la ruta del pipeline de renderizado de baja memoria que el fix upstream real refuerza — libjxl PR #4495) también se decodifican limpiamente en iOS 26.4.2.Así que: la entrega zero-click está probada; el disparo fiable no lo está. El bug que Apple parcheó es real (ver DIFF.md — el pipeline de baja memoria con copia Plane/float fue reescrito y reforzado), pero convertirlo en una corrupción de memoria determinista en iOS es un problema de weaponización que el artefacto público no resuelve.
Todos a quienes preguntamos (y nuestro propio experimento con EXR) asumían que los adjuntos que no son JPEG/PNG/HEIC no se decodifican en la vista previa de Mensajes. JXL sí. Esa es una expansión concreta y comprobable de la superficie de ataque zero-click, y significa que los bugs de AppleJPEGXL merecen cazarse teniendo en mente la entrega por iMessage, no solo WebContent.
Con fines educativos y de investigación defensiva. Prueba solo en hardware que poseas.