CVE-2026-84568 और CVE-2026-84570 का सार्वजनिक, स्रोत-निर्देशित विश्लेषण, जिसमें LDAP/OD इनपुट, NFS डिलीवरी, हेल्पर डिस्पैच, Gatekeeper व्यवहार, और डिवाइस-नोड सीमा के लिए प्रतिवर्ती प्रमाण शामिल हैं।

प्रकाशन स्थिति — अक्टूबर 2026। Apple ने 14 सितंबर 2026 को macOS Sequoia 15.8, macOS Tahoe 26.7, और macOS Golden Gate 27 में दोनों भेद्यताओं को ठीक किया। इस रिपॉज़िटरी में दिया गया रीप्रोड्यूसर केवल एक पृथक, अधिकृत लैब के लिए है जिसमें जानबूझकर अन-पैच किया गया Mac हो।

सत्यापन स्थिति। शामिल ऑन-होस्ट वैलिडेटर एक प्रभावित macOS 26.4 (build 25E246, arm64) लैब होस्ट पर सफलतापूर्वक चलाए गए। हेल्पर-डिस्पैच परीक्षण, पूर्ण लूपबैक NFS डिलीवरी श्रृंखला, पाथनेम/क्रेडेंशियल प्रोब, Gatekeeper डिफरेंशियल, और nodev/डिवाइस सीमा परीक्षण सभी ने PASS लौटाया। Gatekeeper परीक्षण में, आकलन सक्षम थे; ऐप संरचनात्मक रूप से वैध था लेकिन बिना किसी Team ID के ad-hoc हस्ताक्षरित था; स्पष्ट spctl आकलन ने इसे अस्वीकार कर दिया; NFS माउंट में न तो noexec था और न ही क्वारंटीन; और LaunchServices ने इसे बिना किसी अनुमोदन चरण के चलाया। प्रत्येक वैलिडेटर ने cleanup_result=PASS भी लौटाया, और एक स्वतंत्र रन-पश्चात जाँच ने पुष्टि की कि इसके अस्थायी निर्देशिका रिकॉर्ड, माउंट, फ़ाइलें, और /etc/exports परिवर्तन हटा दिए गए या पुनर्स्थापित कर दिए गए थे। Python हार्नेस को अलग से एक अस्थायी OpenLDAP सर्वर के विरुद्ध वास्तविक automount/Apple एट्रिब्यूट स्कीमा के साथ परखा गया: automountKey और apple-user-homeurl दोनों मार्गों ने create/readback/timeout/restore जाँच पास की। ये अवलोकन उस प्रभावित बिल्ड और शामिल हार्नेस की विशेषता बताते हैं; ये पैच किए गए रिलीज़ के बारे में दावे नहीं हैं।

शोध श्रेय: Mr.Gedik (@h4ck2s3c); CVE-2026-84568 का श्रेय सार्वजनिक रूप से Mr.Gedik को, और CVE-2026-84570 का श्रेय Mr.Gedik को, Apple के एडवाइज़री में दिया गया है।

दायरा

यह शोध का सार्वजनिक संस्करण है। इसमें केवल Apple की प्रकाशित एडवाइज़री, Apple के ओपन-सोर्स कोड, और शामिल पुनरुत्पाद्य लैब सामग्री द्वारा समर्थित जानकारी है। निजी केस पहचानकर्ता, निजी संचार, गैर-सार्वजनिक आर्टिफ़ैक्ट, और असंबंधित शोध को जानबूझकर बाहर रखा गया है।

दोनों CVE एक ही आक्रमण सतह साझा करते हैं लेकिन स्वतंत्र मूल कारणों का प्रतिनिधित्व करते हैं:

CVE	Apple का प्रकाशित प्रभाव	क्लाइंट-साइड सीमा
CVE-2026-84568	एक नेटवर्क-निर्देशिका आक्रमणकारी root विशेषाधिकारों के साथ मनमाना कोड निष्पादित कर सकता है	एक निर्देशिका-नियंत्रित `fstype` ने `automountd` द्वारा चयनित निष्पादन योग्य पथ को प्रभावित किया
CVE-2026-84570	एक ऐप Gatekeeper जाँचों को बायपास कर सकता है	एक निर्देशिका-नियंत्रित NFS automount ने एप्लिकेशन-प्रोवेनेंस और डिवाइस-नोड दोनों नीति सीमाओं को पार किया

Apple दोनों मुद्दों को macOS Golden Gate 27, macOS Tahoe 26.7, और macOS Sequoia 15.8 के सुरक्षा सामग्री में autofs के अंतर्गत सूचीबद्ध करता है।

कार्यकारी सारांश

macOS automount मैप निष्पादन योग्य नियंत्रण डेटा हैं। एक मैप पंक्ति एक फ़ाइलसिस्टम प्रकार चुनती है, माउंट विकल्प प्रदान करती है, एक संसाधन की पहचान करती है, और अंततः विशेषाधिकार प्राप्त माउंट डिस्पैच को प्रभावित करती है। सितंबर 2026 के अपडेट से पहले, दो सत्यापन विफलताओं ने निर्देशिका-प्रदत्त डेटा को क्लाइंट पर सुरक्षा सीमाओं को पार करने की अनुमति दी:

एक तैयार किया गया fstype इच्छित /sbin/mount_<type> हेल्पर नेमस्पेस से बच सकता था और NFS के माध्यम से पहुँचाए गए एक निष्पादन योग्य फ़ाइल पर रिज़ॉल्व हो सकता था।
एक तैयार किया गया NFS विकल्प सेट अपेक्षित nodev नीति को नकार सकता था। परिणामी नेटवर्क माउंट में न तो noexec था और न ही क्वारंटीन नीति, इसलिए एक ऐप जो स्पष्ट Gatekeeper आकलन में विफल रहा था, फिर भी उससे लॉन्च किया जा सकता था।

ये संबंधित अवलोकन हैं, परस्पर विनिमेय तंत्र नहीं। nodev नियंत्रित करता है कि विशेष-डिवाइस vnode की व्याख्या की जाती है या नहीं; यह Gatekeeper को लागू नहीं करता। noexec VFS सीमा पर निष्पादन को नियंत्रित करता है। Gatekeeper अलग से एप्लिकेशन विश्वास और प्रोवेनेंस का मूल्यांकन करता है। CVE-2026-84570 वैलिडेटर प्रत्येक सीमा की स्वतंत्र रूप से रिपोर्ट करता है ताकि अनुपस्थित nodev फ़्लैग को कभी भी अपने आप में Gatekeeper बायपास के प्रमाण के रूप में प्रस्तुत न किया जाए।

डायरेक्टरी लेखन पहुँच एक प्रवेश पूर्वशर्त है, परिणामी प्राधिकार नहीं। ऑटोमाउंट या यूज़र-होम विशेषता बदलना प्रत्येक उपभोक्ता Mac पर निष्पादन योग्य पथनाम चुनने या NFS माउंट की कर्नेल नीति को कमज़ोर करने के समतुल्य नहीं है। वे रूपांतरण क्लाइंट पर होते हैं।

सटीकता संबंधी टिप्पणियाँ

एक स्व-निहित CVE-2026-84568 लैब श्रृंखला दो डायरेक्टरी मानों का उपयोग करती है: एक संक्षिप्त NFS पथ प्रदान करता है और एक हेल्पर डिस्पैच को वितरित बाइनरी की ओर पुनर्निर्देशित करता है।
रिकॉर्ड बनाना स्वयं उसे निष्पादित नहीं करता। संबंधित कुंजी का ऑटोफ़्स लुकअप अभी भी आवश्यक है।
शामिल Python हार्नेस वह लुकअप कभी नहीं करता। यह अधिकृत लैब स्थिति स्थापित करता है और स्वतंत्र क्लाइंट गतिविधि द्वारा उत्पन्न प्रूफ़ इवेंट की निष्क्रिय रूप से प्रतीक्षा करता है।
लुकअप क्रेडेंशियल मायने रखते हैं। जेनेरिक हेल्पर चाइल्ड ट्रिगर करने वाले UID से जुड़ा होता है; इसलिए Apple के प्रकाशित रूट-प्रिविलेज्ड एंडपॉइंट को प्रदर्शित करने के लिए रूट-उद्गम वाला लुकअप आवश्यक है।
पथनाम रिज़ॉल्यूशन का परीक्षण विशेषाधिकार प्राप्त डेमन संदर्भ में किया जाना चाहिए। मान्य किए गए होस्ट पर, निर्मित पथ का रूट द्वारा लुकअप सफल रहा, जबकि एक गैर-विशेषाधिकार प्राप्त खाते द्वारा उसी सीधे stat() ने ENOTDIR लौटाया; इसलिए यहाँ गैर-विशेषाधिकार प्राप्त realpath() या stat() परिणाम automountd के लिए वैध प्रॉक्सी नहीं है।
CVE-2026-84568 के लिए CVE-2026-84570 हेतु प्रदर्शित nodev बायपास की आवश्यकता नहीं है। पूरी 84568 श्रृंखला सफल रही, जबकि इसका डिलीवरी माउंट nodev और nosuid बनाए रखे हुए था।
Gatekeeper प्रमाण आधुनिक कंपाइलर आउटपुट को शाब्दिक रूप से अहस्ताक्षरित नहीं लेबल करता। वैलिडेटर एक संरचनात्मक रूप से वैध ad-hoc-हस्ताक्षरित ऐप बनाता है जिसमें कोई Team ID और कोई नोटराइज़ेशन नहीं होता। यह लोडर-वैध कोड को डिफ़ॉल्ट Gatekeeper नीति के अंतर्गत विश्वसनीय सॉफ़्टवेयर से अलग करने के लिए पर्याप्त है।
अकेले CVE-2026-84570 किसी ऐप को स्वचालित रूप से निष्पादित नहीं कराता। इसका वैलिडेटर LaunchServices को स्पष्ट रूप से आमंत्रित करता है। CVE-2026-84568 वह अलग डिस्पैच प्रिमिटिव प्रदान करता है जो डिस्पैच कुंजी के लुकअप होने पर वितरित बाइनरी को निष्पादित करता है।
मॉनिटरिंग टाइमआउट अनिर्णायक है: यह कहता है कि चयनित अंतराल के दौरान कोई मेल खाता प्रूफ़ इवेंट नहीं आया, यह नहीं कि लक्ष्य पैच हो गया है।

डायरेक्टरी डेटा से विशेषाधिकार प्राप्त डिस्पैच तक

डिफ़ॉल्ट ऑटोमाउंट कॉन्फ़िगरेशन /home के अंतर्गत डायरेक्टरी-समर्थित इनपुट उजागर करता है:

/etc/auto_master:  /home  auto_home  -nobrowse,hidefromfinder
/etc/auto_home:    +auto_home
/etc/auto_home:    +/usr/libexec/od_user_homes

पहला inclusion automount रिकॉर्ड को resolve करता है। executable-map inclusion od_user_homes को invoke करता है, जो user-home जानकारी resolve करता है और एक map लाइन emit करता है। दोनों routes automount parser पर converge करते हैं।

सार्वजनिक harness दोनों directory रूपों को स्पष्ट रखता है:

Route	Directory input	परिणामी autofs key/value
`automount`	RFC 2307 entry जिसका RDN `automountMapName=auto_home` map के नीचे `automountKey=<key>` है; मान `automountInformation` में	`<key>` → raw map line
`userhome`	मौजूदा user entry; मान `apple-user-homeurl` में	उपयोगकर्ता की record-name key → map line जो `<home_dir><url>…</url></home_dir>` में wrapped है

यह अंतर operational रूप से मायने रखता है लेकिन vulnerable sink पर नहीं: दोनों मान अंततः Mac पर parsed filesystem type और mount arguments को प्रभावित करते हैं।

flowchart LR
    DS["LDAP / Open Directory"]
    AM["AutomountInformation"]
    UH["User home attribute"]
    GM["getmapent_od()"]
    OUH["od_user_homes"]
    MAP["Automount map line"]
    PARSE["parse_entry() / set_mapent_opts()"]
    TYPE{"fstype"}
    NFS["Dedicated NFS path"]
    GENERIC["Generic helper path"]
    EXEC["run_mount_cmd()"]

    DS --> AM --> GM --> MAP
    DS --> UH --> OUH --> MAP
    MAP --> PARSE --> TYPE
    TYPE -->|exactly nfs| NFS
    TYPE -->|another value| GENERIC --> EXEC

CVE-2026-84568

सबसे लोकप्रिय

दायरा

कार्यकारी सारांश

सटीकता संबंधी टिप्पणियाँ

डायरेक्टरी डेटा से विशेषाधिकार प्राप्त डिस्पैच तक