4 अगस्त 2026 को Mysk के शोधकर्ताओं ने WebKit के तीन तंत्रों का विश्लेषण प्रकाशित किया, जो ट्रैफ़िक को सेट किए गए प्रॉक्सी को बायपास करते हुए सीधे डिवाइस से भेजते हैं। सभी iOS ब्राउज़रों को, जिनमें प्रॉक्सी मोड शामिल है, टार ब्राउज़रों सहित, और एप्पल की अपनी सेवा - iCloud प्राइवेट रिले भी प्रभावित हुई। प्रॉक्सी चालू है, इंटरफ़ेस एक विदेशी देश दिखाता है, जबकि वेबसाइट आपके असली आईपी और आपके घरेलू DNS-रेज़ोल्वर को देखती है।
यह कोई अजीबोगरीब कमजोरियों नहीं है जो केवल पेरानोइड के लिए है। यह एक स्पष्ट प्रदर्शन है उस आर्किटेक्चरल नियम का, जिसे सभी को समझना चाहिए जो प्रॉक्सी के माध्यम से काम करते हैं: एप्लिकेशन स्तर पर प्रॉक्सी केवल उस ट्रैफ़िक की सुरक्षा करता है जो उस एप्लिकेशन के नेटवर्क स्टैक के माध्यम से गुजरता है। जो कुछ भी ऑपरेटिंग सिस्टम या एकल सिस्टम सेवा द्वारा उत्पन्न होता है, वह बायपास होता है।
क्या वास्तव में लीक हो रहा है
शोध एक सामान्य स्थिति से शुरू हुआ: प्रॉक्सी ब्राउज़र Psylo के उपयोगकर्ता ने डेवलपर को DNS लीक की शिकायत की। शिकायत की जांच ने तीन स्वतंत्र लीक चैनलों का खुलासा किया - ये सभी WebKit में हैं, न कि किसी विशेष एप्लिकेशन में।
1. DNS प्रीफेचिंग - सबसे सरल और सबसे अप्रिय
तंत्र: <link rel="dns-prefetch"> टैग ब्राउज़र से अनुरोध करता है कि वह पहले से होस्ट नाम को हल करे, ताकि भविष्य की लोडिंग को तेज किया जा सके। समस्या यह है कि WebKit iOS पर ऐसे नामों को डिवाइस के सामान्य DNS पथ के माध्यम से हल करता है, न कि प्रॉक्सी के माध्यम से।
डेस्कटॉप सफारी ने सफारी 5 के समय से dns-prefetch का समर्थन किया है, लेकिन iOS ने इस टैग को नजरअंदाज किया - iOS 26.0 (सितंबर 2025) तक। तब WebKit ने इसे उसी बदलाव के तहत शामिल किया जिसने पुराने अप्रत्यक्ष सट्टा DNS प्रीफेचिंग को हटा दिया (बग 285744)।
यह कैसे शोषित किया जाता है: पृष्ठ ऐसे टैग में प्रत्येक आगंतुक के लिए अद्वितीय होस्ट नाम डालता है, और फिर बस देखता है कि अनुरोध उसके अपने प्राधिकृत DNS सर्वर पर कैसे आते हैं - आगंतुक के वास्तविक नेटवर्क पते से। कोई जावास्क्रिप्ट नहीं, कोई उपयोगकर्ता के साथ बातचीत नहीं। पृष्ठ खोलना ही पर्याप्त है।
2. WebAuthn संबंधित मूल अनुरोध - पासकी से लीक
यह चैनल iOS 18.0 में आया। जब साइट WebAuthn क्रेडेंशियल (यानी पासकी) का अनुरोध करती है, तो सिस्टम https://<rpId>/.well-known/webauthn फ़ाइल की जांच करता है - यह सुनिश्चित करने के लिए कि डोमेन वास्तव में निर्दिष्ट रिलायंग पार्टी से संबंधित है।
मुख्य विवरण: यह जांच अनुरोध ब्राउज़र के नेटवर्क स्टैक से नहीं आता। इसे ऑपरेटिंग सिस्टम की क्रेडेंशियल सेवा द्वारा निष्पादित किया जाता है, जो सीधे डिवाइस से HTTPS अनुरोध भेजती है। ब्राउज़र के भीतर सेट की गई प्रॉक्सी इसके बारे में नहीं जानती (बग 268426)।
यानी, पृष्ठ का पासकी अनुरोध शुरू करना ही पर्याप्त है - और हमलावर का सर्वर आपके असली आईपी से कनेक्शन प्राप्त करता है।
3. WebTransport - सीधे डिवाइस से QUIC
सबसे नया चैनल। new WebTransport(url) का कॉल सीधे डिवाइस से QUIC कनेक्शन खोलता है, प्रॉक्सी कॉन्फ़िगरेशन को बायपास करते हुए। WebTransport WebKit में लंबे समय तक बंद रहा और मार्च 2026 में iOS 26.4 में सार्वजनिक रूप से आया (बग 260810 और 303453)।
यह किसे प्रभावित करता है
Apple ने सभी ब्राउज़रों को iPhone पर WebKit का उपयोग करने की आवश्यकता है। इसलिए, हर iOS ब्राउज़र जो WebKit प्रॉक्सी-API पर निर्भर करता है प्रभावित होगा - जिसमें सभी iOS संस्करणों के टार ब्राउज़रों और स्वयं Psylo, जिससे जांच शुरू हुई थी, शामिल हैं। इसके अलावा सफारी और iCloud प्राइवेट रिले।
जो प्रभावित नहीं है - VPN एप्लिकेशन। वे सिस्टम स्तर पर काम करते हैं और डिवाइस के सभी ट्रैफ़िक को पूरी तरह से लपेटते हैं, जिसमें वह भी शामिल है जो सिस्टम सेवाओं द्वारा उत्पन्न होता है। यही अंतर का सार है: सिस्टम टनल में "बायपास" नहीं होता। एक अलग अपवाद - सुरक्षा स्तर सिल्वर पर ओनियन ब्राउज़र जिसमें लॉकडाउन मोड चालू है: यह WebTransport के माध्यम से लीक के प्रति प्रतिरोधी है।
डेवलपर्स की ओर से प्रतिक्रिया पहले ही आ चुकी है। Psylo 1.3.1 में सभी तीन चैनल बंद कर दिए गए हैं: एप्लिकेशन dns-prefetch सुझावों को ब्लॉक करता है (पृष्ठ अब डिवाइस को हमलावर के नियंत्रण में नामों को हल करने के लिए मजबूर नहीं कर सकता), और WebTransport और WebAuthn डिफ़ॉल्ट रूप से बंद हैं - इन्हें अलग-अलग टॉगल के माध्यम से सक्षम किया जा सकता है। Apple, प्रकाशन के समय के अनुसार, भविष्य के अपडेट में समस्याओं को हल करने की योजना बना रही है; कंपनी ने कोई विशिष्ट समय सीमा नहीं बताई।
यह अब तक क्यों सामने आया
यहां की समयरेखा महत्वपूर्ण है, और इसे अलग से समझना चाहिए - यह बताती है कि पहले समस्या का पता क्यों नहीं चला।
- सितंबर 2024, iOS 18.0 - WebAuthn संबंधित मूल अनुरोध का तंत्र आता है। लीक चैनल लगभग दो साल से मौजूद है और इस समय किसी ने चर्चा नहीं की: पासकी के लिए डोमेन की जांच सुरक्षा का एक तत्व लगती है, न कि पता प्रकट करने का एक तरीका।
- सितंबर 2025, iOS 26.0 - WebKit मोबाइल उपकरणों पर dns-prefetch का समर्थन करता है। औपचारिक रूप से यह लोडिंग गति का अनुकूलन है; वास्तव में - पृष्ठ को डिवाइस को प्रॉक्सी को बायपास करते हुए किसी भी DNS नाम को संदर्भित करने की अनुमति मिलती है।
- मार्च 2026, iOS 26.4 - WebTransport सार्वजनिक रूप से चालू होता है। तीसरा चैनल।
- अगस्त 2026 - एक उपयोगकर्ता की DNS लीक की शिकायत से एक जांच होती है, जो सभी तीनों को एक साथ उजागर करती है।
सामान्य तत्व: इनमें से कोई भी कार्य डी-एनोनिमाइजेशन चैनल के रूप में नहीं सोचा गया था। सभी तीन सामान्य प्लेटफ़ॉर्म क्षमताएँ हैं: रिज़ॉल्विंग की गति में सुधार, पासकी की जांच, आधुनिक परिवहन। वे केवल एप्लिकेशन स्तर के प्रॉक्सी मोड के साथ संयोजन में लीक बन जाते हैं, और यही कारण है कि वर्षों से किसी ने उनकी इस गुणवत्ता में जांच नहीं की।
व्यवहार में निष्कर्ष सरल और अप्रिय है: लीक के बारे में कोई समाचार का मतलब यह नहीं है कि वे मौजूद नहीं हैं। आपको स्वयं और नियमित रूप से जांच करनी चाहिए, न कि किसी के द्वारा विश्लेषण प्रकाशित होने की प्रतीक्षा करनी चाहिए।
अपने आप को कैसे जांचें
शोधकर्ताओं ने एक सार्वजनिक स्टैंड बनाया - leaks.psylo.app। यह तीन चीजों की जांच करता है: सामान्य HTTPS ट्रैफ़िक (सर्वर कौन सा आईपी और कौन से DNS-रेज़ोल्वर देखता है), WebTransport और WebAuthn + dns-prefetch का संयोजन। आप इसे प्रॉक्सी चालू करके खोलते हैं और परिणाम की तुलना उस पते से करते हैं, जिसे आप देखना चाहते हैं।
बुनियादी स्वच्छता की भी जांच करना महत्वपूर्ण है - क्या आपके कार्यात्मक संयोजन में आईपी, DNS और WebRTC पता मेल खाते हैं। यदि आपने पहले इसे व्यवस्थित रूप से नहीं किया है, तो हमारे विश्लेषण से शुरू करें: कैसे प्रॉक्सी की DNS लीक की जांच करें.
व्यावहारिक निष्कर्ष: परत महत्वपूर्ण है
WebKit के साथ यह कहानी एक सामान्य नियम का एक विशेष मामला है, जिसे किसी भी प्रॉक्सी के माध्यम से काम करते समय, किसी भी प्लेटफ़ॉर्म पर ध्यान में रखना चाहिए।
- ब्राउज़र में प्रॉक्सी ≠ डिवाइस पर प्रॉक्सी। एप्लिकेशन के भीतर सेटिंग केवल उस ट्रैफ़िक को कवर करती है जो एप्लिकेशन स्वयं भेजता है। सिस्टम सेवाएँ, बैकग्राउंड प्रक्रियाएँ, अपडेट, पुश कनेक्शन और, जैसा कि पता चला, अंतर्निहित पासकी सेवा - ये सभी अपने रास्ते पर जाते हैं।
- लीक केवल "ज्ञात" स्थानों पर नहीं होते। WebRTC लंबे समय से चर्चा में है, और इसे बंद करना सीखा गया है। और DNS प्रीफेचिंग और WebAuthn की जांच - ये प्रदर्शन और सुरक्षा की विशेषताएँ हैं, जिन्हें किसी ने भी डी-एनोनिमाइजेशन चैनल के रूप में नहीं देखा। ब्राउज़रों की नई विशेषताएँ नियमित रूप से नए बायपास रास्ते बनाती हैं।
- प्लेटफ़ॉर्म का अपडेट आपकी सुरक्षा को चुपचाप तोड़ सकता है। यहां यह तिथियों के माध्यम से स्पष्ट है: DNS प्रीफेचिंग iOS 26.0 में "चालू" हुआ, WebTransport iOS 26.4 में। उपयोगकर्ता ने कुछ नहीं बदला, और लीक की सतह अपने आप बढ़ गई।
यह मल्टी-एकाउंटिंग और स्वचालन के लिए क्या अर्थ रखता है
उन लोगों के लिए जो कई खातों का संचालन करते हैं या डेटा एकत्र करते हैं, यहाँ जोखिम अमूर्त-निजी नहीं, बल्कि पूरी तरह से वित्तीय है। प्लेटफार्मों की एंटी-फ्रॉड प्रणालियाँ संकेतों की तुलना करती हैं: यदि सत्र एक आईपी का दावा करता है, जबकि संबंधित अनुरोध दूसरे पते और घरेलू रेज़ोल्वर से आता है, तो यह खातों को एक साथ जोड़ने या सत्र को संदिग्ध के रूप में चिह्नित करने का एक तैयार कारण है।
व्यावहारिक परिणाम:
- मोबाइल ब्राउज़रों में प्रॉक्सी मोड के साथ कार्यात्मक मल्टी-एकाउंट सत्र न चलाएँ। जब तक प्लेटफ़ॉर्म छिद्रों को बंद नहीं करता, iOS पर एप्लिकेशन की परत स्वाभाविक रूप से असुरक्षित है।
- सिस्टम स्तर पर ट्रैफ़िक को लपेटें। यदि कार्य मोबाइल वातावरण है, तो डिवाइस स्तर पर प्रॉक्सी स्थापित करना या अलग गेटवे के माध्यम से रूट करना अधिक समझदारी है, न कि ब्राउज़र के भीतर सेटिंग पर निर्भर रहना।
- हर बड़े ओएस और ब्राउज़र अपडेट के बाद संयोजन की जांच करें। न्यूनतम हर तिमाही। इसे चेकलिस्ट में डालें, न कि "जब कुछ गलत हो जाए"।
- जिसका उपयोग नहीं कर रहे हैं उसे बंद करें। कार्यात्मक प्रोफ़ाइल में WebTransport और WebAuthn शायद आवश्यक नहीं हैं - इन्हें बंद करने से तीन में से दो लीक चैनल हटा दिए जाते हैं।
इसमें आईपी की गुणवत्ता एक अलग चर बनी रहती है: यहां तक कि सील बंद कॉन्फ़िगरेशन में, डेटा सेंटर का पता ASN द्वारा खुद को प्रकट करता है। उन परिदृश्यों के लिए जहां सामान्य उपयोगकर्ता की तरह दिखना महत्वपूर्ण है, रेसिडेंशियल प्रॉक्सी काम करती हैं, और सबसे कठोर एंटी-फ्रॉड वाले मोबाइल एप्लिकेशनों और प्लेटफार्मों के लिए - मोबाइल प्रॉक्सी वास्तविक मोबाइल ऑपरेटरों के आईपी के साथ। लेकिन कोई भी प्रॉक्सी वर्ग मदद नहीं करेगा यदि ट्रैफ़िक का एक हिस्सा भौतिक रूप से इसके बायपास हो रहा है - पहले सील, फिर पते की गुणवत्ता।
निष्कर्ष
WebKit के तीन बग - DNS प्रीफेचिंग, WebAuthn संबंधित मूल अनुरोध और WebTransport - ने दिखाया कि "प्रॉक्सी चालू है" और "सारा ट्रैफ़िक प्रॉक्सी के माध्यम से जा रहा है" दो अलग-अलग बयान हैं। iOS पर उनके बीच का अंतर इतना चौड़ा था कि एक सामान्य वेब पृष्ठ बिना एक भी जावास्क्रिप्ट लाइन के Tor ब्राउज़र के आगंतुक के असली पते को जान सकता था।
जब तक Apple एक सुधार तैयार करता है, एकमात्र कार्यात्मक रणनीति है - जांचना, न कि अनुमान लगाना। परीक्षण स्टैंड खोलें, पते की तुलना करें, अनावश्यक API बंद करें। और हर बड़े ओएस अपडेट को एक घटना के रूप में लें, जिसके बाद कॉन्फ़िगरेशन को फिर से जांचने की आवश्यकता होती है। प्राइवेसी और इसके भ्रम के बीच का अंतर अक्सर एक समय पर न पूछे गए सवाल में होता है: "क्या वास्तव में सारा ट्रैफ़िक है?" यह भी समझना उपयोगी है कि आपके पते के अलावा और कौन से संकेत आपको प्रकट करते हैं - इस पर हमने ब्राउज़र फ़िंगरप्रिंटिंग से सुरक्षा पर सामग्री में लिखा है।