
CVE-2026-28956(AppleJPEGXL)に関する配信サーフェスの発見、パッチ差分の帰属、および公開PoCの信頼性に関する現実的な検証。
要約 — 従来の通説(およびEXRを用いた我々自身の先行測定)では、iOS MessagesはJPEG/PNG/HEIC以外の添付ファイルをデコードせずに汎用ファイルブロブとしてレンダリングするとされていました。JPEG XLはその前提を覆します:.jxl添付ファイルはMessagesプレビューパスでデコーダに渡されます。我々はMobileSMS内のImageIOが、ユーザー操作なしに受信時にJXLコンテンツのデコードを試みることを観測しました。これによりAppleJPEGXLは、EXRクラスのフォーマットにはない形で、実際に機能するゼロクリック攻撃サーフェスとなります。
| ファイル | 内容 |
|---|---|
PROBE_RESULT.md | 配信サーフェスのプローブ:セットアップ、送信者エビデンス、デコード試行を示すデバイスsyslog、判定ティア |
DIFF.md | iOS 26.4.2 vs 26.5のパッチ差分:CVE-2026-28956はAppleJPEGXL(libjxl 0.10.4 → 0.10.5)に帰属;ImageIO内のCVE-2026-43661候補 |
pocs/poc.jxl | 公開されている149バイトのトリガー(作者のwriteupより)、プローブペイロードとして使用 |
pocs/poc_brand.heic、pocs/poc_mif1.heic | ftypブランドをheic/mif1に変更した同一バイト列 — コンテンツスニッフィングと宣言UTIの比較テストに使用 |
pocs/jxldec.m | 最小限のCGImageSourceデコードハーネス(iOS用にクロスコンパイル)、オンデバイスデコードテストに使用 |
iOS 18.6.2を搭載した物理iPhoneに対し、iMessage(ブルートランスポート、送信者chat.db上でバイト完全一致)経由で3つの添付ファイルが送信され、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]
2つの点が際立ちます:
.heicブランドの亜種もマジックバイトによって'JXL 'としてスニッフィングされ、JXLデコーダにルーティングされました。つまり.heicファイル名は解析をHEIFリーダーに誘導せず — 逆にプレーンな.jxl添付ファイルはすでにAppleJPEGXLに到達します。配信にコンテナの細工は不要です。-58エラーは、古い(iOS 18.6.2)デコーダが不正な重複jxlc構造を拒否したものです。重要なのは解析が実行されたという事実です。
サーフェスが開かれていることは、公開PoCが機能するゼロクリックであることを意味しません:
frame_originオフセット、実際のアップストリーム修正が強化する低メモリレンダーパイプライン経路を標的 — libjxl PR #4495)も、iOS 26.4.2でクリーンにデコードされます。つまり:配信のゼロクリックは証明済み。信頼性のあるトリガーは未証明。 Appleが修正したバグは実在します(DIFF.md参照 — 低メモリパイプラインのPlane/floatコピーが書き直され強化されました)が、それをiOS上で決定的なメモリ破壊に転換することは、公開アーティファクトでは解決されていない武器化の問題です。
我々が尋ねた全員(および我々自身のEXR実験)は、JPEG/PNG/HEIC以外の添付ファイルはMessagesプレビューでデコードされないと想定していました。JXLはデコードされます。これはゼロクリック攻撃サーフェスの具体的かつテスト可能な拡張であり、AppleJPEGXLのバグはWebContentだけでなくiMessage配信を念頭に置いて調査される価値があることを意味します。
教育および防御的研究目的のためです。所有するハードウェアでのみテストしてください。