LiteLLM 1.107.0 संक्रमित—जाँच के लिए Python चलाना भी जोखिम

Microsoft के तकनीकी विश्लेषण के अनुसार, 21 अक्टूबर 2026 को LiteLLM 1.107.0 के संक्रमित व्हील PyPI पर और संक्रमित कंटेनर छवियाँ आधिकारिक रजिस्ट्री में प्रकाशित हुईं। प्रभावित परिवेश में केवल Python शुरू करने से हानिकारक कोड चल सकता था; अनुप्रयोग को LiteLLM आयात करने की जरूरत नहीं थी। इसी कारण संदिग्ध मशीन पर संस्करण देखने के लिए Python या pip चलाना भी जोखिम है।

भारत की राष्ट्रीय साइबर एजेंसी ने CERT-In की 23 अक्टूबर की सलाह सूची में LiteLLM पैकेज और कंटेनर छवियों पर CIAD-2026-0053 दर्ज किया। भारतीय संस्थानों के सामने अब प्रभावित प्रति की पहचान, उसे अलग करने और उस परिवेश से सुलभ कुंजियाँ बदलने का काम है। सार्वजनिक रजिस्ट्री से पैकेज हट जाने पर पहले डाउनलोड की गई प्रति या उससे बनी आंतरिक छवि अपने आप साफ नहीं होती।

कौन-से व्हील और कंटेनर टैग प्रभावित हुए

LiteLLM की घटना-जाँच के अनुसार, 21 अक्टूबर को litellm==1.107.0 के सात संक्रमित व्हील PyPI पर प्रकाशित हुए और लगभग दो घंटे बाद उन्हें अलग कर दिया गया। Docker Hub तथा GitHub Container Registry में भी संक्रमित छवियाँ पहुँचीं। Docker Hub के v1.107.0, latest, main-latest और main-stable टैग बाद में हटाए गए या सत्यापित साफ छवियों की ओर मोड़े गए।

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

रिलीज़ तक हमलावर की पहुँच एक पहले उजागर हुई LiteLLM Agent Platform मास्टर कुंजी से शुरू हुई, जिसे रद्द नहीं किया गया था। उससे संगठन स्वामी का GitHub टोकन मिला; हमलावर ने अतिरिक्त रखरखावकर्ताओं की पहचान संबंधी पहुँच भी हासिल की। फिर रिलीज़ कार्यप्रवाह का स्रोत असली BerriAI/litellm से मिलते-जुलते Berri-AI/litellm भंडार की ओर मोड़ा गया। प्रकाशन आधिकारिक कार्यप्रवाह से हुआ, लेकिन निर्माण का स्रोत हमलावर के नियंत्रण वाला भंडार था। बाद में कार्यप्रवाह में किया गया बदलाव दृश्य इतिहास से हटाया गया, इसलिए केवल मौजूदा भंडार देखकर उस समय की रिलीज़ का स्रोत तय नहीं किया जा सकता।

Python शुरू होते ही कोड कैसे सक्रिय हुआ

संक्रमित व्हील ने cook.pth, cook.py और sitecustomize.py को Python परिवेश के पुस्तकालय पथ में स्थापित किया। ये फ़ाइलें सामान्य litellm निर्देशिका के बाहर थीं। Python आरंभ होते समय .pth फ़ाइल की निष्पादन योग्य पंक्ति और sitecustomize को संसाधित कर सकता है। इस रास्ते से कुंजियाँ जुटाने वाला कोड ऐसे काम के दौरान भी सक्रिय हो सकता था जिसका LiteLLM से कोई सीधा संबंध नहीं था।

इसी बनावट के कारण प्रभावित परिवेश में pip से पैकेज की जानकारी निकालना या छोटा Python जाँच कार्यक्रम चलाना सुरक्षित निरीक्षण नहीं है। दुर्भावनापूर्ण कोड डेवलपर औजारों, क्लाउड पहचान, ब्राउज़र डेटा, SSH सामग्री, परिवेश चर और LiteLLM प्रॉक्सी के डेटाबेस में उपलब्ध जानकारी तक पहुँचने के लिए बनाया गया था। अलग घटक Unix आधारित परिवेश में दूरस्थ कोड लाने में सक्षम था, लेकिन उसके जरिए अतिरिक्त कोड वास्तव में लाए और चलाए जाने की पुष्टि नहीं हुई। किसी लक्षित फ़ाइल या कुंजी की मौजूदगी भी अपने आप सफल चोरी का प्रमाण नहीं है।

संदिग्ध परिवेश को बाहर से जाँचने का क्रम

पहले प्रभावित प्रति को चलने और फिर से तैनात होने से रोकें। संदिग्ध विकास मशीन, निर्माण एजेंट, परीक्षण परिवेश, कंटेनर और LiteLLM गेटवे को अलग करें। जहाँ संचालन की दृष्टि से सुरक्षित हो, चल रही Python प्रक्रियाएँ रोकें और स्वचालित कार्यों को उन्हें दोबारा शुरू करने से रोकें। निरीक्षण के लिए ज्ञात साफ मशीन के विश्वसनीय औजार इस्तेमाल करें, ताकि जाँच के दौरान संदिग्ध इंटरप्रेटर फिर सक्रिय न हो।

1. निर्भरता लॉक फ़ाइलों, निर्माण अभिलेखों, पैकेज कैश, आंतरिक मिरर और कंटेनर रजिस्ट्री के रिकॉर्ड से पता करें कि प्रभावित रिलीज़ कहाँ पहुँची। बदलने वाले टैग का नाम अकेले दर्ज न करें; डाउनलोड के समय और छवि के डाइजेस्ट को भी जोड़ें।
2. प्रभावित प्रणाली को अलग रखकर उसके पुस्तकालय पथ में cook.pth, cook.py और sitecustomize.py देखें। उपलब्ध प्रक्रिया तथा नेटवर्क अभिलेखों में Python का आरंभ, बाहरी संपर्क और संबंधित पहचान के बाद के उपयोग को एक साथ मिलाएँ। फ़ाइल का न मिलना परिवेश के साफ होने का निर्णायक प्रमाण नहीं है।
3. साक्ष्य सुरक्षित करने के बाद सत्यापित साफ कलाकृतियों से परिवेश और कंटेनर फिर बनाएँ। केवल litellm निर्देशिका हटाना पर्याप्त नहीं है, क्योंकि आरंभ में चलने वाली फ़ाइलें उसके बाहर स्थापित हुई थीं। पुराने पैकेज कैश और आंतरिक मिरर को अगले निर्माण का स्रोत बनने से भी रोकें।

प्रभावित संस्करण के स्थापित होने और उस परिवेश में Python चलने का रिकॉर्ड मिलने पर पहचान संबंधी जानकारी के उजागर होने की आशंका मानकर कार्रवाई करनी चाहिए। वास्तविक डेटा निकासी का निष्कर्ष प्रक्रिया, नेटवर्क और पहचान उपयोग के साक्ष्य मिलाकर निकलेगा। इससे तत्काल अलगाव में देरी किए बिना घटना की सीमा अधिक सटीक तय की जा सकती है।

कौन-सी कुंजियाँ पहले बदलें

कुंजी बदलाव की सीमा उस पहचान के अधिकारों से तय होगी जिसके तहत संक्रमित कोड चला। पहले ऐसे अधिकार निष्क्रिय करें जिनसे नई कुंजियाँ बनाई जा सकती हैं या निर्माण और प्रकाशन कार्यप्रवाह बदला जा सकता है। फिर मॉडल प्रदाताओं की API कुंजियाँ, LiteLLM प्रॉक्सी में रखी प्रदाता कुंजियाँ, क्लाउड और कार्यभार पहचान, CI/CD रहस्य, स्रोत नियंत्रण तथा रजिस्ट्री टोकन बदलें। प्रॉक्सी होस्ट पर DATABASE_URL में मौजूद पासवर्ड और उससे उपलब्ध डेटाबेस अधिकार भी इसी समीक्षा में आते हैं।

डेवलपर मशीन पर सुलभ SSH और GPG निजी कुंजियाँ, AI कोडिंग औजारों के टोकन तथा ब्राउज़र सत्र भी प्रभावित हो सकते हैं। बदलाव ज्ञात साफ मशीन से करें और जहाँ लागू हो, सक्रिय सत्र अलग से रद्द करें; कुंजी या पासवर्ड बदलने से हर जारी सत्र तुरंत समाप्त नहीं होता। हर संस्था के लिए पूरी सूची समान नहीं होगी: निर्णायक बात यह है कि संक्रमित प्रक्रिया किन फ़ाइलों, परिवेश चरों, डेटाबेस अभिलेखों और कार्यभार पहचानों को पढ़ सकती थी।

जिन संस्थानों ने रिलीज़ सीधे स्थापित नहीं की, उन्हें भी घटना के दौरान बनी छवियों और आंतरिक मिरर की वंशावली देखनी होगी। वर्तमान टैग के बजाय उस समय वास्तव में डाउनलोड या निर्मित कलाकृति तथा उससे सुलभ पहचानें पुनर्निर्माण और कुंजी बदलाव की सीमा तय करती हैं।

यह भी पढ़ें:

• वीडियो प्रकाशित करने से पहले YouTube कॉपीराइट जाँच कैसे करें—और हरे निशान की सीमा क्या है
• Patch Tuesday में सब कुछ पहले नहीं—जोखिम से सही क्रम बनाएँ
• गुमनाम Instagram Stories देखने वाली साइटें सुरक्षित हैं या नहीं: पाँच खतरे और जाँच-सूची