LiteLLM के संस्करण 1.82.7 और 1.82.8, जिन्हें 24 मार्च 2026 को PyPI पर प्रकाशित किया गया था, सार्वजनिक रूप से दुर्भावनापूर्ण के रूप में पहचाना गया था। सबसे महत्वपूर्ण तकनीकी विवरण केवल यह नहीं है कि एक पैकेज को विषाक्त किया गया था, बल्कि यह कि संस्करण 1.82.8 ने एक लिटेलएम_इनिट.पीथ फ़ाइल। पाइथन में, एक में निष्पादन योग्य पंक्तियाँ .पथ फ़ाइलें द्वारा संसाधित की जाती हैं साइट इंटरप्रेटर की शुरुआत में मॉड्यूल, इसलिए इसने इस घटना को आयात-प्रेरित समझौते से बदलकर कुछ ऐसा बना दिया जो सामान्य पाइथन स्टार्टअप पर भी सक्रिय हो सकता है। सार्वजनिक घटना ट्रैकिंग यह भी बताती है कि 1.82.7 ने अपना पेलोड इसमें ले जाया था। लिटेलएम/प्रॉक्सी/प्रॉक्सी_सर्वर.पाइ, जबकि 1.82.8 ने उस पेलोड और नए दोनों को वहन किया .पथ लॉन्चर। (गिटहब)
यह अंतर इसलिए मायने रखता है क्योंकि LiteLLM कोई दिखावटी सहायक नहीं है। इसका अपना दस्तावेज़ीकरण और PyPI विवरण इसे एक Python SDK और एक AI गेटवे दोनों के रूप में प्रस्तुत करता है, जो राउटिंग, लॉगिंग, लागत ट्रैकिंग, प्रमाणीकरण, वर्चुअल कीज़, और MCP गेटवे समर्थन जैसी सुविधाओं के साथ 100 से अधिक मॉडल प्रदाताओं के लिए एक एकीकृत इंटरफ़ेस प्रदान करता है। कई टीमों में यह स्टैक में सबसे अधिक मूल्यवान रहस्यों के करीब होता है: क्लाउड क्रेडेंशियल, मॉडल प्रदाता कुंजियाँ, टेनेंट कुंजियाँ, गेटवे कॉन्फ़िगरेशन, प्रॉम्प्ट लॉग, और इंटीग्रेशन टोकन। यहाँ कोई समझौता "केवल एक निर्भरता की समस्या" नहीं है। यह एआई इंफ्रास्ट्रक्चर के लिए एक कंट्रोल प्लेन समस्या है। (पाइपाई)
LiteLLM रिपॉजिटरी पर सार्वजनिक घटना थ्रेड्स दुर्भावनापूर्ण पैकेज के व्यवहार को प्रमाण-पत्र चोरी और … को एक्सफिल्ट्रेशन के रूप में वर्णित करते हैं। https://models.litellm.cloud/. विस्तृत इश्यू टेक्स्ट में कहा गया है कि पेलोड ने पर्यावरण चर और संवेदनशील फ़ाइलें एकत्र कीं, बंडल को हाइब्रिड एन्क्रिप्शन का उपयोग करके एन्क्रिप्ट किया, और इसे HTTP POST के माध्यम से भेजा। व्यापक घटना को ट्रैक करने वाली एक संबंधित इश्यू में कहा गया है कि समझौता किए गए PyPI रिलीज़ हमलावर ने प्रोजेक्ट के सामान्य सार्वजनिक रिलीज़ फ्लो के बजाय मेंटेनर के रिलीज़ पाथ के माध्यम से प्रकाशित किए, और PyPI पर प्रोजेक्ट पेज वर्तमान में दिखाता है 1.82.6 नवीनतम दृश्यमान रिलीज़ के रूप में, 1.82.7 या 1.82.8 नहीं।गिटहब)
परिणाम एक आपूर्ति श्रृंखला घटना है जिसका स्वरूप सुरक्षा टीमों को तुरंत पहचानना चाहिए। हमलावर को LiteLLM उपयोगकर्ताओं का सीधे तौर पर एक उजागर वेब एंडपॉइंट के माध्यम से शोषण करने की आवश्यकता नहीं थी। उन्हें केवल एक विश्वसनीय रिलीज़ को एक विश्वसनीय पैकेज चैनल में पहुँचाना था। एक बार ऐसा हो जाने पर, डेवलपर मशीनें, CI रनर्स, साझा गेटवे, और एजेंट होस्ट सभी संग्रहण बिंदु बन जाते हैं। यह पैटर्न पहले के इकोसिस्टम समझौतों से परिचित है, लेकिन AI स्टैक इसे और भी बदतर बना देता है क्योंकि एक ही मशीन में अक्सर कई LLM विक्रेताओं, क्लाउड API, वेक्टर स्टोर, ऑब्ज़र्वबिलिटी बैकएंड, और टूल इंटीग्रेशन की कुंजियाँ एक साथ मौजूद होती हैं। (गिटहब)
LiteLLM क्या है और यह पैकेज क्यों महत्वपूर्ण है
जब किसी पॉइज़न्ड पाइथन पैकेज का नाम किसी सामान्य एप्लिकेशन डिपेंडेंसी जैसा लगे, तो उसके प्रभाव को कम आंकना आसान होता है। LiteLLM एक एकल-उद्देश्य वाली हेल्पर लाइब्रेरी की तुलना में AI एप्लिकेशनों के लिए एक मल्टीप्लेक्सिंग लेयर के करीब है। इसके सार्वजनिक दस्तावेज़ दो मुख्य उपयोग पैटर्न का वर्णन करते हैं। एक है पाइथन SDK, जो एप्लिकेशन कोड को एक ही इंटरफ़ेस के माध्यम से कई मॉडल प्रदाताओं को कॉल करने की अनुमति देता है। दूसरा है प्रॉक्सी और गेटवे लेयर, जो कई मॉडलों, उपयोगकर्ताओं और टीमों के लिए नीति और ट्रैफ़िक को केंद्रीकृत करती है। इसी दस्तावेज़ में राउटिंग, बजट नियंत्रण, लॉगिंग, प्रॉम्प्ट प्रबंधन, सीक्रेट मैनेजर एकीकरण, और MCP गेटवे सुविधाएँ भी बताई गई हैं। यह बिल्कुल उसी प्रकार का सॉफ़्टवेयर है जो विशेषाधिकार प्राप्त रहस्यों और साझा बुनियादी ढांचे के पास चलने लगता है। (पाइपाई)
पैकेज का PyPI पेज उस आर्किटेक्चर को मजबूत करता है। यह स्पष्ट रूप से LiteLLM को एक ऐसे माध्यम के रूप में प्रचारित करता है जिससे 100 से अधिक LLMs तक या तो प्रॉक्सी सर्वर या Python SDK के माध्यम से पहुँचा जा सके, और यह MCP-शैली के टूलिंग के साथ एकीकरण का दस्तावेजीकरण करता है। इसका मतलब है कि वही घटक एक स्थानीय डेवलपर लैपटॉप पर, सर्विस मेष के अंदर, एक केंद्रीय इन्फरेंस गेटवे में, IDE प्लगइन वर्कफ़्लो में, या रिमोट टूल्स से संवाद करने वाली ऑटोमेशन के अंदर मौजूद हो सकता है। किसी हमले को गंभीर होने के लिए, हमलावर को हर डिप्लॉयमेंट मोड को समझौता करने की आवश्यकता नहीं है। उनमें से कोई भी एक स्थिति पहले से ही पर्याप्त हो सकती है। (पाइपाई)
वह आर्किटेक्चर यह भी बदल देता है कि डिफेंडर्स को विस्फोट त्रिज्या (blast radius) के बारे में कैसे सोचना चाहिए। एक समझौता की गई लॉगिंग लाइब्रेरी प्रोसेस मेमोरी में मौजूद टोकन उजागर कर सकती है। एक समझौता की गई वेब फ्रेमवर्क पैकेज उसके साथ निर्मित सेवाओं का एक उपसमूह उजागर कर सकता है। एक समझौता किया गया AI गेटवे पैकेज निर्भरताओं का एक मैट्रिक्स उजागर कर सकता है: OpenAI कुंजियाँ, Anthropic कुंजियाँ, Azure OpenAI क्रेडेंशियल, Bedrock कॉन्फ़िगरेशन, Vertex सेटिंग्स, Redis या Postgres कनेक्शन स्ट्रिंग्स, टूल गेटवे सीक्रेट्स, और जो कुछ भी आसपास का वातावरण गेटवे को संचालित करने के लिए उपयोग करता है। LiteLLM घटना के सार्वजनिक मुद्दे के पाठ में स्पष्ट रूप से उन कई लक्षित श्रेणियों को सूचीबद्ध किया गया है। (गिटहब)
घटना को समझने का एक उपयोगी तरीका यह है कि LiteLLM की तैनाती की स्थिति को संभावित जोखिम में पड़े रहस्यों से जोड़ा जाए।
| पर्यावरण | LiteLLM वहाँ क्यों दिखाई देता है | उच्च मूल्य के रहस्य संभवतः आस-पास हैं। | अब यह क्यों मायने रखता है |
|---|---|---|---|
| डेवलपर लैपटॉप | स्थानीय SDK का उपयोग, IDE उपकरण, एजेंट प्रयोग | एसएसएच कीज़, क्लाउड सीएलआईज़ .env फ़ाइलें, गिट क्रेडेंशियल | सार्वजनिक घटना विवरणों में कहा गया है कि उन श्रेणियों को निशाना बनाया गया था।गिटहब) |
| सीआई रनर | परीक्षण इंस्टॉलेशन, पैकेजिंग, रिलीज़ सत्यापन | PyPI पब्लिश टोकन, क्लाउड डिप्लॉय कीज़, GitHub टोकन | रखरखावकर्ता ने कहा कि उजागर रिलीज़ पथ में CI में एक PyPI पब्लिश टोकन शामिल था, Trivy समझौते के संदर्भ में।हैकर न्यूज़) |
| साझा एआई गेटवे | प्रॉक्सी मोड, बजट, प्रमाणीकरण, लॉगिंग, बहु-किरायेदार राउटिंग | प्रदाता एपीआई कुंजियाँ, किरायेदार वर्चुअल कुंजियाँ, लॉग्स | LiteLLM के दस्तावेज़ और PyPI पेज में ठीक उन्हीं गेटवे फ़ंक्शन्स का वर्णन है। (पाइपाई) |
| एजेंट होस्ट | MCP गेटवे और टूल निष्पादन | टूल क्रेडेंशियल्स, कॉलबैक सीक्रेट्स, पॉलिसी कॉन्फ़िग | LiteLLM दस्तावेज़ MCP उपयोग और गेटवे एकीकरण को प्रदर्शित करते हैं।पाइपाई) |
| कुबेरनेट्स वर्कलोड | स्व-होस्टेड गेटवे या एआई ऐप तैनाती | क्यूबेकॉन्फिग, सर्विस अकाउंट टोकन, माउंट किए गए सीक्रेट्स | सार्वजनिक मैलवेयर विवरण में स्पष्ट रूप से संग्रह लक्ष्यों में कुबेरनेट्स-संबंधित क्रेडेंशियल्स शामिल हैं।गिटहब) |
अधिकांश सतही रिपोर्टिंग "इस पैकेज में एक क्रेडेंशियल स्टीलर था" पर रुक जाती है। यह सच है, लेकिन अधूरा है। अधिक महत्वपूर्ण निष्कर्ष यह है कि एक गेटवे पैकेज उन सटीक प्रकार के रहस्यों को एकत्र करता है जिन्हें एक हमलावर एक साथ चुराना चाहता है। इसीलिए एक्सपोजर का मूल्यांकन करने वाली टीमों को वातावरणों को केवल पैकेज के महत्व के आधार पर नहीं, बल्कि विशेषाधिकार एकाग्रता के आधार पर रैंक करना चाहिए। यदि कोई छोटा साझा गेटवे नोड किरायेदार कुंजियाँ और मॉडल-प्रदाता क्रेडेंशियल्स को केंद्रित करता है, तो वह दस सामान्य डेवलपर लैपटॉप की तुलना में अधिक तत्काल ध्यान का हकदार हो सकता है। यह रैंकिंग एक विवेकपूर्ण निर्णय है, लेकिन यह सीधे तौर पर उस कार्य से निकलता है जिसके लिए LiteLLM को डिज़ाइन किया गया है। (पाइपाई)
25 मार्च, 2026 तक क्या पुष्ट हुआ है
सबसे विश्वसनीय सार्वजनिक तथ्य वर्तमान में LiteLLM GitHub इश्यूज़, Python दस्तावेज़ीकरण, PyPI प्रोजेक्ट पेज और उन्हीं तकनीकी कलाकृतियों की ओर इशारा करने वाली अनुवर्ती रिपोर्टिंग से मिलते हैं। "litellm PyPI पैकेज समझौता — पूर्ण समयरेखा और स्थिति" शीर्षक वाले इश्यू में कहा गया है कि दुर्भावनापूर्ण संस्करण 1.82.7 और 1.82.8 प्रकाशित किए गए थे, कि 1.82.7 में एक पेलोड एम्बेड किया गया था। लिटेलएम/प्रॉक्सी/प्रॉक्सी_सर्वर.पाइ, और कि 1.82.8 जोड़ा गया लिटेलएम_इनिट.पीथ, जिससे किसी भी सामान्य पाइथन स्टार्टअप पर निष्पादन संभव हो जाता है। एक और समस्या, जो विशेष रूप से पर केंद्रित है .पथ फ़ाइल, डेटा संग्रह और एक्सफ़िल्ट्रेशन लॉजिक का वर्णन करती है और एक्सफ़िल्ट्रेशन एंडपॉइंट को के रूप में नामित करती है https://models.litellm.cloud/. (गिटहब)
PyPI प्रोजेक्ट पेज वर्तमान में दिखाता है लिटेल्म 1.82.6 22 मार्च, 2026 को जारी नवीनतम दृश्यमान संस्करण के रूप में। प्रोजेक्ट पेज 1.82.7 या 1.82.8 को वर्तमान डाउनलोड करने योग्य संस्करणों के रूप में सूचीबद्ध नहीं करता है। LiteLLM इश्यू ट्रैकर पर उपयोगकर्ताओं ने रिपोर्ट किया कि PyPI ने पैकेज को क्वारंटाइन कर दिया था, और LiteLLM के मेंटेनर ने Hacker News पर लिखा कि पैकेज क्वारंटाइन में था और बाद में कहा कि प्रभावित संस्करण PyPI से हटा दिए गए हैं। यह संयोजन इस परिचालन धारणा का दृढ़ता से समर्थन करता है कि दुर्भावनापूर्ण अपलोड शीघ्र ही हटा दिए गए थे, लेकिन यह उन लोगों की तत्काल आवश्यकता को कम नहीं करता जिन्होंने उन्हें जोखिम की अवधि के दौरान इंस्टॉल किया था। (पाइपाई)
एक बिंदु जो सटीकता का हकदार है, वह रिलीज़ की उत्पत्ति का प्रश्न है। घटना-ट्रैकिंग रिपोर्ट कहती है कि दुर्भावनापूर्ण PyPI अपलोड्स परियोजना के सामान्य सार्वजनिक GitHub रिलीज़ प्रवाह का हिस्सा नहीं थे। यह सार्वजनिक GitHub रिलीज़ इतिहास और PyPI परियोजना पृष्ठ की दृश्यमान स्थिति से मेल खाता है: वर्तमान सार्वजनिक परियोजना पृष्ठ PyPI पर 1.82.6 दिखाता है, जबकि घटना ट्रैकिंग हमलावर द्वारा प्रकाशित दुर्भावनापूर्ण संस्करणों के रूप में 1.82.7 और 1.82.8 को इंगित करती है। टीमों को इसे एक मामूली पैकेजिंग विसंगति नहीं माननी चाहिए। इसका मतलब है कि हमलावर ने डिफ़ॉल्ट शाखा में कोड परिवर्तन से कहीं अधिक गंभीर कुछ हासिल किया: वे उपभोक्ताओं द्वारा भरोसेमंद रिलीज़ चैनल तक पहुँच गए। (गिटहब)
एक्सफिल्ट्रेशन पथ का सार्वजनिक विवरण भी काफी विशिष्ट है। समस्या पाठ कहता है कि .पथ फ़ाइल ने base64-ओब्फुस्केटेड पाइथन पेलोड को इसके माध्यम से लॉन्च किया। सबप्रोसेस.पोपन, फ़ाइलें और पर्यावरण डेटा एकत्र किए, उन्हें AES-256-CBC और RSA से एन्क्रिप्ट किया, और परिणाम को भेज दिया मॉडल्स.लिटेल्एम.क्लाउड के साथ एक्स-फ़ाइलनाम: tpcp.tar.gz हेडर। यह IOC-आधारित हंटिंग के लिए पर्याप्त से अधिक विवरण है, भले ही पूरा विक्रेता पोस्टमॉर्टम अभी प्रकाशित न हुआ हो। आपको उस डोमेन, उस फ़ाइल नाम और उस फ़ाइल पथ की खोज शुरू करने के लिए एक परिष्कृत घटना रिपोर्ट का इंतज़ार करने की आवश्यकता नहीं है।गिटहब)
रखरखावकर्ता ने हैकर न्यूज़ पर एक महत्वपूर्ण श्रेय संबंधी सुराग भी पोस्ट किया। उस चर्चा में उन्होंने कहा कि यह समस्या हाल ही में हुए Trivy समझौते से उत्पन्न हुई प्रतीत होती है और उजागर किया गया रहस्य एक पीवाईपीआई_पब्लिश टोकन को प्रोजेक्ट के CI में एक एनवायरनमेंट वेरिएबल के रूप में संग्रहीत किया गया था। यह कोई औपचारिक पोस्टमॉर्टम नहीं है, और इसे एक विकसित होती बयान के रूप में लिया जाना चाहिए, लेकिन यह Trivy घटना और CI में लंबे समय तक चलने वाली रिलीज़ क्रेडेंशियल्स के ज्ञात जोखिम के आसपास व्यापक सार्वजनिक टाइमलाइन से मेल खाता है। (हैकर न्यूज़)
एक संक्षिप्त संस्करण-दर-संस्करण सारांश तात्कालिक को केवल रोचक से अलग करने में मदद करता है।
| संस्करण | जहाँ दुष्ट तर्क रहता था | इसकी वजह क्या बनी? | कार्यात्मक अर्थ |
|---|---|---|---|
| 1.82.7 | लिटेलएम/प्रॉक्सी/प्रॉक्सी_सर्वर.पाइ | प्रॉक्सी कोड सहित पथ आयात करें | अभी भी गंभीर है, लेकिन हर Python स्टार्टअप इसे ट्रिगर नहीं करेगा। (गिटहब) |
| 1.82.8 | लिटेलएम_इनिट.पीथ और प्रॉक्सी_सर्वर.पाइथन | सामान्य पाइथन स्टार्टअप के माध्यम से साइट संसाधित करना | बहुत व्यापक ट्रिगर सतह, क्योंकि .पथ पाइथन स्टार्टअप पर निष्पादन योग्य पंक्तियाँ चलती हैं।गिटहब) |
उन दोनों पंक्तियों के बीच का अंतर "खतरनाक पैकेज" और "इंटरप्रेटर स्टार्टअप ट्रैप" के बीच के अंतर के समान है। इसलिए 1.82.8 को घटना प्रतिक्रिया और सार्वजनिक संचार दोनों में अलग से संबोधित किया जाना चाहिए।गिटहब)
क्यों .पथ फ़ाइल ने घटना को खराब से तात्कालिक में बदल दिया।
पाइथन का अपना दस्तावेज़ीकरण इस बिंदु पर असामान्य रूप से स्पष्ट है। साइट इम्पोर्ट स्टेटमेंट के साथ पाइथन शुरू किए जाने पर ही मॉड्यूल स्वचालित रूप से इनिशियलाइज़ेशन के दौरान इम्पोर्ट हो जाता है। -एस. पथ कॉन्फ़िगरेशन फ़ाइलें जो पर समाप्त होती हैं .पथ साइट के अंदर की निर्देशिकाओं में निष्पादन योग्य पंक्तियाँ हो सकती हैं, और 'के साथ शुरू होने वाली पंक्तियाँ' आयात करें निष्पादित किए जाते हैं। दस्तावेज़ और आगे बढ़कर चेतावनी देते हैं कि एक निष्पादन योग्य पंक्ति एक में .पथ यह फ़ाइल हर पाइथन स्टार्टअप पर चलती है, चाहे संबंधित मॉड्यूल का वास्तव में उपयोग किया जाना हो या नहीं। (पाइथन दस्तावेज़ीकरण)
वह व्यवहार कई इंजीनियरों की सोच से कहीं अधिक पुराना और अस्पष्ट है। दैनिक पैकेजिंग कार्य में, लोग ज्यादातर इसके बारे में सोचते हैं। .पथ फ़ाइलें एक पाथ-एक्सटेंशन तंत्र के रूप में काम करती हैं। वे वही हैं, लेकिन वे एक इंटरप्रेटर-स्टार्टअप निष्पादन प्राइमिटिव भी हैं। वैध टूलिंग ने वर्षों से इस व्यवहार का उपयोग किया है, और यही कारण है कि जब इसका दुरुपयोग किया जाता है तो यह खतरनाक हो जाता है। LiteLLM घटना ने कोई नया पाइथन ट्रिक नहीं बनाई। इसने एक कम-समझा गया लेकिन आधिकारिक तौर पर समर्थित स्टार्टअप व्यवहार का दुरुपयोग किया। (पाइथन दस्तावेज़ीकरण)
व्यावहारिक निहितार्थ सरल है: यदि 1.82.8 किसी वातावरण में उतरता साइट-पैकेज, तो "हम प्रभावित हैं या नहीं" की जाँच के कई सामान्य तरीके स्वयं ही पेलोड को पुनः सक्रिय कर सकते हैं। एक Python REPL खोलना, एक स्क्रिप्ट लॉन्च करना, IDE-एकीकृत Python प्रक्रिया चलाना, या सामान्य इंटरप्रेटर स्टार्टअप पर निर्भर पैकेज टूल्स को कॉल करना—ये सभी दूषित वातावरण में असुरक्षित हो सकते हैं। इसलिए रक्षकों को एक ट्रायाज फ्लो की आवश्यकता होती है जो पहले फ़ाइल सिस्टम निरीक्षण का उपयोग करे और यदि आवश्यक हो तो दूसरे स्थान पर सामान्य Python स्टार्टअप का। की उपस्थिति पाइथन -S एक आधिकारिक विकल्प के रूप में यह यहाँ कोई तुच्छ बिंदु नहीं है; यह सुरक्षित संचालन पैटर्न का हिस्सा है।पाइथन दस्तावेज़ीकरण)
यह स्टार्टअप व्यवहार यह भी समझाता है कि "हमने कभी प्रोडक्शन में LiteLLM इम्पोर्ट नहीं किया" 1.82.8 के लिए पर्याप्त बचाव क्यों नहीं है। वह लाइन 1.82.7 के लिए मायने रख सकती है, जहाँ इंसिडेंट ट्रैकर कहता है कि पेलोड मौजूद था। प्रॉक्सी_सर्वर.पाइथन और प्रॉक्सी कोड में एक आयात पथ की आवश्यकता थी। यह 1.82.8 मामले को हल नहीं करता है, क्योंकि .पथ लॉन्चर को सामान्य एप्लिकेशन लॉजिक को यह तय करने का मौका मिलने से पहले ही चलाने के लिए डिज़ाइन किया गया था कि उसे क्या चाहिए।गिटहब)
सुरक्षा समीक्षकों के लिए यहाँ एक द्वितीय-स्तरीय सबक भी है। पैकेजिंग और इंटरप्रेटर प्रारंभिकीकरण अलग-अलग खतरा क्षेत्र नहीं हैं। यदि आपका सुरक्षित कोडिंग समीक्षा मॉडल "निर्भरता स्थापना" को एक चरण और "एप्लिकेशन निष्पादन" को दूसरे चरण के रूप में मानता है, .पथ दुरुपयोग उस साफ-सुथरी विभाजन को तोड़ देता है। इंस्टॉलेशन अंतर्निहित निष्पादन बन जाता है, और भविष्य के इंटरप्रेटर की शुरुआत सक्रियण घटनाएँ बन जाती हैं। यह क्लासिक भेद्य-लाइब्रेरी CVEs से एक अलग मानसिक मॉडल है, जहाँ एक खामी केवल तभी मायने रखती है जब कोड हमलावर-नियंत्रित इनपुट के साथ एक खराब फ़ंक्शन तक पहुँचता है। LiteLLM 1.82.8 का मामला सामान्य लाइब्रेरी दुरुपयोग की तुलना में स्टार्टअप पर्सिस्टेंस के करीब है। (पाइथन दस्तावेज़ीकरण)
सार्वजनिक रूप से रिपोर्ट किए गए पेलोड ने क्या लक्षित किया
वर्तमान में उपलब्ध सबसे विस्तृत सार्वजनिक विवरण LiteLLM मुद्दे का वर्णन है। लिटेलएम_इनिट.पीथ डेटा-एक्सफिल्ट्रेशन मैलवेयर के रूप में। उस समस्या में कहा गया है कि पेलोड ने क्रेडेंशियल्स होने की संभावना वाले एनवायरनमेंट वेरिएबल्स और फ़ाइलों को एकत्र किया, डेटा को एन्क्रिप्ट किया, और इसे हमलावर-नियंत्रित एंडपॉइंट पर पोस्ट किया। व्यापक टाइमलाइन संबंधी समस्या लक्षित श्रेणियों का सारांश प्रस्तुत करती है: SSH कुंजी, पर्यावरण चर, AWS, GCP, Azure, Kubernetes क्रेडेंशियल, क्रिप्टो वॉलेट, डेटाबेस पासवर्ड, SSL निजी कुंजी, शेल इतिहास, और CI या CD कॉन्फ़िगरेशन। साइमन विलिसन का लेख, जो उसी तकनीकी समस्या की ओर इशारा करता है, प्रभावित फ़ाइल सिस्टम लक्ष्यों की एक लंबी सूची को उजागर करता है, जिसमें शामिल हैं ~/.ssh/, ~/.git-credentials, ~/.aws/, ~/.kube/, ~/.azure/, ~/.docker/, और कई शेल इतिहास फ़ाइलें। (गिटहब)
यह लक्ष्य समूह यादृच्छिक नहीं है। यह डेवलपर और प्लेटफ़ॉर्म-प्रशासक वातावरण के लिए अनुकूलित है। SSH सामग्री रिपॉजिटरी और अवसंरचना तक पहुंच सक्षम करती है। क्लाउड CLI निर्देशिकाएँ लंबे समय तक चलने वाले या ताज़ा किए जा सकने वाले क्लाउड क्रेडेंशियल उजागर करती हैं। कुबेरनेट्स फाइलें एक समझौता किए गए वर्कलोड को व्यापक क्लस्टर दृश्यता में बदल सकती हैं। शेल इतिहास एक-बार के एडमिन कमांड, एड-हॉक टोकन, आंतरिक होस्टनाम, और डेटाबेस एक्सेस पैटर्न प्रकट कर सकता है। गिट क्रेडेंशियल निजी रिपॉजिटरी एक्सेस या रिलीज़ प्रक्रियाओं को खोल सकते हैं। दूसरे शब्दों में, यह मैलवेयर किसी एक एप्लिकेशन से एक API कुंजी चुराने के लिए नहीं बनाया गया था। इसे एक आधुनिक इंजीनियरिंग वर्कस्टेशन या रनर के सामान्य-उद्देश्यीय ट्रस्ट स्टोर पर धावा बोलने के लिए बनाया गया था। (गिटहब)
एक्सफिल्ट्रेशन के विवरण भी परिचालनात्मक रूप से उपयोगी हैं। रिपोर्ट में कहा गया है कि पेलोड ने हाइब्रिड एन्क्रिप्शन का उपयोग किया और आर्काइव को POST के माध्यम से भेजा। https://models.litellm.cloud/ के साथ एक्स-फ़ाइलनाम: tpcp.tar.gz हेडर। यह तेज़ी से आगे बढ़ने वाले पैकेज समझौते के लिए IOC सेट को असामान्य रूप से ठोस बनाता है। भले ही DNS लॉग्स अधूरे हों, प्रॉक्सी लॉग्स, एग्जिट गेटवे, या आउटबाउंड TLS मेटाडेटा फिर भी यह पुष्टि करने में मदद कर सकते हैं कि डोमेन से संपर्क किया गया था या नहीं। हेडर का नाम हर कंट्रोल प्लेन में दिखाई दे या न दे, लेकिन जहाँ भी पूर्ण HTTP मेटाडेटा संरक्षित रहता है, वहाँ यह मूल्यवान होता है। (गिटहब)
FutureSearch के एक सार्वजनिक विश्लेषण में यह भी बताया गया कि जब कुबेरनेट्स सर्विस अकाउंट की सामग्री उपलब्ध थी, तब मैलवेयर ने पार्श्व गति और स्थायित्व की कोशिश की, और खोजकर्ताओं ने इस समस्या को पहली बार इसलिए देखा क्योंकि .पथ व्यवहार ने एक फोर्क-बॉम्ब-जैसा पार्श्व प्रभाव उत्पन्न किया। ये विवरण रोचक हैं और महत्वपूर्ण साबित हो सकते हैं, लेकिन वर्तमान में ये उपरोक्त मुख्य तथ्यों की तुलना में अधिक सीमित स्रोत आधार पर निर्भर करते हैं। रक्षकों को इनके बारे में पता होना चाहिए, लेकिन उन्हें "प्रोजेक्ट इश्यूज़ और पाइथन डॉक्स द्वारा पुष्टि किए गए" को "तीसरे पक्ष के विश्लेषण में रिपोर्ट किए गए और जांचने योग्य" से अलग करना चाहिए। यह अंतर तुच्छता नहीं है। जब तथ्य अभी भी स्पष्ट हो रहे हों, तो यह घटना प्रतिक्रिया को ईमानदार बनाए रखता है।भविष्य खोज)
अधिकांश टीमों के लिए, सबसे सुरक्षित परिचालन मान्यता यह है: किसी भी ऐसे क्रेडेंशियल को जो उस होस्ट पर पर्यावरण चर या मानक इंजीनियरिंग क्रेडेंशियल स्थानों से पहुँचा जा सकता था, जहाँ दुर्भावनापूर्ण संस्करण स्थापित थे, उजागर हो चुका हो सकता है। यह पहले से ही सुधार कार्यों को आगे बढ़ाने के लिए पर्याप्त है, भले ही स्थायीता, पार्श्वीय गति, या बाद की तैयारी संबंधी हर अनसुलझी जानकारी का समाधान न हुआ हो।गिटहब)
एआई इंफ्रास्ट्रक्चर क्यों एक विशेष रूप से आकर्षक शिकार है
एक सामान्य वेब स्टैक में पैकेज समझौता गंभीर होगा। AI स्टैक में यह और भी खराब हो जाता है क्योंकि AI गेटवे होस्ट अक्सर पारंपरिक एप्लिकेशन परतों की तुलना में अधिक प्रकार के भरोसे जमा करते हैं। LiteLLM के अपने दस्तावेज़ दिखाते हैं कि क्यों। गेटवे मॉडल-प्रदाता एक्सेस, राउटिंग, बजट, प्रामाणिकता, लॉगिंग, गार्डरेल और MCP-शैली के इंटीग्रेशन को केंद्रीकृत करता है। इसका मतलब है कि एक प्रक्रिया कई विक्रेताओं की कुंजियाँ, ट्रैफ़िक की दृश्यता और उपयोगकर्ताओं या एजेंटों की ओर से बाहरी टूल्स या आंतरिक सेवाओं को कॉल करने की अनुमति रख सकती है। (पाइपाई)
एआई टीमें भी क्लासिक सेवा टीमों की तुलना में एक अलग जोखिम संरचना के साथ काम करती हैं। एक वेब एप्लिकेशन में अक्सर एक मुख्य क्लाउड खाता, एक डेटाबेस, और एक पूर्वानुमेय अनुरोध सतह होती है। एक एआई प्लेटफ़ॉर्म टीम के पास OpenAI और Anthropic कीज़ एक साथ, एंटरप्राइज राउटिंग के लिए Azure या Vertex क्रेडेंशियल, कैशिंग और लॉगिंग के लिए Redis और Postgres कनेक्शन, ऑब्ज़र्वबिलिटी के लिए कॉलबैक इंटीग्रेशन, IDE प्लगइन ट्रैफ़िक, MCP सर्वर, और बजट और टीम प्रबंधन के लिए आंतरिक एडमिन API हो सकते हैं। इसलिए, गेटवे होस्ट का समझौता न केवल क्रेडेंशियल, बल्कि एआई सिस्टम की परिचालन टोपोलॉजी को भी उजागर कर सकता है। LiteLLM के सार्वजनिक दस्तावेज़ों में स्पष्ट रूप से इन कई फ़ंक्शनों का उल्लेख है। (पाइपाई)
सीक्रेट्स को रोटेट करने के बाद भी यह मायने रखता है। एक बार हमलावर पर्यावरण देख लेता है, तो वह नाम, प्रदाताओं, पथों, बजट सीमाओं, डिप्लॉयमेंट कन्वेंशन्स, और कभी-कभी आपके आंतरिक कंट्रोल प्लेन का आकार भी जान लेता है। क्रेडेंशियल रोटेशन पहचान को ठीक करता है, लेकिन यह हमलावर के ज्ञान को मिटा नहीं पाता। इसीलिए घटना के बाद के कार्य में केवल कुंजी प्रतिस्थापन ही नहीं, बल्कि पर्यावरण की पुनःप्रमाणीकरण भी शामिल होना चाहिए। क्या पुराने कॉलबैक्स अभी भी घूमाए गए क्रेडेंशियल्स स्वीकार कर रहे थे? क्या निष्क्रिय एडमिन सतहें पहुँच योग्य हैं? क्या गेटवे MCP या पासथ्रू एंडपॉइंट्स को इच्छित से अधिक व्यापक रूप से उजागर कर रहा है? ये वास्तुशिल्पीय प्रश्न हैं, पैकेज-प्रबंधन के प्रश्न नहीं। घटना ने इन्हें बस उजागर कर दिया। (पाइपाई)
यह वह जगह भी है जहाँ पोस्ट-रेमेडिएशन वेरिफिकेशन टूल्स, अधिक सिद्धांत से ज़्यादा उपयोगी हो जाते हैं। सीक्रेट रोटेशन और कॉन्फिग क्लीनअप के बाद, टीमों को अभी भी यह टेस्ट करने की ज़रूरत होती है कि चल रहे सिस्टम पर वास्तव में क्या एक्सपोज़्ड है: वेब सरफेस, एपीआई व्यवहार, कॉलबैक फ्लो, ऑथेंटिकेशन की गलतियाँ, पुराने एंडपॉइंट, और इमरजेंसी चेंज विंडो के दौरान पेश की गई पॉलिसी गैप्स। यह उस तरह का वर्कफ़्लो है जहाँ एक ऑटोमेटेड एडवर्सरियल वेरिफिकेशन प्लेटफ़ॉर्म, इंसिडेंट रिस्पांस के विकल्प के बजाय एक वेरिफिकेशन लेयर के रूप में उपयोगी हो सकता है। Penligent की सार्वजनिक सामग्री और Hacking Labs की सामग्री AI सुरक्षा परीक्षण, निष्पादन सीमाओं, और आधुनिक एजेंट और गेटवे तैनाती में निरंतर सत्यापन पर केंद्रित है, जो ठीक उसी प्रकार का अनुवर्ती कार्य है जिसकी इस तरह की घटना के बाद कई टीमों को आवश्यकता होगी। (पेनलिजेंट)
महत्वपूर्ण बात उत्पाद का नाम नहीं है। महत्वपूर्ण बात कार्य की श्रेणी है: गेटवे समझौते के बाद, संगठन को यह प्रमाण चाहिए कि वातावरण अब सुरक्षित है, न कि केवल यह आशा कि खराब पैकेज चला गया है। प्रमाण खुले रास्तों का पुनः परीक्षण करने, यह सत्यापित करने कि असुरक्षित क्रियाएं अवरुद्ध हैं, और यह एक स्वच्छ साक्ष्य रिकॉर्ड तैयार करने से मिलता है कि क्या बदला और क्या अब दोबारा नहीं हो रहा।पेनलिजेंट)
जोखिम कौन उठाए
यदि आपकी टीम ने 24 मार्च, 2026 को LiteLLM इंस्टॉल या अपग्रेड किया था, तो एक्सपोजर एक स्पष्ट चिंता का विषय है। लेकिन कई वास्तविक वातावरण अप्रत्यक्ष रूप से उसी स्थिति तक पहुँच जाते हैं। FutureSearch विश्लेषण कहता है कि उन्हें यह पैकेज Cursor के भीतर एक MCP प्लगइन द्वारा खींची गई ट्रांज़िटिव डिपेंडेंसी के रूप में मिला, और इश्यू थ्रेड्स दिखाते हैं कि खोज का मार्ग एक अलग पैकेज इंस्टॉलेशन फ्लो से होकर गुज़रा था। इसका मतलब है कि आपको अपनी खोज केवल उन रिपॉजिटरी तक सीमित नहीं रखनी चाहिए जहाँ इंजीनियरों ने जानबूझकर जोड़ा था। लिटेलएम को आवश्यकताएँ.txtयह एक IDE वर्कफ़्लो, टूल इंस्टॉलेशन पथ, अस्थायी एजेंट वातावरण, या पारगमन निर्भरता श्रृंखला के माध्यम से आया हो सकता है। (भविष्य खोज)
तीन समूहों को पहले आगे बढ़ना चाहिए। पहला वह कोई भी टीम है जो स्टार्टअप के दौरान डायनामिक डिपेंडेंसी इंस्टॉलेशन की अनुमति देती है, के दौरान यूवी रन, या अस्थायी बिल्ड और टेस्ट जॉब्स के अंदर। दूसरा है कोई भी टीम जो साझा इंफ्रास्ट्रक्चर पर प्रॉक्सी या गेटवे मोड में LiteLLM का उपयोग करती है। तीसरा है कोई भी मेंटेनर या CI मालिक जिसकी पाइपलाइनों में लंबे समय तक चलने वाले रिलीज सीक्रेट्स या क्लाउड डिप्लॉयमेंट क्रेडेंशियल्स होते हैं। ये वे वातावरण हैं जिनमें संभावना और परिणाम का सर्वोत्तम संयोजन होता है। (हैकर न्यूज़)
आपको यह भी मान लेना चाहिए कि "हमने बाद में इसे अनइंस्टॉल कर दिया" कोई विश्वसनीय सीमा नहीं है। सवाल यह है कि क्या वह दुर्भावनापूर्ण पैकेज कभी साइट डायरेक्टरी में पहुँचा और क्या बाद में उस वातावरण में इंटरप्रेटर कभी शुरू हुआ। 1.82.8 मामले में, सार्वजनिक समस्या एक का वर्णन करती है .पथ लॉन्चर को ठीक इसलिए चुना गया है क्योंकि यह हमलावर को एक व्यापक स्टार्टअप ट्रिगर प्रदान करता है। एक बार जब वह घटना घटित हो जाती है, तो बाद में अनइंस्टॉल करने से पहले से हुई किसी भी क्रेडेंशियल के उजागर होने को वापस नहीं लिया जा सकता।गिटहब)
अंत में, कैश किए गए पैकेजों वाले वातावरणों को कई टीमों की तुलना में अधिक जांच की आवश्यकता है। तीसरे पक्ष के खोजकर्ताओं ने स्पष्ट रूप से जांच करने की सिफारिश की। यूवी कैश और वर्चुअल वातावरण, और pip के स्वयं के secure-install मार्गदर्शन नोट्स बताते हैं कि स्थानीय रूप से निर्मित wheel कैश का उपयोग हैश-चेकिंग मोड में भी किया जाता है। कैश उपयोगी और सामान्य हैं, लेकिन इसका मतलब यह भी है कि पैकेज की मौजूदगी इंस्टॉलेशन के क्षण से भी अधिक समय तक बनी रह सकती है। एक टीम जिसने "कभी भी खराब संस्करण डिप्लॉय नहीं किया" उसके डेवलपर सिस्टम या रनर्स पर अभी भी दूषित कैश हो सकते हैं यदि पैकेज संबंधित विंडो के दौरान रिज़ॉल्व किया गया था।भविष्य खोज)
पहले घंटे में क्या करें
पहला प्रतिक्रिया लक्ष्य अतिरिक्त जोखिम को रोकना है, जिज्ञासा को संतुष्ट करना नहीं। यदि कोई संभावना है कि किसी होस्ट, रनर, या इमेज ने 1.82.7 या 1.82.8 खींचा है, तो उस वातावरण को सामान्य रिलीज़ और क्रेडेंशियल प्रवाह से अलग करें। स्वचालित प्रकाशन को रोकें। प्रभावित जॉब्स चलाने वाले रनर्स को अक्षम या अलग करें। आक्रामक सफ़ाई से पहले लॉग और फ़ाइल सिस्टम की स्थिति का स्नैपशॉट लें, लेकिन संवेदनशील गंतव्यों तक पहुँचने वाले नेटवर्क पथ पर समझौता किए गए वातावरण को न रखें। यह सलाह सार्वजनिक रूप से रिपोर्ट किए गए एक्सफ़िल्ट्रेशन व्यवहार और मेंटेनर के उस बयान से सीधे मिलती है कि रिलीज़ क्रेडेंशियल्स इस श्रृंखला में शामिल थे। (गिटहब)
दूसरा लक्ष्य यह है कि आप जांच करते समय पेलोड को फिर से ट्रिगर होने से रोकें। 1.82.8 के साथ, पाइथन का सामान्य उपयोग जोखिम मॉडल का हिस्सा है। पाइथन दस्तावेज़ कहते हैं कि साइट इनिशियलाइज़ेशन के दौरान मॉड्यूल स्वतः आयात हो जाता है जब तक कि -एस का उपयोग किया जाता है, और कि .पथ प्रत्येक स्टार्टअप पर निष्पादन योग्य पंक्तियाँ चलती हैं। इससे पाइथन -S प्रदूषित वातावरण के लिए एक मूल्यवान प्रथम-स्तरीय निरीक्षण उपकरण। यह मशीन को सुरक्षित नहीं बनाता है। यह केवल इस संभावना को कम करता है कि आपका निरीक्षण चरण स्वयं ही निष्पादित हो जाएगा। .पथ सामान्य स्टार्टअप प्रक्रिया से फ़ाइल करें। (पाइथन दस्तावेज़ीकरण)
तीसरा लक्ष्य क्रेडेंशियल रोटेशन को सही क्रम में प्राथमिकता देना है। ऐसी किसी भी चीज़ से शुरू करें जो हमलावर को कोड प्रकाशित करने, कोड तैनात करने, या क्षैतिज रूप से आगे बढ़ने की अनुमति दे सकती है: PyPI पब्लिशिंग टोकन, GitHub टोकन, क्लाउड IAM कुंजी, kubeconfig और क्लस्टर क्रेडेंशियल, और विशेषाधिकार प्राप्त इंफ्रास्ट्रक्चर एक्सेस के लिए उपयोग की जाने वाली SSH सामग्री। उसके बाद, मॉडल-प्रोवाइडर कुंजियों और एप्लिकेशन सीक्रेट्स को रोटेट करें। सार्वजनिक मुद्दे से प्राप्त पेलोड लक्ष्य सूची इतनी व्यापक है कि यह तय करने की कोशिश करना कि कौन सा एकल सीक्रेट "वास्तव में मायने रखता था", आमतौर पर समय की बर्बादी है। अनुमान के आधार पर नहीं, बल्कि विशेषाधिकार और प्रभाव की सीमा के आधार पर प्राथमिकता दें। (गिटहब)
एक संक्षिप्त, रूढ़िवादी ट्राइएज अनुक्रम इस प्रकार दिखता है:
- उन होस्ट्स और रनर्स की पहचान करें जिन्होंने 1.82.7 या 1.82.8 इंस्टॉल किया हो सकता है।
- रिलीज़ स्वचालन को रोकें और संदिग्ध बिल्ड एजेंटों को अलग करें।
- जहाँ संभव हो, सामान्य पाइथन स्टार्टअप के बिना फ़ाइलसिस्टम्स और कैश की जाँच करें।
- दुष्ट कलाकृतियों को हटाएँ और कैश साफ़ करें।
- सबसे पहले उच्च-अधिकार वाले क्रेडेंशियल्स को घुमाएँ।
- IOC डोमेन से बाहर निकलने और संदिग्ध डाउनस्ट्रीम पहुँच के लिए लॉग्स की समीक्षा करें।
- निर्भरताओं के सत्यापित स्रोत से स्वच्छ आर्टिफैक्ट्स को पुनर्निर्मित करें।
- सामान्य वितरण फिर से शुरू करने से पहले मरम्मत किए गए वातावरण का पुनः परीक्षण करें।
उस अनुक्रम का प्रत्येक चरण सार्वजनिक तथ्यों से मेल खाता है: स्टार्टअप-प्रेरित निष्पादन, प्रमाणपत्र चोरी, CI-संबंधित रिलीज़-गुप्त प्रकटीकरण, और PyPI से पैकेज का त्वरित निष्कासन।गिटहब)
पुनः-ट्रिगर किए बिना सुरक्षित ट्राइएज .पथ फ़ाइल
संदिग्ध होस्ट पर सबसे सुरक्षित प्रारंभिक कदम "बस पाइथन चलाकर देखो" के बजाय फ़ाइल सिस्टम की जाँच करना है। नीचे दिया गया कोड जानबूझकर उबाऊ है। यही बात है।
# साइट कस्टमाइज़ेशन को इम्पोर्ट किए बिना पाइथन साइट पथ प्रिंट करें
python -S - </dev/null
# इंस्टॉल की गई फ़ाइलों और कैश में IOC डोमेन खोजें
grep -R "models\.litellm\.cloud" \
~/.cache ~/.local /usr/local/lib /opt /venv /srv 2>/dev/null
कारण पाइथन -S यहाँ जो दिख रहा है वह अंधविश्वास नहीं है। पाइथन की डॉक्स कहती हैं कि साइट शुरुआतीकरण के दौरान स्वचालित रूप से आयात किया जाता है जब तक कि -एस का उपयोग किया जाता है, और कि .पथ कार्यकारी पंक्तियाँ द्वारा संसाधित की जाती हैं साइटयदि आप एक होस्ट की जाँच कर रहे हैं जहाँ लिटेलएम_इनिट.पीथ मौजूद हो सकता है, दबाते हुए साइट आपकी पहली नज़र में एक समझदारी भरी रक्षात्मक आदत है। (पाइथन दस्तावेज़ीकरण)
यदि आपको वर्चुअल एनवायरनमेंट को सीधे निरीक्षण करना हो, तो साइट-पैकेजेस डायरेक्टरी में जाएँ, इम्पोर्ट टारगेट के रूप में नहीं। खोजें लिटेलएम_इनिट.पीथ, इसकी सामग्री को एक फ़ाइल के रूप में निरीक्षण करें, और इंस्टॉल की गई LiteLLM फ़ाइलों की तुलना एक ज्ञात-सही आर्टिफैक्ट स्रोत से करें। सार्वजनिक घटना पाठ कहता है कि पहली पंक्ति की .पथ फ़ाइल ने एक base64-ओब्फुस्केटेड पाइथन पेलोड को via के माध्यम से लॉन्च किया। सबप्रोसेस.पोपन, इसलिए फ़ाइल को सादा-पाठ में पढ़ना आमतौर पर यह पुष्टि करने के लिए पर्याप्त होता है कि वातावरण प्रभावित है। (गिटहब)
# उदाहरण पथ पैटर्न, अपने वातावरण के अनुसार समायोजित करें
SITEPKG="/path/to/venv/lib/python3.12/site-packages"
ls -la "$SITEPKG" | grep -E 'litellm|\.pth'
sed -n '1,5p' "$SITEPKG/litellm_init.pth" 2>/dev/null
find "$SITEPKG/litellm" -type f | sort | sed -n '1,40p'
CI और कंटेनराइज़्ड वातावरण के लिए भी यही सिद्धांत लागू होता है। अपने आप को लाइव फ़ाइल सिस्टम तक सीमित न रखें। बिल्ड वर्कस्पेस, डिपेंडेंसी कैश और, यदि प्रासंगिक हो, इमेज लेयर्स या आर्टिफैक्ट स्टोरेज की जाँच करें। एक पैकेज जिसे बिल्ड के दौरान इंस्टॉल किया गया था लेकिन अंतिम रनटाइम कंटेनर में मौजूद नहीं था, फिर भी बिल्ड चरण के दौरान सीक्रेट्स उजागर कर सकता है। यह अंतर इस घटना में कई रनटाइम-केवल समझौतों की तुलना में अधिक मायने रखता है क्योंकि रिपोर्ट किया गया पेलोड डेवलपर और पाइपलाइन सीक्रेट्स को लक्षित करने के लिए बनाया गया था। (गिटहब)
प्रभावित वातावरणों और कैशों की खोज
अधिकांश टीमें यह कम आंकती हैं कि एक विषाक्त पैकेज कितनी जगहों पर उतर सकता है। कम से कम चार सामान्य मार्ग हैं: स्थानीय वर्चुअल वातावरण, वैश्विक साइट-पैकेज, पाइप कैश, और वैकल्पिक टूल कैश जैसे यूवी. सार्वजनिक FutureSearch विश्लेषण स्पष्ट रूप से जांचने की सिफारिश करता है यूवी 24 मार्च के बाद इंस्टॉलेशनों में कैश और वर्चुअल वातावरण, और pip की secure-install दस्तावेज़ीकरण बताती है कि कैशिंग वास्तविक इंस्टॉलेशन व्यवहार का हिस्सा बनी रहती है, भले ही सख्त अखंडता नियंत्रण लागू किए गए हों। इसलिए एक गंभीर खोज में "पैकेज कहाँ चला" और "पैकेज कहाँ संग्रहीत था" दोनों को शामिल करना आवश्यक है।भविष्य खोज)
वर्कस्टेशनों और रनर्स पर एक व्यावहारिक कैश हंट इस तरह दिखता है:
# pip मेटाडेटा और कैश
pip show litellm 2>/dev/null || true
pip cache dir 2>/dev/null || true
pip cache purge 2>/dev/null || true
# uv कैश उदाहरण
find ~/.cache/uv -iname '*litellm*' 2>/dev/null
find ~/.cache/uv -name 'litellm_init.pth' 2>/dev/null
# वर्चुअलएनवी और लोकल प्रोजेक्ट सर्च
find ~ -type d -path '*/site-packages' 2>/dev/null | while read d; do
test -f "$d/litellm_init.pth" && echo "FOUND $d/litellm_init.pth"
done
कंटेनर इमेज के लिए, अंतिम इमेज और उसे बनाने वाली बिल्ड सिस्टम दोनों की जाँच करें। एक मल्टी-स्टेज Docker बिल्ड अंतिम रनटाइम इमेज से पैकेज को छिपा सकता है, फिर भी निर्भरता समाधान के दौरान बिल्ड होस्ट या बिल्ड रनर को उजागर कर सकता है। इसलिए पहली प्रतिक्रिया को केवल एप्लिकेशन पॉड्स ही नहीं, बल्कि रनर्स की भी जाँच करनी चाहिए और रिलीज ऑटोमेशन को रोक देना चाहिए। ट्राइवी घटना, जिसे LiteLLM के मेंटेनर ने स्पष्ट रूप से अपस्ट्रीम समझौते के मार्ग के रूप में जोड़ा है, यह एक मजबूत अनुस्मारक है कि पाइपलाइन वातावरण स्वयं उच्च-मूल्य की संपत्तियां हैं, न कि केवल अस्थायी ढांचा। (हैकर न्यूज़)
एक बार जब आप पैकेज की मौजूदगी की पुष्टि कर लें, तो उस मशीन पर पहुँच योग्य सभी सीक्रेट्स की सूची बनाएँ, न कि केवल उन सीक्रेट्स की जो एप्लिकेशन रिपॉजिटरी से संबंधित थे। डेवलपर मशीन पर, इसमें SSH सामग्री, क्लाउड CLI स्थिति, Git क्रेडेंशियल स्टोर्स, शेल इतिहास, और डेटाबेस हेल्पर शामिल हैं। रनर पर, इसमें रिलीज सीक्रेट्स, क्लाउड डिप्लॉयमेंट पहचान, आर्टिफैक्ट रजिस्ट्री, और जॉब समय पर लोड किए गए सीक्रेट्स शामिल हैं। एक साझा AI गेटवे पर, इसमें मॉडल-प्रोवाइडर कुंजियाँ, एडमिन कुंजियाँ, लॉगिंग एंडपॉइंट, और MCP या टूल-इंटीग्रेशन क्रेडेंशियल शामिल हैं। ये श्रेणियाँ काल्पनिक नहीं हैं। ये सार्वजनिक रूप से रिपोर्ट की गई लक्ष्य सूची के अनुरूप हैं। (गिटहब)
पैकेज हटाएँ, लेकिन यहीं न रुकें।
दुष्ट पैकेज को हटाना आवश्यक है, लेकिन यह अपर्याप्त है। यह ट्रिगर को हटा देता है, लेकिन यह सबसे महत्वपूर्ण प्रश्न का उत्तर नहीं देता: हटाने से पहले मशीन से क्या बाहर गया था। सार्वजनिक समस्या विवरण में कहा गया है कि पेलोड ने मौन उपप्रक्रिया निष्पादन का उपयोग किया, संवेदनशील फ़ाइलें और पर्यावरण चर एकत्र किए, आउटपुट को एन्क्रिप्ट किया, और उसे बाहर भेज दिया। यदि दुष्ट कोड कम से कम एक बार चला था, तो मान लें कि उस वातावरण से पहुँच योग्य रहस्य पहले ही उजागर हो चुके हो सकते हैं।गिटहब)
इसलिए सफ़ाई एक सोची-समझी क्रमबद्धता में होनी चाहिए। पहले, दुर्भावनापूर्ण पैकेज को हटाएँ और उन कैश को साफ़ करें जो इसे गलती से फिर से इंस्टॉल कर सकते हैं। दूसरा, उजागर हुए क्रेडेंशियल्स को बदलें। तीसरा, उन क्रेडेंशियल्स से जुड़े सिस्टम के लॉग्स की संभावित उजागर होने के समय के बाद की संदिग्ध गतिविधियों के लिए ऑडिट करें। चौथा, एक स्वच्छ निर्भरता स्रोत से आर्टिफैक्ट्स को फिर से बनाएं। पांचवां, मरम्मत किए गए वातावरण का फिर से परीक्षण करें। टीमें अक्सर उस क्रम को उलट देती हैं और "पैकेज को बाहर निकालने" पर ध्यान केंद्रित करती हैं, जैसे कि पैकेज हटाने से घटना समाप्त हो जाती है। ऐसा नहीं है। पैकेज हटाने से हमलावर का एक पैर जमाना समाप्त होता है। यह इस बारे में कुछ नहीं बताता कि चोरी हुए क्रेडेंशियल आगे क्या कर सकते हैं। (गिटहब)
Python वर्चुअल एनवायरनमेंट के लिए एक सफाई उदाहरण नीचे दिया गया है:
# एक अलग शेल में, सबूत इकट्ठा करने के बाद
pip uninstall -y litellm
# संदिग्ध लॉन्चर हटाएँ यदि यह अभी भी मौजूद है
find /path/to/venv/lib -name 'litellm_init.pth' -delete 2>/dev/null
# कैश किए गए आर्टिफैक्ट्स के पुन: उपयोग से बचने के लिए कैश साफ़ करें
pip cache purge 2>/dev/null || true
rm -rf ~/.cache/uv 2>/dev/null || true
"पैकेज अब स्थापित नहीं है" को "वातावरण अब भरोसेमंद है" के साथ भ्रमित न करें। यदि सिस्टम रनर था, तो उसे पुनर्निर्माण करें या बदलें। यदि यह विशेषाधिकार प्राप्त इन्फ्रास्ट्रक्चर एक्सेस वाला डेवलपर लैपटॉप था, तो उन क्रेडेंशियल्स को रोटेट करें और हाल की गतिविधि की समीक्षा करें। यदि यह साझा AI गेटवे था, तो न केवल यह सत्यापित करें कि गेटवे बाइनरी स्वच्छ है, बल्कि यह भी कि पुरानी प्रोवाइडर कुंजियाँ, एडमिन कुंजियाँ और कॉलबैक पाथ अब काम नहीं करते। गेटवे घटनाओं के लिए केवल पैकेज-स्तर की स्वच्छता नहीं, बल्कि इन्फ्रास्ट्रक्चर-स्तर की स्वच्छता भी आवश्यक है। (गिटहब)
सही क्रम में रहस्य घुमाएँ
सभी सीक्रेट्स का मूल्य समान नहीं होता, और सभी को समान प्रतिक्रिया समय-सीमा की आवश्यकता नहीं होती। घटना की सार्वजनिक लक्ष्य सूची दृढ़ता से एक ऐसा रोटेशन क्रम सुझाती है जो रिलीज़ और इन्फ्रास्ट्रक्चर नियंत्रण से शुरू होता है, फिर प्लेटफ़ॉर्म एक्सेस की ओर बढ़ता है, और फिर एप्लिकेशन-विशिष्ट क्रेडेंशियल्स की ओर। रिलीज़ और CI टोकन को सबसे पहले रखा जाना चाहिए क्योंकि वे एक हमलावर को कोड को पुनः प्रकाशित करने या डिलीवरी को बदलने की अनुमति दे सकते हैं। क्लाउड IAM और क्लस्टर एक्सेस को इसके बाद रखा जाना चाहिए क्योंकि वे घटना को मूल होस्ट से परे तक फैला सकते हैं। प्रशासन या प्रोडक्शन डिप्लॉयमेंट के लिए उपयोग की जाने वाली SSH सामग्री को भी उनके साथ ही घुमाया जाना चाहिए। तभी टीमों को प्रदाता API कुंजियों, ऐप सीक्रेट्स और कम-अधिकार वाले टोकन की ओर बढ़ना चाहिए। (हैकर न्यूज़)
AI टीमों के लिए, मॉडल-प्रदाता क्रेडेंशियल्स के साथ विशेष सावधानी बरतना चाहिए। OpenAI या Anthropic की कुंजी को घुमाना पर्याप्त नहीं है यदि आंतरिक प्रॉक्सी, बजट सेवाएँ, या उपयोग लॉगर्स अभी भी मूल गुप्त क्रेडेंशियल से व्युत्पन्न पुरानी द्वितीयक क्रेडेंशियल्स पर भरोसा करते हैं। इसी तरह, Azure या Vertex एक्सेस को घुमाने के लिए केवल एक-लाइन एनवायरनमेंट वेरिएबल स्वैप के बजाय सर्विस प्रिंसिपल्स, वर्कलोड आईडेंटिटीज़, या प्रॉक्सी कॉन्फ़िगरेशन में बदलाव की आवश्यकता हो सकती है। यही एक कारण है कि सप्लाई चेन समझौते के बाद AI स्टैक को साफ़ करना एक सरल सिंगल-वेंडर इंटीग्रेशन की तुलना में अधिक कठिन होता है। दिखाई देने वाला क्रेडेंशियल अक्सर एक बड़े परिचालन ग्राफ़ में सिर्फ एक परत होता है। (पाइपाई)
शेल इतिहास और स्थानीय कॉन्फ़िगरेशन फ़ाइलों को भी सामान्यतः मिलने वाली सम्मान से अधिक सम्मान मिलना चाहिए। सार्वजनिक लक्ष्य सूची में शेल इतिहास, Git कॉन्फ़िगरेशन, डेटाबेस हेल्पर और स्थानीय क्रेडेंशियल स्टोर शामिल हैं। ये आर्टिफैक्ट्स सीधे क्रेडेंशियल लीक कर सकते हैं, लेकिन ये आकस्मिक रूप से विशेषाधिकार प्राप्त परिचालन जानकारी भी प्रकट कर सकते हैं: आंतरिक होस्टनाम, एडमिन स्क्रिप्ट्स, बैकअप स्थान, रिलीज़ नामकरण परंपराएँ, और समस्या निवारण के दौरान पेस्ट किए गए एक-बार के टोकन। भले ही आपको चोरी की गई कुंजी का उपयोग करके सफल लॉगिन का कोई सबूत न मिले, फिर भी आपको यह मान लेना चाहिए कि हमलावर ने भविष्य में फिशिंग या पार्श्वीय गतिविधि को आसान बनाने के लिए पर्याप्त जानकारी हासिल कर ली है। (गिटहब)
सफ़ाई के बाद पर्यावरण को मान्य करें
गुप्त रोटेशन के बाद, अगली गलती यह मान लेना है कि आपका काम पूरा हो गया है क्योंकि कोई स्पष्ट संकेत नहीं बचे हैं। व्यवहार में, आपातकालीन सफाई अपने स्वयं के विफलता मोड पेश करती है: आंशिक रोटेशन, भूली हुई साइडकार कॉन्फ़िगरेशन, पुरानी कंटेनर इमेज, अनदेखे मिरर, और टूल्स के बीच अदृश्य ट्रस्ट संबंध। Aqua की आधिकारिक Trivy एडवाइजरी यहाँ शिक्षाप्रद है। यह स्पष्ट रूप से कहती है कि 19 मार्च की घटना पहले के हमले का ही एक सिलसिला थी और क्रेडेंशियल रोटेशन एटॉमिक नहीं था, जिससे हमलावर को एक्सेस बनाए रखने का मौका मिला। यह सबक सीधे LiteLLM पर भी लागू होता है। एक जल्दबाज़ी में किया गया आंशिक समाधान समापन के समान नहीं होता। (गिटहब)
प्रमाणीकरण को ठोस हाँ-या-नहीं वाले प्रश्नों का उत्तर देना चाहिए। क्या पुराने रिलीज़ क्रेडेंशियल निष्क्रिय हो गए हैं? क्या पुराने प्रदाता कुंजी हर जगह, प्रॉक्सी और साइडकार सहित, विफल हो जाती हैं? क्या बिल्ड एजेंट्स को स्वच्छ बेस इमेज से पुनः निर्मित किया जाता है? क्या पैकेज स्रोत अब आंतरिक और पिन किया गया है? क्या आउटबाउंड नियंत्रण IOC डोमेन और बिल्ड या गेटवे नेटवर्क से समान अप्रत्याशित निकास को रोकते हैं? क्या आप यह साबित कर सकते हैं कि ठीक किए गए वातावरण में अब पहले से पहुँच योग्य वेब, एपीआई, या टूल सतहें असुरक्षित तरीकों से उजागर नहीं होती हैं? ये वे प्रश्न हैं जो पैकेज के चले जाने के बाद मायने रखते हैं। (गिटहब)
यह दूसरी जगह है जहाँ घटना-पश्चात सत्यापन टूलिंग मायने रखती है। एक बार क्रेडेंशियल्स रोटेट हो जाने और पैकेज फिर से बन जाने के बाद भी, टीमों को लाइव वातावरण के बाहरी व्यवहार को सत्यापित करने की आवश्यकता होती है। इसका आमतौर पर मतलब होता है पहुँच योग्य संपत्तियों को स्कैन करना, प्राधिकरण सीमाओं को सत्यापित करना, महत्वपूर्ण अनुरोधों को फिर से चलाना, यह जाँचना कि पुराने टोकन वास्तव में असफल होते हैं, और आंतरिक हितधारकों के लिए सबूत इकट्ठा करना। Penligent के सार्वजनिक दस्तावेज़ और शोध सामग्री यहाँ इसलिए प्रासंगिक हैं क्योंकि यह घटना "Penligent के बारे में" नहीं है, बल्कि इसलिए कि सफ़ाई के बाद का कार्य वेब, एपीआई, और टूल सीमाओं वाली एक एआई-संबंधित प्रणाली का मौलिक रूप से प्रतिपक्षी सत्यापन है। (पेनलिजेंट)
यदि आप उस पैराग्राफ़ से उत्पाद का नाम हटा दें, तो मार्गदर्शन अभी भी लागू रहता है। आपूर्ति श्रृंखला की सफाई के लिए सत्यापन आवश्यक है। सत्यापन के लिए साक्ष्य चाहिए। साक्ष्य आमतौर पर स्वचालन और सावधानीपूर्वक समीक्षा से प्राप्त होते हैं, न कि एक ही दिलासा देने वाले स्क्रीनशॉट से जो दिखाता है कि खराब पैकेज अब आयात नहीं हो रहा है।पेनलिजेंट)
होस्ट, नेटवर्क, सीआई, और पैकेज हाइजीन के लिए डिटेक्शन आइडियाज़
होस्ट-स्तर की टेलीमेट्री से शुरू करें। सार्वजनिक समस्या आपको उपयोगी एंकर देती है: फ़ाइल का नाम लिटेलएम_इनिट.पीथ, निकासी डोमेन मॉडल्स.लिटेल्एम.क्लाउड, और साइलेंट सबप्रोसेस निष्पादन के साथ-साथ रिपोर्ट किए गए उपयोग घुमाव या व्यापक पेलोड संरचना में संबंधित टूलिंग। इसलिए एक समझदारी भरी होस्ट हंट में नए शामिल होते हैं। .पथ साइट-पैकेजेस के अंतर्गत क्रिएशन, पाइथन द्वारा स्टार्टअप के दौरान अनपेक्षित शेल यूटिलिटीज़ का स्पॉन होना, और IOC डोमेन युक्त कमांड लाइनें या फाइलें। पाइथन स्टार्टअप गतिविधि शोरगुल भरी होती है, इसलिए अस्पष्ट "पाइथन पर अलर्ट" की बजाय सटीक IOC हंटिंग बेहतर है।गिटहब)
एक सरल फ़ाइलसिस्टम और IOC स्वीप अक्सर पहले दिन में अति-अभियांत्रित डिटेक्शन नियम की तुलना में अधिक मूल्यवान होता है:
# IOC फ़ाइलों और डोमेन संदर्भों की खोज
find / -type f \( -name 'litellm_init.pth' -o -name '*.pth' \) 2>/dev/null | sed -n '1,200p'
grep -R "models\.litellm\.cloud" /etc /opt /srv /usr /var ~/.cache ~/.local 2>/dev/null
# उपयोगकर्ता-साइट निर्देशिकाओं में पाइथन स्टार्टअप फ़ाइलें मौजूद हैं या नहीं, इसकी समीक्षा करें
python -S -m site --user-site 2>/dev/null
नेटवर्क रक्षकों के लिए, आउटबाउंड कनेक्शन को मॉडल्स.लिटेल्एम.क्लाउड संदिग्ध LiteLLM एक्सपोजर के संदर्भ में इन्हें उच्च-विश्वास संकेतकों के रूप में माना जाना चाहिए। यदि आप HTTP मेटाडेटा कैप्चर करते हैं, तो POST ट्रैफ़िक और the की तलाश करें। एक्स-फ़ाइलनाम: tpcp.tar.gz इस अंक में वर्णित हेडर। यदि आप केवल DNS या TLS मेटाडेटा कैप्चर करते हैं, तो भी वहीं से शुरू करें। IOC-आधारित नेटवर्क हंटिंग शायद ही कभी पूरी कहानी बताती है, लेकिन यह यह स्थापित करने में मदद कर सकती है कि किन मशीनों की सबसे गहरी समीक्षा की आवश्यकता है। (गिटहब)
CI रक्षकों को LiteLLM घटना को आधिकारिक Trivy एडवाइजरी के दृष्टिकोण से देखना चाहिए। Aqua की GHSA बताती है कि Trivy घटना में समझौता किए गए क्रेडेंशियल्स, परिवर्तनीय GitHub Action टैग्स, और दुर्भावनापूर्ण रिलीज़ आर्टिफैक्ट्स शामिल थे। यह भी अनुशंसा करती है कि एक्शन्स को अपरिवर्तनीय SHA पर पिन किया जाए और किसी भी पाइपलाइन को जो प्रभावित घटकों को चलाया हो, समझौता किया हुआ माना जाए। LiteLLM मेंटेनर की HN पर टिप्पणी के बारे में एक पीवाईपीआई_पब्लिश CI में टोकन उस मार्गदर्शन को तुरंत Python पैकेज प्रोजेक्ट्स के लिए प्रासंगिक बना देता है। आपका रिलीज़ वर्कफ़्लो आपके अटैक सतह का हिस्सा है। आपका सिक्योरिटी स्कैनर इनवोकेशन आपके अटैक सतह का हिस्सा है। आपके "अस्थायी" रनर सीक्रेट्स आपके अटैक सतह का हिस्सा हैं। (गिटहब)
पैकेज की स्वच्छता नियंत्रण उपभोक्ता पक्ष पर भी मायने रखते हैं। pip के secure-install दस्तावेज़ में कहा गया है कि हैश-चेकिंग मोड पूर्णतः या कुछ नहीं होता है, सभी आवश्यकताओं और निर्भरताओं के लिए हैश अनिवार्य हैं, और आवश्यकताओं को पिन किया जाना चाहिए। वही दस्तावेज़ यह भी चेतावनी देते हैं कि इंडेक्स द्वारा प्रदान किए गए दूरस्थ हैश पर्याप्त नहीं हैं। --हैश-आवश्यक, क्योंकि वे हैश स्वयं दूरस्थ सर्वर से आते हैं और छेड़छाड़ किए गए इंडेक्स के खिलाफ रक्षा नहीं करते। यह अंतर महत्वपूर्ण है। केवल पिनिंग छोटा करें==1.82.8 अगर 1.82.8 स्वयं ही समझौता किया गया रिलीज़ होता तो इससे कोई मदद नहीं मिलती। स्थानीय, सत्यापित हैश और ज्ञात-सही आंतरिक आर्टिफैक्ट्स ही विश्वास मॉडल को बदलते हैं।पाइप)
एक हार्डन की गई आवश्यकताओं का खंड इस प्रकार दिखता है:
litellm==1.82.6 \
--hash=sha256:REPLACE_WITH_VERIFIED_GOOD_HASH
और इंस्टॉल पथ को उन हैशों को लागू करना चाहिए:
पाइप इंस्टॉल --require-hashes -r requirements.txt
यह पूरे इकोसिस्टम में मेंटेनर समझौते को हल नहीं करेगा, लेकिन यह एक महत्वपूर्ण तथ्य को बदल देता है: आपका वातावरण अब इंडेक्स को एक पैकेज फ़ाइल कैसी होनी चाहिए, इसके लिए एकमात्र प्राधिकरण के रूप में भरोसा करना बंद कर देता है। pip उस आवश्यकता को स्पष्ट रूप से दस्तावेज़ित करता है, और उच्च-मूल्य वाले इन्फ्रास्ट्रक्चर पैकेज का उपभोग करने वाली टीमों को इसे एक आधार रेखा के रूप में मानना चाहिए, न कि एक वैकल्पिक सुरक्षा उपाय के रूप में।पाइप)
यह सिर्फ एक खराब अपलोड नहीं, बल्कि एक रिलीज़ पाइपलाइन की समस्या क्यों लगती है
घटना की सार्वजनिक स्थिति पारंपरिक स्रोत-रिपॉजिटरी कोड समीक्षा विफलता की बजाय रिलीज़-पाथ समझौते की ओर इशारा करती है। LiteLLM टाइमलाइन मुद्दे के अनुसार, दुर्भावनापूर्ण पैकेज एक हमलावर द्वारा प्रोजेक्ट के PyPI चैनल के माध्यम से प्रकाशित किए गए थे, और मेंटेनर ने हैकर न्यूज़ पर कहा कि उजागर हुआ रहस्य CI में मौजूद एक PyPI पब्लिशिंग टोकन था। वही HN टिप्पणी इसकी उत्पत्ति को हाल की Trivy घटना से जोड़ती है, जबकि Trivy के लिए Aqua की आधिकारिक सलाह बताती है कि Trivy इकोसिस्टम की सुरक्षा भंग में दुरुपयोग किए गए क्रेडेंशियल, परिवर्तनीय एक्शन टैग, और पिछली घटना के बाद अधूरे टोकन रोटेशन शामिल थे। कुल मिलाकर, यह एक रिलीज़-सुरक्षा विफलता की संरचना है: एक हमलावर उस पथ तक पहुँच जाता है जो कोड को विश्वसनीय आर्टिफैक्ट्स में बदलता है। (गिटहब)
यह अंतर महत्वपूर्ण है क्योंकि यह सुधार के लक्ष्य को बदल देता है। यदि इस घटना से आपका सबक "कोड की और कड़ी समीक्षा करें" है, तो आपने गलत सबक सीखा है। सही प्रश्न यह है कि रिलीज़ क्रेडेंशियल्स को कैसे रखा जाता है, जारी किया जाता है, दायरे में बाँधा जाता है और रद्द किया जाता है, और अन्य अवसंरचना को उन्हें कितनी हद तक छूने की अनुमति है। PyPI Trusted Publishing दस्तावेज़ीकरण ठीक इसी कारण के लिए मौजूद है। PyPI कहता है कि पारंपरिक API टोकन लंबे समय तक चलते हैं और मैन्युअल रूप से रद्द किए जाने तक उपयोगी रहते हैं, जबकि Trusted Publishing CI द्वारा जारी OIDC पहचान का उपयोग करता है और 15 मिनट के लिए मान्य एक अल्पकालिक टोकन लौटाता है। यह कोई जादुई समाधान नहीं है, लेकिन यह चोरी की गई रिलीज़ क्रेडेंशियल्स के लिए रीप्ले विंडो को काफी हद तक संकुचित कर देता है। (पाइपाई दस्तावेज़)
PyPI का दस्तावेज़ीकरण भी उस परिचालन पैटर्न को दिखाता है जिसकी ओर टीमों को बढ़ना चाहिए। Trusted Publishing के साथ, एक GitHub Actions वर्कफ़्लो बिना लंबे समय तक चलने वाले पीवाईपीआई_टोकन बिल्कुल भी रहस्य नहीं। इसके बजाय, काम प्राप्त करता है आईडी-टोकन: लिखें, PyPI को अपनी OIDC पहचान प्रस्तुत करता है, और एक अल्पकालिक अपलोड क्रेडेंशियल प्राप्त करता है। यह ठीक उसी प्रकार का नियंत्रण है जो एक लीक हुए CI पर्यावरण चर के मूल्य को कम कर देता है। (पाइपाई दस्तावेज़)
Trusted Publishing का उपयोग करने वाली एक न्यूनतम GitHub Actions पब्लिशिंग जॉब कुछ इस तरह दिखती है:
jobs:
pypi-publish:
name: PyPI पर रिलीज़ अपलोड करें
runs-on: ubuntu-latest
environment: pypi
permissions:
id-token: write
steps:
- name: PyPI पर पैकेज वितरण प्रकाशित करें
uses: pypa/gh-action-pypi-publish@release/v1
वह उदाहरण लगभग सीधे PyPI की आधिकारिक दस्तावेज़ीकरण से लिया गया है। ध्यान दें कि क्या गायब है: कोई नहीं उपयोगकर्ता नाम, नहीं पासवर्ड, नहीं पीवाईपीआई_टोकन गुप्त, और कोई दीर्घकालिक क्रेडेंशियल बेतरतीब रूप से विरासत में लेने के लिए पड़े-पड़े न रहे। PyPI की डॉक्स में स्पष्ट रूप से कहा गया है कि आईडी-टोकन: लिखें ट्रस्टेड पब्लिशिंग के लिए अनुमति अनिवार्य है और जॉब स्तर पर अनुमति का उपयोग करने की दृढ़ता से अनुशंसा की जाती है क्योंकि यह अनावश्यक क्रेडेंशियल एक्सपोजर को कम करता है।पाइपाई दस्तावेज़)
रिलीज़-पाथ का सबक PyPI से भी आगे तक जाता है। यदि आपका बिल्ड जॉब PyPI पर प्रकाशित कर सकता है, कंटेनर इमेज पुश कर सकता है, क्लाउड इंफ्रास्ट्रक्चर पर डिप्लॉय कर सकता है, और उसी एम्बिएंट सीक्रेट सेट के साथ थर्ड-पार्टी एक्शन या स्कैनर चला सकता है, तो आपने एक बहुत ही आकर्षक लक्ष्य तैयार कर लिया है। LiteLLM घटना एक पाइथन पैकेज की कहानी है, लेकिन मूल सबक व्यापक है: पब्लिशिंग पाइपलाइनों को सामान्य CI की तरह नहीं, बल्कि अपनी स्वयं की ट्रस्ट बाउंड्रीज़ वाली विशेषाधिकार प्राप्त प्रणालियों के रूप में माना जाना चाहिए।हैकर न्यूज़)
रखरखाव करने वालों को अब क्या बदलना चाहिए
मेंटेनर्स को इस घटना को रिलीज़ प्रक्रिया की डिज़ाइन समीक्षा के रूप में लेना चाहिए। पहली बदलाव लंबी अवधि वाले पैकेज प्रकाशन रहस्यों को समाप्त करना है, जहाँ रजिस्ट्री बेहतर मॉडल का समर्थन करती है। PyPI के लिए इसका मतलब है स्टैटिक API टोकन के बजाय OIDC के माध्यम से ट्रस्टेड पब्लिशिंग। PyPI के अपने दस्तावेज़ सुरक्षा लाभ को स्पष्ट रूप से बताते हैं: पारंपरिक टोकन लंबे समय तक चलते हैं, जबकि ट्रस्टेड पब्लिशिंग स्वचालित रूप से समाप्त हो जाने वाले अल्पकालिक टोकन उत्पन्न करता है। यदि कोई हमलावर जॉब-स्कोप्ड OIDC-उत्पन्न टोकन चुरा लेता है, तो पुनःप्रयोग की खिड़की रिपॉजिटरी या रनर वातावरण से कॉपी किए गए सीक्रेट की तुलना में काफी छोटी होती है। (पाइपाई दस्तावेज़)
दूसरा परिवर्तन है रिलीज़-जॉब पृथक्करण। एक स्कैन जॉब को प्रकाशित क्रेडेंशियल्स विरासत में नहीं मिलनी चाहिए। एक दस्तावेज़ीकरण जॉब को प्रकाशित क्रेडेंशियल्स विरासत में नहीं मिलनी चाहिए। एक टेस्ट मैट्रिक्स को प्रकाशित क्रेडेंशियल्स विरासत में नहीं मिलनी चाहिए। यहां तक कि रिलीज़ वर्कफ़्लो के भीतर भी, अनुमतियाँ संभवतः सबसे संकीर्ण जॉब सीमा पर ही दी जानी चाहिए। PyPI की दस्तावेज़ीकरण विशेष रूप से जॉब-स्तर की अनुशंसा करती है। आईडी-टोकन: लिखें व्यापक वर्कफ़्लो-स्तर की अनुमतियों के बजाय। यह सलाह केवल सुंदरता के बारे में नहीं है। यह इस बारे में है कि एक समझौता किया हुआ कदम प्रकाशन की घटना न बन जाए।पाइपाई दस्तावेज़)
तीसरी परिवर्तन उपभोक्ताओं के लिए अपरिवर्तनीय उत्पत्ति है। पाइथन पैकेजिंग इकोसिस्टम यहाँ सुधार कर रहा है, और Simple Repository API विनिर्देश में अब प्रति-फ़ाइल हैश और उत्पत्ति-संबंधी विशेषताओं के लिए समर्थन शामिल है। टीमों द्वारा हर नई उत्पत्ति सुविधा को अपनाने से पहले भी, मेंटेनर्स स्पष्ट हैश प्रकाशित करके, आंतरिक मिरर को प्रोत्साहित करके, और आधिकारिक रिलीज़ की उत्पत्ति को सत्यापित करना आसान बनाकर व्यावहारिक सुधार कर सकते हैं। इनमें से कोई भी उपाय उन उपभोक्ताओं को नहीं बचा सकता था जिन्होंने उस क्षण में एक खराब आर्टिफैक्ट पर अंधाधुंध भरोसा किया था, लेकिन यह बाद में विश्वसनीय पुनर्प्राप्ति का मार्ग छोटा कर देता है। (पाइथन पैकेजिंग)
चौथा परिवर्तन इंसिडेंट-मोड दस्तावेज़ीकरण है। उपभोक्ताओं को तीन प्रश्नों का त्वरित उत्तर चाहिए: कौन से संस्करण प्रभावित हैं, मैं कैसे जांचूँ कि मैंने उन्हें खींचा है, और मुझे कौन से सटीक IOC और सफ़ाई चरणों का पालन करना चाहिए। LiteLLM इश्यू ट्रैकर में पहले से ही उस जानकारी का अधिकांश हिस्सा कच्चे रूप में मौजूद है। मेंटेनर्स, या कोई भी मेंटेनर जो समान घटना का सामना कर रहा हो, उसे यथाशीघ्र एक मानक सूचना पृष्ठ में परिवर्तित कर देना चाहिए। तेज़ी से बदलती आपूर्ति श्रृंखला घटनाओं में, सार्वजनिक स्पष्टता एक सुरक्षा नियंत्रण है। (गिटहब)
कौन सी चीज़ें उपभोक्ता टीमों को बदलनी चाहिए, भले ही उन्होंने कभी LiteLLM का उपयोग न किया हो
इस घटना को बर्बाद करने का सबसे आसान तरीका इसे "उनके पैकेज की समस्या" मान लेना है। यहाँ नुकसान को कम करने वाले नियंत्रण सामान्य-उद्देश्यीय नियंत्रण हैं जिन्हें कई टीमें अभी तक लागू नहीं कर पाई हैं। पहला सरल है: प्रोडक्शन स्टार्टअप के दौरान निर्भरताएँ गतिशील रूप से स्थापित न करें। जितना अधिक आप … पर निर्भर करते हैं यूवी रन, अस्थायी इंस्टॉलेशन, या रनटाइम पथों में अनसुलझी निर्भरता प्राप्त करना, आप पैकेज इकोसिस्टम को ही अपनी प्रोडक्शन उपलब्धता और सुरक्षा सीमा का हिस्सा बनाते जाते हैं। यहां तक कि इस घटना पर HN की चर्चा भी जल्दी ही इस बात पर सहमत हो गई कि डिप्लॉय करने योग्य आर्टिफैक्ट्स लॉन्च समय पर लाइव निर्भरता प्राप्त करने की तुलना में अधिक सुरक्षित और ऑडिट करने योग्य होते हैं। (हैकर न्यूज़)
दूसरा है उच्च-मूल्य वाले वातावरणों के लिए सटीक पिनिंग और स्थानीय हैश। pip का secure-install मार्गदर्शन इससे अधिक स्पष्ट नहीं हो सकता: हैश-चेकिंग मोड के लिए सभी आवश्यकताओं और निर्भरताओं को हैश और पिन किया जाना चाहिए, और दूरस्थ रूप से प्रदान किए गए इंडेक्स हैश उस विश्वास मॉडल को पूरा करने के लिए पर्याप्त नहीं हैं। टीमों को हर फेंकने योग्य नोटबुक और प्रयोग में इस कड़ाई को समान रूप से लागू करने की आवश्यकता नहीं है, लेकिन उन्हें इसे CI, प्रोडक्शन बिल्ड्स, साझा AI गेटवे और उन आंतरिक पैकेजों पर अवश्य लागू करना चाहिए जो गोपनीय जानकारियों के पास होते हैं। (पाइप)
तीसरा है आर्टिफैक्ट और मिरर रणनीति। पैकेज इंडेक्स आपके महत्वपूर्ण वातावरणों के लिए एकमात्र स्रोत नहीं होना चाहिए। आंतरिक मिरर, क्यूरेट किए गए आर्टिफैक्ट रिपॉजिटरी, और ज्ञात-सही निर्भरताओं का बिल्ड-टाइम प्रमोशन आकर्षक नियंत्रण नहीं हैं, लेकिन जब सार्वजनिक रजिस्ट्री को किसी प्रोजेक्ट को क्वारंटाइन करना पड़े या किसी घटना से पहले आपने वास्तव में कौन सी फ़ाइल इंस्टॉल की थी, यह साबित करना हो, तो ये फायदेमंद साबित होते हैं। यह केवल Python या LiteLLM तक सीमित नहीं है। यह आधुनिक सॉफ़्टवेयर डिलीवरी में आपूर्ति श्रृंखला के सबसे पुराने और सबसे टिकाऊ सबकों में से एक है। (पाइपाई)
चौथा है बिल्ड और गेटवे होस्ट्स के लिए आउटबाउंड नेटवर्क अनुशासन। यदि आपके बिल्ड नोड्स और AI गेटवे मनमाने आउटबाउंड कनेक्शन बना सकते हैं, तो क्रेडेंशियल चुराने वाला मैलवेयर सीधे घर तक पहुँचने का रास्ता पा लेता है। प्रतिबंधात्मक निकास हमेशा आसान नहीं होता, लेकिन यह कई सप्लाई चेन समझौतों को "मौन निकासी" से "पहचाने गए और अवरुद्ध प्रयास" में बदल देता है। यहाँ तक कि जब प्रारंभिक समझौता रोका नहीं जाता है, तब भी आउटबाउंड प्रतिबंध घटना को अदृश्य चोरी से शोरगुल वाली विफलता में बदल सकता है। ज्ञात एक्सफिल्ट्रेशन अवसंरचना को ब्लॉक करने पर ट्रिवी मार्गदर्शन का जोर उस व्यापक सबक का हिस्सा है। (गिटहब)
एक अंतिम नियंत्रण मानचित्रण पाठ को अधिक ठोस बनाता है।
| कमजोर अभ्यास | ऐसे मामलों में यह क्यों विफल हुआ | बेहतर नियंत्रण |
|---|---|---|
| CI में दीर्घकालिक रिलीज़ का रहस्य | एक खुला हुआ टोकन दुर्भावनापूर्ण आर्टिफैक्ट प्रकाशित कर सकता है। | अल्पकालिक OIDC-निर्मित टोकन के साथ विश्वसनीय प्रकाशन। (पाइपाई दस्तावेज़) |
| रनटाइम पर गतिशील इंस्टॉलेशन | प्रोडक्शन हर लॉन्च पर रजिस्ट्री पर भरोसा करता है। | एक बार बनाएँ, आर्टिफैक्ट्स को प्रमोट करें, ज्ञात-सही इमेजेज़ से चलाएँ।हैकर न्यूज़) |
| केवल पिन संस्करण | एक दुर्भावनापूर्ण प्रकाशित संस्करण फिर भी पिन को संतुष्ट करता है। | सटीक संस्करणों को पिन करें और स्थानीय हैश लागू करें। (पाइप) |
| परिवर्तनीय गिटहब एक्शन टैग्स | हमलावर एक विश्वसनीय टैग को दुर्भावनापूर्ण कोड की ओर पुनः निर्देशित कर सकते हैं। | कार्रवाइयों को अपरिवर्तनीय कमिट SHA पर पिन करें। (गिटहब) |
| व्यापक नौकरी अनुमतियाँ | एक समझौता किया गया कदम हर रहस्य को देख लेता है। | नौकरी-स्तर पर न्यूनतम विशेषाधिकार और अलग-अलग रिलीज़ नौकरियाँ।पाइपाई दस्तावेज़) |
CVE-2024-3094 से आपूर्ति श्रृंखला का सबक
हर सप्लाई चेन घटना को उस तरह से एक पैकेज-स्तर की "कमजोरी" के रूप में साफ-सुथरे तरीके से दर्ज नहीं किया जाता है, जैसा कि इंजीनियर CVE सलाहकारों को पढ़ने के आदी हैं, लेकिन CVE-2024-3094 सही तुलना बिंदु बना हुआ है क्योंकि यह दिखाता है कि जब एक विश्वसनीय वितरण पथ दुर्भावनापूर्ण सामग्री ले जाता है तो समस्या कितनी गंभीर हो जाती है। NVD, CVE-2024-3094 का वर्णन xz के 5.6.0 और 5.6.1 संस्करणों से शुरू होने वाले अपस्ट्रीम टारबल्स में दुर्भावनापूर्ण कोड के रूप में करता है, जहाँ बिल्ड प्रक्रिया ने एक छिपी हुई ऑब्जेक्ट फ़ाइल निकाली और बिल्ड के दौरान लाइब्रेरी के व्यवहार को संशोधित किया। मुख्य सबक यह नहीं था कि "xz में एक बग था।" सबक यह था कि आर्टिफैक्ट आपूर्ति श्रृंखला स्वयं समझौता कर ली गई थी। (एनवीडी)
यही कारण है कि CVE-2024-3094 यहाँ प्रासंगिक है। दोनों ही मामलों में, हमलावर ने बाहरी रूप से किसी सामान्य एप्लिकेशन बग का शोषण करने के बजाय सॉफ़्टवेयर वितरण पथ में विश्वास का दुरुपयोग किया। xz मामले में, दुर्भावनापूर्ण लॉजिक अपस्ट्रीम रिलीज़ सामग्री के भीतर मौजूद था और इसने डाउनस्ट्रीम सॉफ़्टवेयर के निर्माण और लिंक करने के तरीके को प्रभावित किया। LiteLLM मामले में, दुर्भावनापूर्ण लॉजिक पैकेज रजिस्ट्री रिलीज़ के भीतर मौजूद था और उन वातावरणों को निशाना बनाया जिन्होंने उन्हें इंस्टॉल किया था। अलग-अलग तंत्र, एक ही सामरिक सत्य: विश्वसनीय वितरण चैनल विशेषाधिकार प्राप्त हमले की सतहें हैं। (एनवीडी)
शोषण की शर्तें भी अंतर समझाने में मदद करती हैं। CVE-2024-3094 प्रभावित xz रिलीज़ सामग्री और विशिष्ट डाउनस्ट्रीम बिल्ड एवं रनटाइम परिस्थितियों पर निर्भर था। LiteLLM घटना उपभोक्ताओं द्वारा PyPI से विशिष्ट दुर्भावनापूर्ण पैकेज संस्करणों को खींचने और फिर, 1.82.8 मामले में, सामान्य Python स्टार्टअप करने पर निर्भर थी। एक तरह से, LiteLLM की 1.82.8 स्टार्टअप शर्त कई पीड़ितों के लिए परिचालनात्मक रूप से सरल है: वह इंटरप्रेटर व्यवहार जो बनाता है .पथ कार्यन्वयन की संभावना सामान्य, प्रलेखित पाइथन व्यवहार है। इससे समझौता स्थापित होने के बाद गलती से ट्रिगर करना आसान हो जाता है।एनवीडी)
निवारण का पाठ भी साझा किया गया है। xz में, रक्षकों को ज्ञात-सुरक्षित संस्करणों पर जाने और आपूर्ति श्रृंखला पथ को स्वयं संदिग्ध मानने के लिए कहा गया था। LiteLLM मामले में, रक्षकों को प्रभावित आर्टिफैक्ट्स को हटाना चाहिए, सीक्रेट्स को घुमाना चाहिए, रिलीज़ पथ को सत्यापित करना चाहिए, और ट्रस्टेड पब्लिशिंग, सटीक पिनिंग, और हैश प्रवर्तन जैसे नियंत्रणों के साथ आर्टिफैक्ट ट्रस्ट को मजबूत करना चाहिए। पैकेज का नाम बदल गया। आवश्यक अनुशासन नहीं बदला।एनवीडी)
यही कारण है कि यह घटना उन टीमों का भी ध्यान खींचने लायक है जो LiteLLM का उपयोग नहीं करतीं। यह एक ताज़ा, एआई-संबंधित उदाहरण है एक बहुत पुरानी सच्चाई का जिसे CVE-2024-3094 ने नज़रअंदाज़ करना असंभव बना दिया: यदि आप अपनी रिलीज़ चेन की जांच करने की तुलना में उस पर अधिक भरोसा करते हैं, तो हमलावर अंततः इसे नोटिस कर लेंगे।एनवीडी)
अधिक जानकारी के लिए
प्रोजेक्ट इश्यू ट्रैकर पर LiteLLM घटना की स्थिति और संस्करण-विशिष्ट ट्रैकिंग। (गिटहब)
LiteLLM सार्वजनिक पैकेज पेज और उत्पाद दस्तावेज़ीकरण, यह समझने के लिए उपयोगी है कि यह पैकेज उच्च-मूल्य वाले AI कंट्रोल-प्लेन फ़ंक्शंस के इतने करीब क्यों है। (पाइपाई)
के लिए पाइथन दस्तावेज़ीकरण साइट मॉड्यूल और .पथ कार्य-निष्पादन व्यवहार, जो कि मुख्य तकनीकी कारण है कि संस्करण 1.82.8, 1.82.7 से अधिक खतरनाक था।पाइथन दस्तावेज़ीकरण)
ट्रस्टेड पब्लिशिंग पर PyPI दस्तावेज़ीकरण और सुरक्षित इंस्टॉल्स पर pip दस्तावेज़ीकरण और --हैश-आवश्यक, जो सीधे तौर पर रिलीज हार्डनिंग और उपभोक्ता-पक्ष कलाकृति विश्वास से संबंधित हैं। (पाइपाई दस्तावेज़)
Aqua का Trivy सलाहकार और चर्चा थ्रेड यहाँ इसलिए महत्वपूर्ण हैं क्योंकि LiteLLM के रखरखावकर्ता ने हालिया Trivy समझौते के स्पष्ट स्रोत को सार्वजनिक रूप से लिंक किया है और यह सलाहकार दस्तावेज़ व्यापक प्रमाणपत्र-समझौता और रिलीज़-चेन संदर्भ को दर्ज़ करता है।गिटहब)
NVD का CVE-2024-3094, xz सप्लाई चेन बैकडोर के लिए रिकॉर्ड, जो यह समझने के लिए सबसे उपयोगी CVE-स्तर की तुलना बना हुआ है कि जब एक विश्वसनीय वितरण पथ हमले का माध्यम बन जाता है तो उसका क्या मतलब होता है।एनवीडी)
पैनलिजेंट संसाधन जो स्वाभाविक रूप से पोस्ट-इंसीडेंट वेरिफिकेशन और एआई सप्लाई चेन सीमा चर्चा से प्रासंगिक हैं, उनमें उत्पाद होमपेज, डॉक्स पेज, और एआई निष्पादन सीमाओं तथा सप्लाई चेन जोखिम पर हैकिंग लैब्स के लेख शामिल हैं।पेनलिजेंट)
Hindi 
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Arabic 
Turkish 
Hebrew