eddinos2/cve-2026-28956-jxl-messages-surfaceJPEG XL é auto-decodificado no caminho de pré-visualização do Mensagens do iOS — descoberta de superfície de entrega para CVE-2026-28956 (AppleJPEGXL), com atribuição por diff de patch (libjxl 0.10.4->0.10.5) e uma verificação honesta de confiabilidade sobre o PoC público.
Uma descoberta de superfície de entrega para CVE-2026-28956 (AppleJPEGXL), além da atribuição por diff de patch e uma verificação de realidade sobre a confiabilidade do PoC público.
TL;DR — O conhecimento convencional (e nossa própria medição anterior com EXR) é
que o Messages no iOS renderiza anexos não-JPEG/PNG/HEIC como blobs de arquivo genéricos
sem decodificá-los. JPEG XL quebra essa suposição: um anexo .jxl
é entregue ao decodificador no caminho de pré-visualização do Messages. Observamos
o ImageIO dentro do MobileSMS tentar decodificar conteúdo JXL no recebimento, sem
nenhuma interação do usuário. Isso torna o AppleJPEGXL uma superfície de ataque zero-click viva de uma forma
que formatos da classe EXR não são.
| arquivo | o quê |
|---|
PROBE_RESULT.md | A sonda da superfície de entrega: configuração, evidência do remetente, syslog do dispositivo mostrando as tentativas de decodificação, níveis de veredito |
DIFF.md | Diff de patch iOS 26.4.2 vs 26.5: CVE-2026-28956 atribuída ao AppleJPEGXL (libjxl 0.10.4 → 0.10.5); candidatos a CVE-2026-43661 no ImageIO |
pocs/poc.jxl | O gatilho público de 149 bytes (do writeup do autor), usado como payload da sonda |
pocs/poc_brand.heic, pocs/poc_mif1.heic | Os mesmos bytes com a marca ftyp alterada para heic / mif1 — usados para testar detecção de conteúdo vs UTI declarada |
pocs/jxldec.m | Harness mínimo de decodificação CGImageSource (compila de forma cruzada para iOS), usado para testes de decodificação no dispositivo |
Três anexos foram enviados via iMessage (transporte azul, bytes intactos conforme o
chat.db do remetente) para um iPhone físico com iOS 18.6.2, com idevicesyslog
monitorando as superfícies de decodificação:
poc.jxl (UTI public.jpeg-xl)poc_brand.heic (mesmos bytes, marca heic)poc_mif1.heic (marca mif1)Log do dispositivo (MobileSMS):
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]
Duas coisas se destacam:
.heic
também foram detectadas como 'JXL ' pelos bytes mágicos e roteadas para o decodificador JXL,
então um nome de arquivo .heic não direciona o parse para o leitor HEIF — e,
inversamente, um anexo .jxl simples já alcança o AppleJPEGXL. Nenhum
truque de contêiner é necessário para a entrega.Os erros -58 são o decodificador mais antigo (iOS 18.6.2) rejeitando a estrutura
malformada de jxlc duplicado; o ponto é que o parse aconteceu.
A superfície estar aberta não torna o PoC público um zero-click funcional:
frame_origin
elaborados, visando o caminho do pipeline de renderização de baixa memória que o
fix upstream real endurece — libjxl PR #4495) também decodifica limpo no iOS 26.4.2.Então: entrega zero-click é comprovada; disparo confiável não é. O bug que a Apple
corrigiu é real (veja DIFF.md — o pipeline de baixa memória de cópia Plane/float foi
reescrito e endurecido), mas transformá-lo em uma corrupção de memória determinística
no iOS é um problema de weaponização que o artefato público não resolve.
Todos a quem perguntamos (e nosso próprio experimento com EXR) assumiram que anexos não-JPEG/PNG/HEIC não são decodificados na pré-visualização do Messages. JXL é. Essa é uma expansão concreta e testável da superfície de ataque zero-click, e significa que bugs do AppleJPEGXL merecem ser caçados tendo a entrega via iMessage em mente, não apenas WebContent.
Para fins educacionais e de pesquisa defensiva. Teste apenas em hardware que você possui.