प्रॉक्सी पासवर्ड लीक करना curl, libsoup और requests के माध्यम से: जांच

प्रॉक्सी का पासवर्ड आमतौर पर लोगों से छिपाया जाता है: स्क्रीनशॉट में नहीं दिखाया जाता, git में कमिट नहीं किया जाता, और पर्यावरण चर में रखा जाता है। लेकिन 2026 में पता चला कि इसे HTTP-क्लाइंट खुद जारी कर सकता है। अप्रैल से जुलाई के बीच curl, libcurl और libsoup में कई कमजोरियां सामने आईं, जिनमें Proxy-Authorization हेडर गलत प्रॉक्सी को भेजा जाता है, या सीधे लक्ष्य साइट को। नीचे यह बताया गया है कि यह किस स्थिति में होता है, और अपने स्टैक की चरण-दर-चरण जांच कैसे करें।

क्या हुआ: चार महीनों में चार लीक

इन सभी बग्स का निर्माण एक समान है: क्लाइंट एक प्रॉक्सी का लॉगिन और पासवर्ड याद रखता है और गलती से उन्हें श्रृंखला में आगे भेज देता है।

CVE-2026-6253 (curl और libcurl 7.14.1–8.19.0). यदि http:// और https:// के लिए अलग-अलग प्रॉक्सी सेट किए गए हैं, पहला पासवर्ड मांगता है, जबकि दूसरा नहीं, तो स्कीम बदलने पर curl पहले प्रॉक्सी के क्रेडेंशियल्स को दूसरे को भेज देगा। डेटा base64 में भेजा जाता है, यानी वास्तव में स्पष्ट पाठ में। इसे 29 अप्रैल 2026 को जारी curl 8.20.0 में ठीक किया गया। कंसोल curl भी प्रभावित है, केवल लाइब्रेरी नहीं।
CVE-2026-8927 (libcurl 7.12.0–8.20.0). एप्लिकेशन एक हैंडल को कई अनुरोधों के लिए पुनः उपयोग करता है, प्रॉक्सी पर्यावरण चर से लिए जाते हैं, और प्रमाणीकरण डाइजेस्ट के माध्यम से होता है। तब प्रॉक्सी A के लिए Proxy-Authorization हेडर प्रॉक्सी B को भेजा जाता है, और वह इसे दोहराकर खुद को आपके रूप में प्रस्तुत कर सकता है। इसे 24 जून 2026 को curl 8.21.0 में ठीक किया गया। कंसोल curl प्रभावित नहीं है। लगभग इसी तरह का बग CVE-2026-7168 में वर्णित है, केवल यह कि प्रॉक्सी कैसे चुना जाता है।
CVE-2026-12547 (libsoup, SoupAuthManager). libsoup प्रॉक्सी क्रेडेंशियल्स को कैश करता है, बिना उन्हें host:port पते से बांधे। जब प्रॉक्सी सेटिंग्स बदलती हैं (सिस्टम सेटिंग्स, WPAD), पुराना हेडर नए प्रॉक्सी को भेजा जाता है। इसे 21 जुलाई 2026 को प्रकाशित किया गया, और इसका मूल्यांकन निम्न है।
CVE-2026-66339 (libsoup, CONNECT-टनल). HTTP-प्रॉक्सी के माध्यम से CONNECT-टनल स्थापित करने के बाद libsoup अगले HTTPS अनुरोधों के साथ Proxy-Authorization को जोड़ता है। हेडर पहले से ही लक्ष्य सर्वर द्वारा देखा जाता है। CVSS 6.5, 24 जुलाई 2026 को प्रकाशित।

यह कहानी नई नहीं है। Python लाइब्रेरी requests में संस्करण 2.3.0 से 2.31.0 (CVE-2023-32681) के बीच, HTTPS पर रीडायरेक्ट करते समय Proxy-Authorization हेडर लक्ष्य सर्वर को भेजा जाता था, यदि लॉगिन और पासवर्ड सीधे प्रॉक्सी के URL में लिखे गए थे। urllib3 में 1.26.19 और 2.2.2 (CVE-2024-37891) तक, मैन्युअल रूप से सेट किया गया हेडर, न कि प्रॉक्सी के अंतर्निहित समर्थन के माध्यम से, दूसरे डोमेन पर रीडायरेक्ट करते समय काटा नहीं गया।

यह प्रॉक्सी के साथ काम करने के लिए क्यों महत्वपूर्ण है

भुगतान किए गए प्रॉक्सी का पासवर्ड पैसे के बराबर होता है। जिसने इसे प्राप्त किया, वह आपके ट्रैफिक का उपयोग करता है, जब तक आप पहुंच नहीं बदलते। जब आप गीगाबाइट के लिए भुगतान करते हैं, तो यह सीधा बिल होता है, और जब यह पूरी टीम के लिए साझा किया जाता है, तो आपके IP के साथ अन्य लोगों की गतिविधियां भी होती हैं।

सबसे कमजोर परिदृश्य इस प्रकार हैं:

पार्सर्स और मॉनिटरिंग, जो स्वचालित रूप से रीडायरेक्ट पर जाते हैं। लक्ष्य साइट या मध्यवर्ती रीडायरेक्ट अनुरोध को उस डोमेन पर ले जा सकता है, जो हेडर एकत्र करता है।
कई प्रॉक्सी वाले स्क्रिप्ट: विभिन्न स्कीमों के लिए विभिन्न प्रॉक्सी, एक ही कनेक्शन पर अनुरोधों के बीच प्रॉक्सी का स्विचिंग, "पासवर्ड वाले प्रॉक्सी" और "बिना पासवर्ड वाले प्रॉक्सी" का मिश्रण।
Linux सर्वरों पर दीर्घकालिक प्रक्रियाएं, जहां libcurl और libsoup सिस्टम पैकेजों के साथ आते हैं और आपके कोड के साथ नहीं, बल्कि वितरण के साथ अपडेट होते हैं।
कॉर्पोरेट नेटवर्क WPAD और PAC फ़ाइलों के साथ: प्रॉक्सी बिना एप्लिकेशन की भागीदारी के बदलता है, और यही मामला CVE-2026-12547 में वर्णित है।

अपने स्टैक की जांच कैसे करें: चरण-दर-चरण

libcurl का असली संस्करण जानें, न कि केवल कंसोल curl का। curl -V कमांड दोनों को दिखाता है, लेकिन एप्लिकेशन अपनी लाइब्रेरी की कॉपी के साथ बनाया जा सकता है। Python के लिए pycurl के साथ python -c "import pycurl; print(pycurl.version)" चलाएं, PHP के लिए curl_version() को कॉल करें। सुरक्षित सीमा: 8.21.0 और नए या ठीक किए गए शाखाएं 8.20.1+, 8.16.1+ और 8.14.2+।
Python निर्भरताओं की जांच करें। pip show requests urllib3 चलाएं। requests 2.31.0 से कम नहीं और urllib3 1.26.19 (1.x शाखा) या 2.2.2 (2.x शाखा) से कम नहीं चाहिए। यदि निर्भरता पारगमन में आती है, तो उसी वातावरण में pip list देखें, जहां पार्सर काम कर रहा है।
Linux पर libsoup की जांच करें। यह GNOME एप्लिकेशनों, WebKitGTK और इस स्टैक पर बने सभी चीजों के लिए लागू होता है। पैकेज को वितरण प्रबंधक के माध्यम से अपडेट करें और अपने वितरण के सुरक्षा बुलेटिन के साथ मिलान करें: इन CVE के कार्डों में Red Hat में प्रभावितों में RHEL 6–10 शामिल हैं।
कोड में हेडर की मैन्युअल सेटिंग खोजें। पूरे रिपॉजिटरी में Proxy-Authorization के लिए खोजें। यदि हेडर मैन्युअल रूप से सेट किया जाता है, न कि क्लाइंट प्रॉक्सी के मानक तंत्र के माध्यम से (proxies= requests में, ProxyManager urllib3 में, CURLOPT_PROXYUSERPWD libcurl में), तो यह रीडायरेक्ट पर लीक के लिए एक उम्मीदवार है।
प्रॉक्सी बदलने पर कनेक्शनों के पुन: उपयोग को खोजें। एक हैंडल libcurl, एक सत्र requests या एक HTTP एजेंट, जिसके माध्यम से बारी-बारी से विभिन्न प्रॉक्सी के साथ अनुरोध किए जाते हैं। इसे ठीक करने का सबसे सरल विकल्प: प्रत्येक प्रॉक्सी के लिए अलग सत्र।
जहां आवश्यक न हो, वहां स्वचालित रीडायरेक्ट बंद करें। requests में यह allow_redirects=False है, urllib3 में redirect=False है, curl में -L और CURLOPT_FOLLOWLOCATION न लगाएं। तब 3xx को मैन्युअल रूप से संसाधित किया जाता है, और आप खुद तय करते हैं कि आगे कहां जाना है। यही बाईपास मार्ग requests और urllib3 के लेखकों द्वारा दिया गया है।
फंदे पर एक जीवित परीक्षण करें। अपने पास एक साधारण HTTP सर्वर उठाएं, जो सभी आने वाले हेडर्स को प्रिंट करता है, और उस पर दूसरे समान सर्वर पर रीडायरेक्ट करें। अपने पार्सर के माध्यम से प्रॉक्सी के साथ वास्तविक परिदृश्य चलाएं, जिसमें http से https में स्कीम का परिवर्तन शामिल है। यदि किसी भी सर्वर ने Proxy-Authorization देखा, तो लीक आपके कोड पर पुष्टि की गई है, न कि सिद्धांत में।

छिपे हुए खतरे

Docker इमेज अपनी जिंदगी जीती हैं। होस्ट पर curl को अपडेट किया, लेकिन पार्सर एक पुराने बेस इमेज वाले कंटेनर में काम कर रहा है। जांच कंटेनर के भीतर करनी चाहिए: docker exec <कंटेनर> curl -V।
कंसोल curl और libcurl अलग-अलग अपडेट होते हैं। CVE-2026-8927 कंसोल curl को प्रभावित नहीं करता, जबकि CVE-2026-6253 इसे प्रभावित करता है। टर्मिनल में ताजा curl -V आपके PHP या Python के साथ बनाए गए लाइब्रेरी के बारे में कुछ नहीं बताता।
डाइजेस्ट सुरक्षा नहीं देता। हां, डाइजेस्ट के मामले में पासवर्ड स्पष्ट पाठ में नहीं जाता। लेकिन CVE-2026-8927 में हमलावर को पासवर्ड की आवश्यकता नहीं है: कैप्चर किया गया हेडर तब तक दोहराया जाता है जब तक nonce सक्रिय है।
URL में पासवर्ड सुविधाजनक है, लेकिन खतरनाक है। requests में लीक तब प्रकट होती थी जब क्रेडेंशियल्स प्रॉक्सी के पते में user:pass@host:port के रूप में लिखे जाते थे। यह प्रारूप से दूर जाने का कारण नहीं है, लेकिन लाइब्रेरी को ताजा रखने का कारण है।
रीडायरेक्ट लक्ष्य से नहीं आ सकता। कैप्चा पृष्ठ, सहमति बैनर, लिंक शॉर्टनर और CDN भी 3xx का उत्तर देते हैं। जितना अधिक "लिंक के पीछे चलना" क्रॉलर में होगा, उतनी ही अधिक हमले की सतह होगी।

यदि पासवर्ड फिर भी लीक हो जाए तो नुकसान को कैसे सीमित करें

पूर्ण रूप से लीक को समाप्त नहीं किया जा सकता: कल अगली CVE जारी होगी। इसलिए यह महत्वपूर्ण है कि एक लीक की कीमत कितनी है।

एक प्रोजेक्ट, एक पहुंच। सभी पार्सरों के लिए एक सामान्य लॉगिन न रखें। ProxyCove में प्रत्येक खरीदे गए प्रॉक्सी को एक अलग लॉगिन और पासवर्ड जोड़ी मिलती है, इसलिए एक स्क्रिप्ट का लीक हुआ पहुंच अन्य का ट्रैफिक नहीं खोलता।
एक पहुंच पर जरूरत से ज्यादा ट्रैफिक न रखें। कार्य के लिए थोड़ा-थोड़ा करके भरें, न कि छह महीने पहले से।
खर्च पर नज़र रखें। बिना कार्यों की संख्या में वृद्धि के ट्रैफिक में अचानक वृद्धि — यह पहला संकेत है कि आपके पहुंच का कोई और उपयोग कर रहा है।
संदेह होने पर तुरंत पासवर्ड बदलें और एक कार्यक्रम के अनुसार। इसे बिना ठहराव के कैसे व्यवस्थित किया जाए, इस पर प्रॉक्सी पासवर्ड रोटेशन पर गाइड में बताया गया है।

किस प्रकार का प्रॉक्सी चुनें और इसमें क्या है

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

निष्कर्ष

प्रॉक्सी का पासवर्ड बिना हैकिंग, बिना वायरस और बिना मानव त्रुटि के लीक हो सकता है: पुरानी libcurl, किसी अन्य डोमेन पर रीडायरेक्ट और पुनः उपयोग किए गए कनेक्शन के लिए पर्याप्त है। चेकलिस्ट संक्षिप्त है: curl और libcurl 8.21.0 से, requests 2.31.0 से, urllib3 1.26.19 या 2.2.2 से, ताजा libsoup, प्रत्येक प्रॉक्सी के लिए अलग सत्र, रीडायरेक्ट पर नियंत्रण और एक जीवित परीक्षण। इसके अलावा, प्रत्येक प्रोजेक्ट के लिए अलग पहुंच, ताकि एक लीक एक स्क्रिप्ट की कीमत हो, न कि पूरे बैलेंस की।