
प्रकाशित urllib3 मुद्दों के लिए पैच-डिफ अनुसंधान: पिन किए गए रिलीज़, मूल ऑफ़लाइन हार्नेस, पहले/बाद का व्यवहार और सौम्य नियंत्रण।
निर्माता और अनुरक्षक Sergio Rodriguez (SSH-PuR66)। प्रयोग हार्नेस और विश्लेषण मेरे हैं; प्रकाशित भेद्यताएँ, urllib3 कोड और अपस्ट्रीम फ़िक्स अपने मूल श्रेय को बनाए रखते हैं।
लेखक की शोध विधि · रीडायरेक्ट हार्नेस · चंक-फ़्रेमिंग अध्ययन
एक रीडायरेक्ट गंतव्य बदल देता है जबकि तीन संवेदनशील हेडर जुड़े रहते हैं। एक फ़्रेमिंग पार्सर ऐसा इनपुट स्वीकार करता है जिसे अगला रिलीज़ अस्वीकार कर देता है। Afterimage प्रकाशित प्रोटोकॉल फ़िक्स को छोटे, निरीक्षण-योग्य पहले/बाद के प्रयोगों में बदल देता है।
मैंने हार्नेस और नियंत्रण मामले पिन किए गए, अपरिवर्तित urllib3 रिलीज़ के आसपास बनाए। प्रत्येक परिणाम पैकेज हैश, कैप्चर किया गया व्यवहार, फ़िक्स्चर सीमा और अपस्ट्रीम श्रेय दर्ज करता है।
| अध्ययन | तुलना की गई रिलीज़ | दर्ज किया गया कॉर्पस | निरीक्षण करें |
|---|---|---|---|
| रीडायरेक्ट-हेडर सीमा · CVE-2026-44431 | urllib3 2.6.3 / 2.7.0 | 12 मामले, जिनमें प्रभावित व्यवहार और सौम्य नियंत्रण शामिल हैं | परिणाम · हार्नेस |
| चंक फ़्रेमिंग · CVE-2026-97689 | urllib3 2.7.0 / 2.8.0 | 32 सीमित ऑफ़लाइन मामले | विधि और परिणाम |
शोध प्रकार: प्रकाशित मुद्दों का स्वतंत्र पुनरुत्पादन। मापी गई सीमा: लाइब्रेरी आर्ग्युमेंट हैंडलिंग और इन-मेमोरी फ़्रेमिंग व्यवहार। एप्लिकेशन शोषणीयता और संसाधन की कमी इन फ़िक्स्चर परिणामों से बाहर रहते हैं।
CVE-2026-44431 · urllib3 2.6.3 → 2.7.0 · 27 सितंबर 2026 को पुनरुत्पादित
एक अनुरोध एक ओरिजिन पर तीन संवेदनशील हेडर ले जाता है। एक रीडायरेक्ट गंतव्य बदल देता है। क्या अगला अनुरोध अभी भी उन्हें ले जाता है?
यह स्वतंत्र रिग्रेशन दो सटीक urllib3 रिलीज़ से वास्तविक रीडायरेक्ट कार्यान्वयन चलाता है। संस्करण 2.6.3 प्रभावित निम्न-स्तरीय API के माध्यम से सभी तीन हेडर बनाए रखता है। संस्करण 2.7.0 उन्हें हटा देता है। एक सौम्य हेडर बच जाता है, और सामान्य अनुरोध अभी भी काम करते हैं।
| फ़िक्स्चर | urllib3 2.6.3 | urllib3 2.7.0 |
|---|---|---|
| निम्न-स्तरीय क्रॉस-ओरिजिन रीडायरेक्ट | 3 संवेदनशील हेडर बनाए रखे गए | 0 बनाए रखे गए |
| लोअरकेस नामों वाला वही मामला | 3 बनाए रखे गए | 0 बनाए रखे गए |
| उच्च-स्तरीय API नियंत्रण | 0 बनाए रखे गए | 0 बनाए रखे गए |
| सीधा 200 प्रतिक्रिया | 3 इच्छानुसार बनाए रखे गए | 3 इच्छानुसार बनाए रखे गए |
| रीडायरेक्ट स्पष्ट रूप से अक्षम | एक कॉल; 302 लौटाया गया | एक कॉल; 302 लौटाया गया |
| कस्टम हटाने का सेट सौम्य मार्कर जोड़ता है | सभी 4 हेडर बनाए रखे गए | सभी 4 हटा दिए गए |
12/12 परिदृश्य अपेक्षाएँ पास हुईं। प्रत्येक परिदृश्य प्रतिक्रिया स्थिति, ट्रांसपोर्ट कॉल गणना, प्रारंभिक हेडर सेट, सौम्य-हेडर परिणाम, और यह भी जाँचता है कि कॉलर के हेडर में परिवर्तन नहीं हुआ। भेद्य परिणाम एक अपेक्षित आधारभूत परिणाम है, पास होने वाला सुरक्षा जाँच नहीं।
मशीन-पठनीय परिणाम में कैप्चर किए गए आर्ग्युमेंट, सटीक व्हील हैश, रनटाइम, टेस्ट-सोर्स हैश, श्रेय और पुनरुत्पादन समय शामिल हैं।
7 मई 2026 को प्रकाशित अपस्ट्रीम सलाह, urllib3 के प्रॉक्सीड निम्न-स्तरीय रीडायरेक्ट पथ में एक सूचना-प्रकटीकरण मुद्दे की पहचान करती है। यह संस्करणों >=1.23, <2.7.0 को प्रभावित के रूप में सूचीबद्ध करती है। ProxyManager.connection_from_url(...).urlopen(..., assert_same_host=False) को कॉल करने से कॉन्फ़िगर किए गए संवेदनशील हेडर किसी अन्य ओरिजिन पर रीडायरेक्ट किए गए अनुरोध में चले जाते थे। उच्च-स्तरीय मैनेजर API पहले से ही उन्हें हटा देता था।
अपस्ट्रीम फ़िक्स पुनरावर्ती निम्न-स्तरीय अनुरोध से पहले Retry.remove_headers_on_redirect लागू करता है। हमारा लोअरकेस-हेडर मामला हेडर-नाम केसिंग पर अपस्ट्रीम रिग्रेशन के ध्यान का अनुसरण करता है। कस्टम-हटाने का मामला जाँचता है कि नियम केवल तीन डिफ़ॉल्ट नामों से आगे बढ़कर कॉन्फ़िगर किए गए सेट का सम्मान करता है।
सलाहकार में christos-cantina-security को रिपोर्टर, illia-v को समन्वयक, और sethmlarson को उपचार समीक्षक के रूप में श्रेय दिया गया है। यहाँ Sergio Rodriguez का योगदान स्वतंत्र ऑफ़लाइन हार्नेस और पहले/बाद का विश्लेषण है। यह उनके प्रकाशित CVE का पुनरुत्पादन है।
Python 3.10 या बाद के संस्करण का उपयोग करें। किसी pip इंस्टॉल या वर्चुअल एनवायरनमेंट की आवश्यकता नहीं है: प्रत्येक संस्करण को एक ताज़ा पृथक सबप्रोसेस में उसके शुद्ध-Python व्हील से सीधे आयात किया जाता है।
पोर्टफोलियो रिपॉज़िटरी रूट से:
python -B ./labs/cve-replay/run_replay.py --fetch
python -B ./labs/cve-replay/run_replay.py
पहला कमांड दो सटीक wheels को लैब की अनदेखी की गई .cache/wheels/ डायरेक्टरी में डाउनलोड करता है और उनके SHA-256 हैश को मैनिफ़ेस्ट के विरुद्ध जाँचता है। दूसरा कमांड उस कैशे का उपयोग बिना डाउनलोड किए करता है। स्टैंडअलोन सोर्स चेकआउट के लिए, python -B run_replay.py --fetch चलाएँ, फिर वही कमांड --fetch के बिना चलाएँ। --cache एक भिन्न स्थानीय कैशे डायरेक्टरी स्वीकार करता है।
HTTPConnectionPool._make_request को दो-प्रतिक्रिया वाले ट्रांसपोर्ट से बदल दिया जाता है: एक निश्चित लोकेशन के साथ 302, फिर एक 200। फ़िक्स्चर उस सीमा तक पहुँचने वाले आर्ग्युमेंट्स को कैप्चर करता है। urllib3 की पार्सिंग, रिट्राई नीति, हेडर फ़िल्टरिंग, और पुनरावर्ती रीडायरेक्ट हैंडलिंग चयनित wheel से अपरिवर्तित निष्पादित होती हैं।
सभी गंतव्य निश्चित आरक्षित .invalid नाम हैं; सभी हेडर मान DUMMY से शुरू होते हैं। सॉकेट निर्माण और DNS फ़ंक्शन तुरंत त्रुटि उत्पन्न करते हैं। लाइब्रेरी की इम्पोर्ट-समय IPv6 क्षमता जाँच को अस्वीकार कर दिया जाता है और अलग से रिकॉर्ड किया जाता है; रीप्ले परिदृश्य कोई नेटवर्क ऑपरेशन का प्रयास नहीं करते। कोई सुनता हुआ सर्वर या लाइव लक्ष्य नहीं है।
यह रीडायरेक्ट आर्ग्युमेंट हैंडलिंग को मान्य करता है। यह एंड-टू-एंड प्रॉक्सी ट्रैफ़िक को मापता नहीं है। संस्करण 2.7.0 इस विशेष CVE के लिए पहला फ़िक्स है; यह ऐतिहासिक तुलना इसे नए समर्थित रिलीज़ों की तुलना में चुनने की सिफ़ारिश नहीं है।
फ़िक्स्चर स्क्रिप्ट और विश्लेषण मूल पोर्टफ़ोलियो कार्य हैं। urllib3 एक अपस्ट्रीम प्रोजेक्ट है जो अपने MIT लाइसेंस के अंतर्गत वितरित किया जाता है; इसका कोड और रिलीज़ wheels पोर्टफ़ोलियो सोर्स आर्काइव में पुनर्वितरित नहीं किए जाते। उन्हें PyPI से अलग से डाउनलोड किया जाता है और प्रयोग के लिए अपरिवर्तित इम्पोर्ट किया जाता है।