JPEG XL iOS Messages पूर्वावलोकन पथ में स्वतः-डिकोड होता है

CVE-2026-28956 (AppleJPEGXL) के लिए एक डिलीवरी-सतह खोज, साथ ही पैच-डिफ विशेषता और सार्वजनिक PoC पर विश्वसनीयता की वास्तविकता-जांच।

TL;DR — पारंपरिक ज्ञान (और EXR के साथ हमारा अपना पिछला मापन) यह है कि iOS Messages गैर-JPEG/PNG/HEIC अटैचमेंट को बिना डिकोड किए सामान्य फ़ाइल ब्लॉब के रूप में प्रस्तुत करता है। JPEG XL उस धारणा को तोड़ता है: एक .jxl अटैचमेंट Messages पूर्वावलोकन पथ में डिकोडर को सौंपा जाता है। हमने 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 (समान बाइट्स, ब्रांड heic)
3. 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]

दो चीज़ें स्पष्ट रूप से सामने आती हैं:

• डिकोडर बिल्कुल चला। तुलना के लिए, उसी सेटअप में एक EXR अटैचमेंट कोई डिकोड गतिविधि उत्पन्न नहीं करता — Messages एक फ़ाइल आइकन दिखाता है और डिकोडर को कभी आमंत्रित नहीं करता। JXL को पूर्वावलोकन में डिकोड करने योग्य एक छवि के रूप में माना जाता है।
• सामग्री स्निफिंग घोषित ब्रांड से आगे निकल जाती है। .heic-ब्रांडेड वेरिएंट को भी मैजिक बाइट्स द्वारा '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 में एक इंटरपोज़ लाइब्रेरी के साथ उत्पन्न किया गया था।

इसलिए: डिलीवरी 0-क्लिक सिद्ध है; विश्वसनीय ट्रिगरिंग नहीं है। Apple द्वारा पैच किया गया बग वास्तविक है (देखें DIFF.md — कम-मेमोरी पाइपलाइन Plane/float कॉपी को फिर से लिखा और सख्त किया गया था), लेकिन इसे iOS पर एक निर्धारक मेमोरी-भ्रष्टाचार में बदलना एक हथियारीकरण समस्या है जिसे सार्वजनिक आर्टिफैक्ट हल नहीं करता।

फिर भी प्रकाशित क्यों करें

हमने जिनसे भी पूछा (और हमारा अपना EXR प्रयोग) उन्होंने मान लिया कि गैर-JPEG/PNG/HEIC अटैचमेंट Messages पूर्वावलोकन में डिकोड नहीं होते। JXL होता है। यह ज़ीरो-क्लिक हमला सतह का एक ठोस, परीक्षण योग्य विस्तार है, और इसका मतलब है कि AppleJPEGXL बग्स को केवल WebContent को ध्यान में रखकर नहीं, बल्कि iMessage डिलीवरी को ध्यान में रखकर खोजा जाना चाहिए।

शैक्षिक और रक्षात्मक अनुसंधान उद्देश्यों के लिए। केवल उस हार्डवेयर पर परीक्षण करें जो आपके स्वामित्व में है।