AI डिपेंडेंसी पर हमला: LiteLLM कंप्रोमाइज़ डेवलपर्स को क्या सिखाता है

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

ये भरोसे के सार्थक संकेत हैं। लेकिन इनसे यह साबित नहीं होता कि रिलीज़ पर अधिकार रखने वाले किसी व्यक्ति ने बनने वाले कोड को बदला नहीं।

21 अक्टूबर 2026 को LiteLLM की सामान्य पब्लिशिंग प्रक्रिया ने दुर्भावनापूर्ण वर्ज़न 1.107.0 को PyPI और अपनी आधिकारिक कंटेनर रजिस्ट्रियों तक पहुंचा दिया। LiteLLM की बाद की जांच ने बताया कि एक हमलावर ने शक्तिशाली GitHub क्रेडेंशियल हासिल किए, एक निजी रिलीज़ वर्कफ़्लो बदला और उसे एक मिलते-जुलते नाम वाली रिपॉज़िटरी से कोड बनाने का निर्देश दिया। स्वतंत्र शोधकर्ताओं ने दुर्भावनापूर्ण पैकेज की जांच की और ऐसे तरीके पाए जो Python शुरू होते ही क्रेडेंशियल इकट्ठा करते हैं। (LiteLLM’s incident investigation, Microsoft’s payload analysis और Datadog’s independent analysis)

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

रिलीज़ वैध दिखी क्योंकि प्रक्रिया वैध थी

LiteLLM ऐसा सॉफ़्टवेयर देता है जिससे एप्लिकेशन अलग-अलग लैंग्वेज-मॉडल प्रोवाइडर से जुड़ सकते हैं। इस जगह पर होने के कारण वह API कीज़ और दूसरे ज़रूरी कॉन्फ़िगरेशन संभाल सकता है। वह डेवलपमेंट एनवायरनमेंट और ऑटोमेटेड बिल्ड में भी इंस्टॉल होता है।

LiteLLM की 23 अक्टूबर की जांच के अनुसार, हमला दुर्भावनापूर्ण रिलीज़ आने से काफ़ी पहले शुरू हो चुका था। मई में एक प्रायोगिक आंतरिक Agent Platform की एडमिन कुंजी एक सार्वजनिक रिपॉज़िटरी में कमिट हो गई। फ़ाइल कुछ घंटों बाद हटा दी गई, लेकिन कुंजी वैध बनी रही। LiteLLM ने बताया कि एक हमलावर ने उसका इस्तेमाल 10 अक्टूबर को Agent Platform तक पहुंचने और एक ऑर्गनाइज़ेशन ओनर से जुड़ा GitHub CLI OAuth टोकन पाने के लिए किया। (LiteLLM’s reported investigation)

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

LiteLLM ने बताया कि हमलावर ने ओनर-स्तर के टोकन से ऐसे वर्कफ़्लो चलाए जिनसे और सीक्रेट उजागर हुए। 21 अक्टूबर को हमलावर ने एक निजी रिलीज़ वर्कफ़्लो बदलकर उसे कॉन्फ़िगर किए जा सकने वाले सोर्स रिपॉज़िटरी ओनर को स्वीकार करने लायक बना दिया। एक सामान्य ब्रांच-प्रोटेक्शन नियम ने शुरुआती पुश को अस्वीकार कर दिया। फिर भी ऑर्गनाइज़ेशन-ओनर क्रेडेंशियल ने बदलाव को आगे जाने दिया। (LiteLLM’s reported investigation)

बदले हुए वर्कफ़्लो ने फिर वैध BerriAI/litellm सोर्स की जगह मिलते-जुलते नाम वाली रिपॉज़िटरी Berri-AI/litellm से बिल्ड किया। LiteLLM के अनुसार, दूसरे मेंटेनर के चुराए गए टोकन ने प्रोडक्शन रिलीज़ गेट को मंज़ूरी दी, जबकि ऑर्गनाइज़ेशन-ओनर क्रेडेंशियल ने स्टेजिंग डिस्पैच चलाया। नतीजे में बने आर्टिफैक्ट अपेक्षित रिलीज़ इन्फ्रास्ट्रक्चर से होकर आधिकारिक वितरण चैनलों तक पहुंच गए। (LiteLLM investigation और Datadog analysis)

Microsoft की स्वतंत्र पेलोड जांच रिलीज़ कंप्रोमाइज़ की इस कहानी का समर्थन करती है, लेकिन साफ़ कहती है कि शुरुआती अपस्ट्रीम पहुंच और क्रेडेंशियल चोरी कैसे हुई, इसका उसने स्वतंत्र रूप से निर्धारण नहीं किया। इसलिए क्रम के उस हिस्से को LiteLLM के बताए फ़ोरेंसिक निष्कर्ष की तरह ही समझना चाहिए। (Microsoft Security Research)

LiteLLM की टाइमलाइन के अनुसार दुर्भावनापूर्ण रिलीज़ 21 अक्टूबर को लगभग 11:39 UTC पर ऑनलाइन आई। एक सार्वजनिक इश्यू ने लगभग 12:06 पर समस्या बताई, PyPI ने लगभग 13:23 तक रिलीज़ को क्वारंटीन किया और कंटेनर रजिस्ट्रियां लगभग 13:51 तक पीछे आईं, जिस अवधि को LiteLLM लगभग दो घंटे बताता है। Datadog PyPI क्वारंटीन लगभग 13:20 और कंटेनर इमेज हटना लगभग 13:53 बताता है, यह भी करीब दो घंटे है, और पहचान का कोई समय नहीं देता। दोनों विवरणों में फ़र्क़ कुछ मिनटों का है, कुल तस्वीर में नहीं। (LiteLLM’s reported investigation और Datadog analysis)

भरोसेमंद पब्लिशिंग रास्ता भरोसेमंद सोर्स कोड की गारंटी नहीं है

तीन सवालों को अलग करना उपयोगी है।

प्रामाणिकता पूछती है कि आर्टिफैक्ट अपेक्षित पब्लिशर से आया या नहीं। प्रोवेनेंस उस प्रक्रिया और दर्ज सोर्स का वर्णन करता है जिससे वह बना। कोड की भरोसेमंदी पूछती है कि नतीजे में बना सॉफ़्टवेयर चलाने के लिए सुरक्षित है या नहीं।

ये गुण आपस में जुड़े हैं, लेकिन एक-दूसरे की जगह नहीं ले सकते।

बिल्ड रिकॉर्ड या प्रोवेनेंस एटेस्टेशन उस वर्कफ़्लो और सोर्स रिपॉज़िटरी की पहचान बता सकता है जिससे आर्टिफैक्ट बना, पर यह तय नहीं करता कि वह सोर्स अधिकृत या सुरक्षित था या नहीं। LiteLLM की घटना में हमलावर ने प्रभावित किया कि वैध वर्कफ़्लो कौन सा सोर्स बनाए। Datadog ने बताया कि प्रकाशित आर्टिफैक्ट पर देखने में वैध बिल्ड प्रोवेनेंस था, जो दुर्भावनापूर्ण फ़ोर्क को उनका सोर्स सही-सही बताता था। (Datadog Security Labs)

यह साइनिंग, प्रोवेनेंस सत्यापन या Trusted Publishing छोड़ देने का कारण नहीं है। ये नियंत्रण किसी आर्टिफैक्ट की उत्पत्ति सत्यापित करने या लंबे समय तक चलने वाले पब्लिशर क्रेडेंशियल पर निर्भरता घटाने में मदद कर सकते हैं। पर वे अपने आप यह तय नहीं करते कि किसी विशेषाधिकार वाली पब्लिशर पहचान से समझौता हुआ या बिल्ड ने इच्छित सोर्स चुना। LiteLLM के 30 अक्टूबर के फ़ॉलो-अप के अनुसार उसकी अपनी पाइपलाइन ने आर्टिफैक्ट साइन किए और उन पर वैध Trusted Publishing प्रोवेनेंस था। (LiteLLM’s follow-up)

डेवलपमेंट टीम के लिए यह फ़र्क़ बदल देता है कि किसी डिपेंडेंसी का मूल्यांकन कैसे हो। भरोसा पैकेज रजिस्ट्री पर खत्म नहीं होता। वह पब्लिशर की पहचान, मंज़ूर सोर्स रिपॉज़िटरी, बिल्ड की अनुमतियों और उस एनवायरनमेंट पर भी निर्भर करता है जहां पैकेज चलता है।

इस पैकेज को इंस्टॉल करना ही काफ़ी क्यों हो सकता था

दुर्भावनापूर्ण LiteLLM रिलीज़ इस पर निर्भर नहीं थी कि कोई डेवलपर किसी AI मॉडल से गलत सवाल पूछे। उसने Python के सामान्य स्टार्टअप व्यवहार का इस्तेमाल किया।

Microsoft और Datadog ने प्रभावित wheel से आई तीन दुर्भावनापूर्ण फ़ाइलें पाईं, cook.pth, cook.py और sitecustomize.py। Python इंटरप्रेटर के शुरू होने के दौरान कुछ .pth निर्देश प्रोसेस कर सकता है और sitecustomize लोड कर सकता है। प्रभावित एनवायरनमेंट में Python शुरू करना ही दुर्भावनापूर्ण कोड को सक्रिय कर सकता था, भले ही एप्लिकेशन ने LiteLLM कभी इंपोर्ट न किया हो। (Microsoft analysis और Datadog analysis)

इससे संभावित जोखिम उन सिस्टम से आगे बढ़ गया जो LiteLLM को सक्रिय रूप से गेटवे की तरह इस्तेमाल करते थे। कंप्रोमाइज़ पैकेज इंस्टॉल होने के बाद डेवलपर का लैपटॉप, टेस्ट कंटेनर या बिल्ड एजेंट किसी असंबंधित काम के लिए Python चला सकता था।

बरामद पेलोड के निशाने पर पहुंच में आने वाले क्लाउड क्रेडेंशियल, डेवलपर और सोर्स-कंट्रोल क्रेडेंशियल, AI-प्रोवाइडर कीज़, ब्राउज़र डेटा, SSH सामग्री और LiteLLM डेटाबेस के कुछ रिकॉर्ड थे। उसमें एक ऐसा तंत्र भी था जो अतिरिक्त कोड ला सकता था। शोधकर्ताओं ने दूसरा चरण पहुंचाया जाते नहीं देखा, हालांकि Microsoft ने कहा कि लोडर को फिर से सक्रिय किया जा सकता था। (Microsoft analysis और Datadog analysis)

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

यह फ़र्क़ सुरक्षा रिपोर्टिंग और इंसिडेंट रिस्पांस, दोनों को दिशा देना चाहिए। प्रभावित रिलीज़ खतरनाक थी। इसका मतलब यह नहीं कि हर डाउनलोड पुष्ट ब्रीच बन गया।

पैकेज हटाने से भरोसा बहाल क्यों नहीं हो सकता

दुर्भावनापूर्ण स्टार्टअप फ़ाइलें LiteLLM की सामान्य एप्लिकेशन डायरेक्टरी के बाहर इंस्टॉल हो सकती थीं। केवल वह डायरेक्टरी हटाने से Python एनवायरनमेंट पेलोड को फिर चलाने में सक्षम रह सकता था। Microsoft और Datadog दोनों ने सामान्य पैकेज रिमूवल को पूरी रिकवरी मानने के खिलाफ़ चेताया। (Microsoft analysis और Datadog analysis)

जांच में एक व्यावहारिक जाल भी है। प्रभावित एनवायरनमेंट को जांचने के लिए उसी का Python या pip चलाने से वही स्टार्टअप व्यवहार ट्रिगर हो सकता है। संभावित रूप से कंप्रोमाइज़ मशीन की जांच करने वाली टीमों को संदिग्ध एनवायरनमेंट चलाने की जगह साफ़ टूल और अलग-थलग वर्कफ़्लो इस्तेमाल करना चाहिए।

जिन संगठनों ने वर्ज़न 1.107.0 इंस्टॉल किया हो सकता है, उनकी प्रतिक्रिया आधिकारिक एडवाइज़री और उनकी अपनी सुरक्षा टीम के मार्गदर्शन में होनी चाहिए। प्रभावित होस्ट, वर्कस्टेशन, कंटेनर और बिल्ड एनवायरनमेंट पहचानें। संदिग्ध एनवायरनमेंट को अलग करें या दोबारा बनाएं, संभावित एक्ज़ीक्यूशन और आउटबाउंड गतिविधि की जांच करें, और जिन क्रेडेंशियल तक कंप्रोमाइज़ प्रक्रिया पहुंच सकती थी, उन्हें साफ़ एनवायरनमेंट से रोटेट करें। बाद के दुरुपयोग के लिए संबंधित ऑडिट लॉग देखें। (Microsoft analysis और Datadog analysis)

रीबिल्ड और क्रेडेंशियल समीक्षा एक पैकेज हटाने से ज़्यादा मेहनत का काम हो सकता है। वह मेहनत असली जोखिम को संबोधित करती है, जो केवल LiteLLM के बने रहने तक सीमित नहीं है।

यह घटना डेवलपर्स के लिए क्या बदलती है

तात्कालिक सबक है कि डिपेंडेंसी पर भरोसे को ज़्यादा विशिष्ट बनाया जाए।

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

सॉफ़्टवेयर प्रकाशित करने वाली टीमों के लिए सोर्स का चयन रिलीज़ चलाने के अधिकार से स्वतंत्र रूप से सीमित होना चाहिए। रिलीज़ वर्कफ़्लो को केवल इसलिए मनमानी मिलती-जुलती रिपॉज़िटरी से बिल्ड करने में सक्षम नहीं होना चाहिए कि कोई विशेषाधिकार वाला अकाउंट इनपुट दे दे। पब्लिशर क्रेडेंशियल, ओनर-स्तर के अकाउंट और CI सीक्रेट का दायरा और अवधि कम से कम ज़रूरी होनी चाहिए। जहां कोई लीक हुई कुंजी मिले, वहां उसे सोर्स कंट्रोल से हटाने के बाद रिवोकेशन और एक्सपोज़र का आकलन होना चाहिए।

प्लेटफ़ॉर्म और सुरक्षा टीमों के लिए सबसे अहम सवाल अक्सर यह होता है कि कंप्रोमाइज़ डिपेंडेंसी कितनी दूर तक पहुंच सकती है। एक AI गेटवे प्रोवाइडर कीज़, क्लाउड वर्कलोड क्रेडेंशियल और डेटाबेस एक्सेस के पास बैठ सकता है। उन अनुमतियों की सीमा तय होनी चाहिए ताकि एक प्रक्रिया के कंप्रोमाइज़ होने से संगठन का व्यापक इन्फ्रास्ट्रक्चर अपने आप उजागर न हो जाए।

इनमें से कोई कदम पूरी सुरक्षा की गारंटी नहीं देता। साथ मिलकर वे इस मौके को घटाते हैं कि एक कंप्रोमाइज़ रिलीज़ बड़ी पहचान और इन्फ्रास्ट्रक्चर घटना बन जाए।

यह चल रहे AI सर्वर पर हमले से कैसे अलग है

TechiesJournal की अलग PoeLLM कवरेज उन हमलावरों की पड़ताल करती है जो कमज़ोर AI और डेवलपर सेवाओं का फ़ायदा उठाते हैं, जिनमें LiteLLM का एक MCP ऑथराइज़ेशन दोष भी शामिल है। यह रनटाइम एक्सपोज़र की समस्या है: हमलावर पहले से डिप्लॉय सॉफ़्टवेयर तक पहुंचता है।

21 अक्टूबर की घटना ने एक अलग सीमा पार की। दुर्भावनापूर्ण कोड सॉफ़्टवेयर डिलीवरी प्रक्रिया के ज़रिए ही आया। कोई टीम पहले कमज़ोर सार्वजनिक एंडपॉइंट उजागर किए बिना भी आधिकारिक स्रोत से कंप्रोमाइज़ वर्ज़न इंस्टॉल कर सकती थी।

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

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

भरोसेमंद रिलीज़ क्या बता सकती है और क्या नहीं

वैध रिलीज़ प्रक्रिया मूल्यवान है, और अक्टूबर की घटना इसे नहीं बदलती। वह दिखाती है कि रिलीज़ प्रक्रिया उन पहचानों और सोर्स की सुरक्षा विरासत में पाती है जिन पर वह भरोसा करती है।

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

व्यावहारिक अगला कदम हर AI टूल पर अविश्वास करना नहीं है। यह देखना है कि AI डिपेंडेंसी कहां चलती हैं, उनके पास कौन से क्रेडेंशियल पहुंच में हैं, उनके अपडेट कैसे मंज़ूर होते हैं और कंप्रोमाइज़ वर्ज़न को एनवायरनमेंट या उसके सीक्रेट उजागर छोड़े बिना कितनी जल्दी हटाया जा सकता है।

और गहराई से पढ़ें

1. LiteLLM: The attack chain behind the v1.107.0 LiteLLM release (23 अक्टूबर 2026)। क्रेडेंशियल श्रृंखला, वर्कफ़्लो में हेरफेर और रिलीज़ टाइमलाइन की मेंटेनर द्वारा की गई जांच।
2. Microsoft Security Research: Inside the LiteLLM 1.107.0 supply chain compromise (23 अक्टूबर 2026)। Python स्टार्टअप एक्ज़ीक्यूशन, क्रेडेंशियल संग्रह और रिस्पांस पर स्वतंत्र शोध।
3. Datadog Security Labs, LiteLLM supply chain compromise: What you need to know (21 अक्टूबर 2026)। आर्टिफैक्ट का स्वतंत्र विश्लेषण, वितरण टैग और उपचार मार्गदर्शन।
4. LiteLLM: What we are changing after October 21 (30 अक्टूबर 2026)। साइनिंग और नियोजित सुरक्षा नियंत्रणों पर मेंटेनर का फ़ॉलो-अप। ये नियंत्रण योजनाएं हैं, पूरा हो चुका काम नहीं।