# LiteLLM सप्लाई चेन अटैक: 2026 के दुर्भावनापूर्ण कोड इंजेक्शन का पूर्ण विश्लेषण और आपातकालीन प्रतिक्रिया मार्गदर्शक

मार्च 2026 में, PyPI के माध्यम से LiteLLM के संस्करण 1.82.7 और 1.82.8 में दुर्भावनापूर्ण कोड डाला गया था। यह विस्तृत मार्गदर्शक हमले, चुराए गए डेटा और तत्काल क्रेडेंशियल्स की जांच, सफाई और रोटेशन के सटीक कदम बताता है।

Canonical URL: https://a2a-mcp.org/blog/litellm-supply-chain-attack-2026-hi

Language: hi

Published: 2026-03-25

Updated: 2026-03-25

## मुख्य बिंदु

- **प्रभावित संस्करण**: PyPI पर LiteLLM 1.82.7 और 1.82.8 में दुर्भावनापूर्ण कोड इंजेक्ट किया गया था और इन्हें हटा दिया गया है। अंतिम सुरक्षित संस्करण **1.82.6** है।
- **हमले की विधि**: संस्करण 1.82.7 ने पेलोड को `proxy_server.py` में छिपाया; संस्करण 1.82.8 ने अतिरिक्त रूप से एक Python `.pth` फ़ाइल (`litellm_init.pth`) का उपयोग किया, जो **किसी भी Python प्रक्रिया शुरू होने पर** स्वचालित रूप से निष्पादित होती है, बिना LiteLLM को इम्पोर्ट किए।
- **चुराए गए डेटा**: SSH निजी कुंजियाँ, AWS/GCP/Azure क्रेडेंशियल्स, Kubernetes कॉन्फ़िग्स और Secrets, `.env` फ़ाइलें, क्रिप्टोकरेंसी वॉलेट्स, डेटाबेस पासवर्ड्स, Git क्रेडेंशियल्स, शेल इतिहास, और अधिक।
- **तीन-चरणीय हमला**: क्रेडेंशियल संग्रह → Kubernetes पार्श्व आंदोलन (विशेषाधिकारित Pods बनाना) → प्रच्छन्न systemd सेवा (`sysmon.service`) के माध्यम से स्थायित्व।
- **मूल कारण**: हमलावरों ने पहले Trivy सुरक्षा स्कैनर को कमजोर किया, LiteLLM मेंटेनर के PyPI प्रकाशन अधिकार प्राप्त किए, और सामान्य CI/CD को बायपास करके सीधे दुर्भावनापूर्ण पैकेज अपलोड किए।
- **एक्सपोज़र विंडो**: दुर्भावनापूर्ण संस्करण केवल 1–2 घंटे के लिए सक्रिय रहे, जिसके बाद एक फोर्क बॉम्ब दोष के कारण डेवलपर मशीनें क्रैश हो गईं, जिससे खोज हुई।
- **प्रभाव दायरा**: LiteLLM के प्रति माह 95 मिलियन से अधिक डाउनलोड हैं और कई AI एजेंट सिस्टम, MCP सर्वर और LLM ऑर्केस्ट्रेशन परियोजनाओं द्वारा अप्रत्यक्ष रूप से इस पर निर्भर है।

## समयरेखा और हमले के विवरण

24 मार्च, 2026 को, लोकप्रिय LiteLLM लाइब्रेरी — 100 से अधिक LLM प्रदाताओं के लिए एकीकृत API रैपर — के PyPI पर अचानक असामान्य संस्करण दिखाई दिए। थ्रेट एक्टर TeamPCP (जो पहले Trivy और KICS पर हमलों के लिए जिम्मेदार था) ने कमजोर मेंटेनर क्रेडेंशियल्स या PyPI टोकन का उपयोग करके दो दुर्भावनापूर्ण संस्करण जारी किए।

**संस्करण 1.82.7**:
- दुर्भावनापूर्ण पेलोड `litellm/proxy/proxy_server.py` के अंदर छिपाया गया।
- केवल तब ट्रिगर हुआ जब मॉड्यूल इम्पोर्ट किया गया या `litellm --proxy` चलाया गया।
- पेलोड डबल base64-

encoded Python स्क्रिप्ट था।

**संस्करण 1.82.8** (अधिक विनाशकारी):
- अतिरिक्त रूप से `litellm_init.pth` फ़ाइल रोपित की गई।
- Python का `site` मॉड्यूल इंटरप्रेटर स्टार्टअप पर `.pth` फ़ाइलों को स्वचालित रूप से निष्पादित करता है, जिससे **शून्य-इंटरैक्शन ट्रिगरिंग** संभव हुई।
- इसका अर्थ था कि यहाँ तक कि वे परियोजनाएँ जिन्होंने कभी स्पष्ट रूप से LiteLLM का उपयोग नहीं किया, भी संक्रमित हो सकती थीं यदि पैकेज उनके पर्यावरण में मौजूद था।

मैलवेयर ने डेटा को नकली डोमेन `models.litellm.cloud` तक निकालने के लिए हाइब्रिड एन्क्रिप्शन (AES-256-CBC + RSA-4096) का उपयोग किया।

## दुर्भावनापूर्ण पेलोड की तकनीकी विवरण

विश्लेषण से पता चलता है कि पेलोड तीन अलग-अलग चरणों में काम कर रहा था:

1. **क्रेडेंशियल हार्वेस्टिंग चरण**:
   - सामान्य पथों की पुनरावर्ती स्कैनिंग की: `~/.ssh/`, `~/.aws/`, `~/.kube/`, `~/.azure/`, `.env` फ़ाइलें, Kubernetes कॉन्फ़िग, Git क्रेडेंशियल, आदि।
   - पर्यावरण चर, मेमोरी सीक्रेट्स, क्लाउड मेटाडेटा एंडपॉइंट्स (IMDS), और कई क्रिप्टोकरेंसी वॉलेट फ़ाइलों को निकाला।

2. **लैटरल मूवमेंट चरण** (Kubernetes वातावरण):
   - क्लस्टर-वाइड सीक्रेट्स को पढ़ने के लिए ServiceAccount टोकन का उपयोग किया।
   - प्रत्येक नोड पर `kube-system` नेमस्पेस में विशेषाधिकार प्राप्त `alpine:latest` Pods बनाए, होस्ट फ़ाइलसिस्टम को माउंट किया।

3. **परसिस्टेंस चरण**:
   - एक बैकडोर को "सिस्टम टेलीमेट्री सेवा" (`sysmon.py` + systemd यूज़र सेवा) के रूप में तैनात किया।
   - नियमित रूप से `checkmarx.zone` जैसे डोमेन से अतिरिक्त पेलोड प्राप्त किए।

**खोज ट्रिगर**: दुर्भावनापूर्ण कोड के `subprocess.Popen` कॉलों ने `.pth` मैकेनिज्म के तहत एक एक्सपोनेंशियल फोर्क बम बनाया, जिससे तेजी से मेमोरी खत्म हो गई और मशीनें क्रैश हो गईं — यह एक दोष था जिसने अनजाने में हमले को उजागर कर दिया।

## LiteLLM एक उच्च मूल्य का लक्ष्य क्यों था

LiteLLM 100+ LLM प्रदाताओं का समर्थन करने वाली एक यूनिवर्सल प्रॉक्सी के रूप में काम करता है और व्यापक रूप से प्रोडक्शन AI एजेंट सिस्टम, MCP सर्वर, और मल्टी-मॉडल रूटिंग में उपयोग किया जाता है। डेवलपर्स अक्सर अंतर्निहित कॉल को एक ही लाइन के कोड से बदल देते हैं, जिसका अर्थ है कि संवेदनशील API कुंजियाँ अक्सर एक ही वातावरण में सह-अस्तित्व में होती हैं।

सप्लाई चेन अटैक चेन स्पष्ट थी: **Trivy समझौता → LiteLLM CI/CD Trivy पर निर्भर → पब्लिशिंग अधिकार लीक → PyPI पर सीधा दुर्भावनापूर्ण अपलोड**। यह आज के ओपन-सोर्स इकोसिस्टम में "ट्रस्ट बट वेरीफाई" के महत्व को उजागर करता है।

## तत्काल कार्रवाई: पहचान और सफाई के कदम

**चरण 1: इंस्टॉल किए गए वर्जन की जाँच करें**
```bash
pip show litellm
pip list | grep litellm
```

यदि वर्जन 1.82.7 या 1.82.8 मिलता है, तो इसे तुरंत हटाएँ:
```bash
pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall
```

**चरण 2: Python कैश और site-packages साफ़ करें**
+ `site-packages/litellm*` डायरेक्टरी और किसी भी `.pth` फ़ाइलों को हटाएँ।
+ pip कैश साफ़ करें: `pip cache purge`

**चरण 3: सभी क्रेडेंशियल्स को घुमाएँ (रोटेट करें)**
+ **तुरंत** SSH कुंजियों, सभी क्लाउड एक्सेस कुंजियों (AWS IAM, GCP सर्विस अकाउंट्स, Azure AD), Kubernetes टोकन, डेटाबेस पासवर्ड और CI/CD सीक्रेट्स को रोटेट करें।
+ संदिग्ध पहुँच के लिए क्लाउड ऑडिट लॉग (CloudTrail, Audit Logs, Activity Log) की समीक्षा करें।

**चरण 4: Kubernetes वातावरण के लिए अतिरिक्त जाँच**
+ `kube-system` नेमस्पेस में संदिग्ध Pods के लिए स्कैन करें।
+ नोड्स पर `~/.config/sysmon/` डायरेक्टरी और रॉग systemd सेवाओं की तलाश करें।
+ प्रभावित नोड्स को रीबिल्ड करें (दृढ़ता से अनुशंसित)।

**चरण 5: निर्भर परियोजनाओं को स्कैन करें**
+ सभी `requirements.txt`, `pyproject.toml`, और Docker इमेजों का ऑडिट करें; LiteLLM को `==1.82.6` पर पिन करें।
+ वातावरण को स्कैन करने के लिए `pip-audit` या `safety` जैसे टूल का उपयोग करें।

## उन्नत निवारण और सर्वोत्तम प्रथाएं

- **संस्करण पिन करें**: उत्पादन में Poetry, Pipenv या इसी तरह के टूल का उपयोग करते हुए LiteLLM को हमेशा `==1.82.6` (या नए सुरक्षित संस्करण) पर लॉक करें।
- **आपूर्ति श्रृंखला स्कैनिंग**: PyPI पैकेज परिवर्तनों की निगरानी के लिए Dependabot, Snyk, JFrog Xray, या Endor Labs को एकीकृत करें।
- **न्यूनतम विशेषाधिकार**: विकास और उत्पादन क्रेडेंशियल्स को मिलाने से बचें; समर्पित Secrets Managers (AWS Secrets Manager, HashiCorp Vault) का उपयोग करें।
- **एयर-गैप्ड इंस्टॉलेशन**: उच्च सुरक्षा वाले वातावरणों के लिए, सत्यापित GitHub स्रोत से निर्माण करें और हैश की जाँच करें।
- **निगरानी**: `.pth` फ़ाइल निर्माण, असामान्य फ़ॉर्क व्यवहार, और संदिग्ध डोमेन से बाहरी कनेक्शनों पर नज़र रखने के लिए EDR समाधान तैनात करें।

**किनारे के मामले**:
- CLI स्क्रिप्ट्स (`install.sh`) के माध्यम से अप्रत्यक्ष इंस्टॉलेशन भी सिस्टम को उजागर करता है।
- समझौता किए गए बेस इमेज पर आधारित Docker इमेज को पुनर्निर्माण करना होगा।
- वर्चुअल एन्वायरनमेंट (venv) अलग-थलग होते हैं, लेकिन वैश्विक Python इंस्टॉलेशन अभी भी सिस्टम प्रक्रियाओं को प्रभावित करते हैं।

## निष्कर्ष

LiteLLM आपूर्ति श्रृंखला हमला एक स्पष्ट अनुस्मारक के रूप में कार्य करता है कि ओपन-सोर्स इकोसिस्टम की सुविधा गंभीर सुरक्षा जोखिमों के साथ आती है। एक सुरक्षा स्कैनर को पहले समझौता करके, हमलावरों ने सटीक डाउनस्ट्रीम प्रभाव प्राप्त किया।

**अभी कार्रवाई करें**: प्रत्येक Python वातावरण में LiteLLM संस्करणों की जाँच करें, 1.82.6 पर डाउनग्रेड करें, और **संभावित रूप से उजागर सभी क्रेडेंशियल्स को तुरंत बदलें**। भविष्य की घटनाओं को रोकने के लिए सख्त निर्भरता समीक्षा प्रक्रियाएं स्थापित करें।

आधिकारिक LiteLLM GitHub और PyPI घोषणाओं के माध्यम से अपडेट रहें। 2026 और उसके बाद, नियमित निर्भरता ऑडिटिंग प्रत्येक AI डेवलपर के लिए एक आवश्यक कौशल है।

सतर्क रहें और आपूर्ति श्रृंखला की सुरक्षा करें — आज ही संस्करण पिनिंग से शुरुआत करें।