eddinos2/cve-2026-28956-jxl-messages-surfaceJPEG XL автоматически декодируется в пути предпросмотра iOS Messages — находка поверхности доставки для CVE-2026-28956 (AppleJPEGXL), с атрибуцией по диффу патча (libjxl 0.10.4->0.10.5) и честной проверкой надёжности публичного PoC.
Находка поверхности доставки для CVE-2026-28956 (AppleJPEGXL), а также атрибуция по патч-диффу и проверка реальности публичного PoC.
TL;DR — Общепринятое мнение (и наши собственные предыдущие измерения с EXR)
заключается в том, что iOS Messages отображает вложения, не являющиеся JPEG/PNG/HEIC,
как общие файловые блобы без их декодирования. JPEG XL разрушает это предположение:
.jxl-вложение передаётся декодеру в пути предпросмотра Messages. Мы наблюдали,
как ImageIO внутри MobileSMS пытался декодировать JXL-контент при получении, без
какого-либо взаимодействия с пользователем. Это делает AppleJPEGXL живой
zero-click поверхностью атаки так, как форматы класса EXR — нет.
| файл | что это |
|---|
PROBE_RESULT.md | Зонд поверхности доставки: настройка, доказательства от отправителя, системный журнал устройства с попытками декодирования, уровни вердикта |
DIFF.md | Патч-дифф iOS 26.4.2 против 26.5: CVE-2026-28956 атрибутирован AppleJPEGXL (libjxl 0.10.4 → 0.10.5); кандидаты CVE-2026-43661 в ImageIO |
pocs/poc.jxl | Публичный триггер из 149 байт (из статьи автора), использованный как полезная нагрузка зонда |
pocs/poc_brand.heic, pocs/poc_mif1.heic | Те же байты с изменённым брендом ftyp на heic / mif1 — для проверки сниффинга контента против объявленного UTI |
pocs/jxldec.m | Минимальный харнесс декодирования CGImageSource (кросс-компилируется для iOS), использованный для тестов декодирования на устройстве |
Три вложения были отправлены через iMessage (синий транспорт, байт-в-байт
целостность по chat.db отправителя) на физический iPhone под iOS 18.6.2,
с idevicesyslog, наблюдающим за поверхностями декодирования:
poc.jxl (UTI public.jpeg-xl)poc_brand.heic (те же байты, бренд heic)poc_mif1.heic (бренд mif1)Журнал устройства (MobileSMS):
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]
Выделяются две вещи:
.heic также были определены как 'JXL ' по магическим байтам и
направлены в JXL-декодер, так что имя файла .heic не направляет разбор
в HEIF-ридер — и, наоборот, обычное .jxl-вложение уже достигает
AppleJPEGXL. Никаких ухищрений с контейнером для доставки не требуется.Ошибки -58 — это более старый (iOS 18.6.2) декодер, отклоняющий
некорректную дублированную структуру jxlc; суть в том, что разбор произошёл.
Открытая поверхность не делает публичный PoC работающим zero-click:
frame_origin, нацеленные на путь низкопамятного конвейера
рендеринга, который укрепляет реальный апстрим-фикс — libjxl PR #4495)
также декодируется чисто на iOS 26.4.2.Итак: доставка 0-click доказана; надёжный триггер — нет. Баг, который
Apple пропатчила, реален (см. DIFF.md — копирование Plane/float в
низкопамятном конвейере было переписано и укреплено), но превращение его в
детерминированное повреждение памяти на iOS — это проблема вепонизации,
которую публичный артефакт не решает.
Все, кого мы спрашивали (и наш собственный эксперимент с EXR), предполагали, что вложения, не являющиеся JPEG/PNG/HEIC, не декодируются в предпросмотре Messages. JXL — декодируется. Это конкретное, проверяемое расширение zero-click поверхности атаки, и это означает, что баги AppleJPEGXL заслуживают охоты с учётом доставки через iMessage, а не только WebContent.
Для образовательных и защитных исследовательских целей. Тестируйте только на оборудовании, которым владеете.