JPEG XL 在 iOS 信息预览路径中自动解码

针对 CVE-2026-28956（AppleJPEGXL）的投递面发现，以及补丁差异归因和对公开 PoC 可靠性的现实核查。

TL;DR — 传统认知（以及我们此前用 EXR 进行的测量）认为 iOS 信息会将非 JPEG/PNG/HEIC 附件渲染为通用文件块而不进行解码。JPEG XL 打破了这一假设：.jxl 附件在信息预览路径中确实会被交给解码器处理。我们观察到 MobileSMS 中的 ImageIO 在收到内容时即尝试解码 JXL 数据，全程无需用户交互。这使得 AppleJPEGXL 成为活跃的零点击攻击面，而 EXR 类格式则不具备这一特性。

目录

发现

通过 iMessage（蓝色气泡传输，根据发送方 chat.db 确认字节完整）向一台运行 iOS 18.6.2 的实体 iPhone 发送了三个附件，同时使用 idevicesyslog 监控解码面：

1. poc.jxl（UTI public.jpeg-xl）
2. poc_brand.heic（相同字节，brand 为 heic）
3. poc_mif1.heic（brand 为 mif1）

设备日志（MobileSMS）：

MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]

有两点值得注意：

• 解码器确实运行了。 作为对比，相同设置下的 EXR 附件不会产生任何解码活动 — 信息仅显示文件图标，从不调用解码器。JXL 则被视为值得在预览中解码的图像。
• 内容嗅探优先于声明的 brand。 带有 .heic brand 的变体也通过魔数被嗅探为 'JXL ' 并路由至 JXL 解码器，因此 .heic 文件名不会将解析导向 HEIF 读取器 — 反之，普通的 .jxl 附件已经能够到达 AppleJPEGXL。投递无需任何容器技巧。

-58 错误是旧版（iOS 18.6.2）解码器拒绝格式错误的重复 jxlc 结构；关键在于解析确实发生了。

现实核查（坦诚说明）

攻击面开放并不意味着公开 PoC 就是一个可用的零点击漏洞：

• 149 字节的公开触发器在 iOS 26.4.2、iOS 18.6.2 或 macOS 26.3.1 上通过裸 CGImageSource 解码均不会崩溃（在 MallocScribble 下 10/10 次运行，外加 8 倍重复触发器变体）。
• 一系列专门构造的恶意帧文件（精心设计的 frame_origin 偏移，针对上游实际修复所加固的低内存渲染管线路径 — libjxl PR #4495）在 iOS 26.4.2 上同样干净解码。
• 作者自己的分析文章也指出其根因分析可能不完整，且其崩溃证据是在 macOS Safari 中借助 interpose 库产生的。

因此：投递零点击已得到证实；可靠触发则尚未实现。 Apple 修复的漏洞是真实存在的（参见 DIFF.md — 低内存管线中的 Plane/float 拷贝已被重写并加固），但要在 iOS 上将其转化为确定性的内存破坏，是一个公开工件尚未解决的武器化难题。

为何仍要发布

我们询问的每个人（以及我们自己的 EXR 实验）都假设非 JPEG/PNG/HEIC 附件不会在信息预览中被解码。但 JXL 会。这是对零点击攻击面的一次具体、可验证的扩展，也意味着 AppleJPEGXL 的漏洞应当以 iMessage 投递为考量来挖掘，而不仅仅局限于 WebContent。

仅供教育和防御性研究使用。请仅在您自己拥有的硬件上进行测试。