LiteLLM 1.82.7 और 1.82.8 PyPI पैकेज समझौता घटना

 (github.com/BerriAI)
2 पॉइंट द्वारा GN⁺ 2026-03-25 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • व्यापक रूप से इस्तेमाल होने वाली LLM इंटीग्रेशन लाइब्रेरी LiteLLM के PyPI पैकेज के दो वर्ज़न (1.82.7, 1.82.8) में malicious payload डाला गया और वितरित किया गया, जिससे इंस्टॉल करते समय सिस्टम credentials चोरी करने वाला हमला हुआ
  • हमले की जड़ CI/CD security scanning tool Trivy की supply chain compromise में थी, जिससे CircleCI credentials लीक हुए और PyPI publish token तथा GitHub PAT चोरी हो गए
  • आधिकारिक LiteLLM Proxy Docker image उपयोगकर्ताओं पर असर नहीं पड़ा क्योंकि requirements.txt में वर्ज़न pin किए गए थे, लेकिन PyPI से सीधे pip install करने वाले environments को तुरंत जांचने की ज़रूरत है
  • GitHub issue thread में सैकड़ों bot spam comments आए, जिससे वास्तविक चर्चा बाधित हुई; पुष्टि हुई कि हमलावर ने जानबूझकर response communication को बाधित किया
  • DSPy, CrewAI जैसे LiteLLM पर dependency रखने वाले कई projects पर भी असर पड़ा, जिससे software supply chain security की बुनियादी कमजोरी फिर उजागर हुई

घटना का सार और खोज का क्रम

  • नया project सेट करते समय सिस्टम असामान्य व्यवहार करने लगा, RAM खत्म हो रही थी और forkbomb जैसे processes चल रहे थे
  • जांच में पता चला कि proxy_server.py में base64-encoded malicious blob जोड़ा गया था, जिसे decode करके अलग फ़ाइल बनाई जाती थी और फिर चलाया जाता था
  • वर्ज़न 1.82.7 में payload litellm/proxy/proxy_server.py में शामिल था और import litellm.proxy पर execute होता था
  • वर्ज़न 1.82.8 में अतिरिक्त litellm_init.pth फ़ाइल भी शामिल थी, जिससे केवल पैकेज इंस्टॉल होने पर ही Python startup के समय malware अपने-आप execute हो जाता था
    • .pth फ़ाइल Python के site module का startup mechanism है, जिसमें import keyword के बाद arbitrary code execute किया जा सकता है
    • यह mechanism Python 2.1 से मौजूद है और बिना अलग PEP के लाया गया था
  • FutureSearch टीम ने पहली बार नुकसान की रिपोर्ट की: uvx ने अपने-आप latest litellm (बिना version pinning) इंस्टॉल किया, फिर Cursor ने local MCP server auto-load किया और infection हो गया

हमले का रास्ता और TeamPCP संबंध

  • पुष्टि हुई कि यह हमला हाल में Trivy को compromise करने वाले TeamPCP समूह ने ही किया
  • compromise path: Trivy hack → CircleCI credentials का पूरा leakage → PyPI publish token + GitHub PAT की चोरी → malicious package distribution
  • LiteLLM CEO/CTO के GitHub accounts भी पूरी तरह compromise हो गए; उनके personal repositories के descriptions को "teampcp owns BerriAI" में बदला गया और issues बंद किए गए
  • PYPI_PUBLISH token GitHub project के environment variable के रूप में रखा गया था, और वही Trivy के ज़रिए लीक हुआ
    • account पर 2FA enabled था, लेकिन token चोरी हो जाने से उसे bypass कर लिया गया
  • हमलावरों ने GitHub issues में सैकड़ों bot accounts से एक जैसी पंक्तियाँ बार-बार पोस्ट कीं, जिससे सार्थक चर्चा बाधित हुई
    • Trivy repository में भी इसी पैटर्न के 700 से अधिक spam comments मिले
    • कुछ spam accounts असली GitHub users थे जिनका योगदान इतिहास था; फरवरी से "Update workflow configuration" commits के जरिए CI workflows में credential stealer डाला गया होने के संकेत मिले
  • Trivy compromise कम-से-कम 5 दिन पहले हो चुका था, और latest attack advisory ठीक पिछ्ले दिन आई थी, इसलिए संभव है maintainers को जानकारी ही न रही हो
  • हमलावरों ने payload delivery के लिए Internet Computer Protocol(ICP) Canisters का भी उपयोग किया, इसलिए केवल DNS blocking से बचाव संभव नहीं

malicious payload कैसे काम करता है

  • यह background Python process बनाता है और embedded stages को decode कर चलाता है
  • credential collector चलता है, और data collection सफल होने पर attacker की RSA public key से AES key encrypt करके चुराया गया data remote host पर भेजता है
  • malware में मिले URLs: checkmarx.zone/raw और models.litellm.cloud
  • मुख्य लक्ष्य ~/.git-credentials में मौजूद SSH keys और crypto wallet information थी
  • CPU-intensive काम के कारण सिस्टम overload हो जाता था, जिससे इसे पहचानना आसान हुआ; कुछ मामलों में fan noise से असामान्यता पकड़ी गई
  • Harbor इंस्टॉल के दौरान भी यही लक्षण दिखे: grep -r rpcuser\rpcpassword process forkbomb की तरह चलकर crypto wallet खोजने की कोशिश कर रहा था

LiteLLM टीम की प्रतिक्रिया

  • प्रभावित वर्ज़न (v1.82.7, v1.82.8) PyPI से हटा दिए गए
  • सभी maintainer accounts के password बदले गए, और GitHub/Docker/CircleCI/pip की सभी keys हटाकर बदली गईं
  • नए maintainer accounts @krrish-berri-2 और @ishaan-berri कर दिए गए
  • PyPI पर पूरे पैकेज को अस्थायी रूप से quarantine किया गया था, फिर संक्रमित वर्ज़न हटाने के बाद बहाल किया गया
  • सभी नए releases रोक दिए गए और पूरी supply chain review पूरी होने तक distribution freeze किया गया
  • Google की Mandiant security team के साथ मिलकर जांच और recovery जारी है
  • Trivy को अंतिम safe version v0.35.0 पर pin किया गया (शुरुआती v0.69.3 pinning को community feedback के बाद बदला गया)
  • आगे Trusted Publishing (JWT token-based OIDC) अपनाने और अलग PyPI account इस्तेमाल करने जैसे security hardening उपायों पर विचार हो रहा है
  • malicious versions का पहला publish time लगभग UTC 8:30 था, जबकि PyPI quarantine लगभग UTC 11:25 पर हुआ

असर का दायरा और downstream projects

  • LiteLLM, DSPy के लिए LLM provider calls की एकमात्र लाइब्रेरी है, और CrewAI भी इसे fallback के रूप में इस्तेमाल करता है
  • Airflow, Dagster, Unsloth.ai, Polar, nanobot भी LiteLLM पर निर्भर हैं
  • GitHub search के अनुसार requirements.txt में LiteLLM को बिना version pinning शामिल करने वाले 628 से अधिक projects मिले
  • आधिकारिक Proxy Docker distribution path वाले users प्रभावित नहीं हुए क्योंकि requirements.txt में version pinning थी
  • Docker deployment में host filesystem और environment variables तक पहुंच सीमित होने से यह अपेक्षाकृत सुरक्षित था, लेकिन mounted credentials अब भी जोखिम में थे
    • हमलावर का मुख्य लक्ष्य personal SSH keys था; LLM keys तक पहुंच द्वितीयक थी
  • Harbor, browser-use जैसे tools, जो dependency के रूप में LiteLLM को auto-install करते हैं, उनके users ने भी indirect damage की रिपोर्ट की
  • CrewAI ने litellm को 1.82.6 (अंतिम safe version) पर pin किया, लेकिन commit message में compromise का ज़िक्र नहीं था
  • DSPy ने सार्वजनिक रूप से issue बनाकर response शुरू किया
  • LangChain का अपना LLM provider calling layer है, इसलिए इस supply chain compromise से सीधे प्रभावित नहीं हुआ (वैकल्पिक langchain-litellm पैकेज के उपयोग को छोड़कर)

community चर्चा: supply chain security और sandboxing

  • dependencies और development environments को अब भरोसेमंद नहीं माना जा सकता, इसलिए VM isolation + container primitives + allowlist + egress filters + seccomp + gVisor जैसी defense in depth की ज़रूरत है
  • पिछले 50 वर्षों की security convenience अब उलट रही है, और पूरे security model के redesign की ज़रूरत बताई जा रही है
  • programming language स्तर पर per-module sandboxing की मांग भी उठी
    • Java में 1990s के v1.2 से यह सुविधा थी, लेकिन usability समस्याओं के कारण छोड़ दी गई
    • कुछ लोगों ने कहा कि capability-based languages विकसित करने का यह सही समय है
    • Cloudflare का workerd runtime एक मौजूदा समाधान के रूप में उल्लेखित हुआ, जिसमें module isolation संभव है
  • OS-level isolation tools पहले से मौजूद हैं, जैसे OpenBSD का pledge/unveil, Linux का chroot/namespace/cgroup, और FreeBSD का Capsicum
  • Guix कुछ ही सेकंड में isolated container बना सकता है, जिससे $HOME तक पहुंच दिए बिना dependencies इंस्टॉल की जा सकती हैं
  • Firejail और bwrap जैसे user-space isolation tools के सक्रिय उपयोग की ज़रूरत बताई गई
  • mobile apps में sandboxing + permission model (Intents) पहले से मौजूद है, लेकिन desktop environments में सामान्य computation limits के प्रति कड़ा विरोध है
    • इसके जवाब में कहा गया कि Apple/Meta जैसे app store की बंद प्रकृति और security sandboxing अलग मुद्दे हैं; उपयोगकर्ता को नियंत्रण देते हुए भी सुरक्षा देने वाले tools बनाए जा सकते हैं
  • macOS के लिए canary/honeypot tool जारी किया गया (github.com/dweinstein/canary): नकली secrets को WebDAV/NFS पर mount करके असामान्य access detect किया जा सकता है
  • यह राय भी सामने आई कि package publishing और public repositories के बीच दीवार होनी चाहिए: public repositories को सीधे Trusted Publisher बनाने से attack surface बढ़ता है
    • जवाब में कहा गया कि Trusted Publishing का मूल उद्देश्य source और published artifact के बीच auditable link देना है, इसलिए private repository के रास्ते जाना पीछे हटना होगा

व्यावहारिक security सिफारिशें

  • dependencies को SHA256 checksums के साथ version pin करना अनिवार्य है
  • latest versions को सीधे अपनाने से बचने के लिए internal package mirrors चलाने चाहिए
  • build artifacts का उपयोग करें और uv run जैसी on-the-fly install आधारित deployment पर निर्भर न रहें
    • इससे PyPI outage होने पर सिस्टम रुकने का संरचनात्मक जोखिम भी कम होता है
    • deployable artifacts के फायदे: auditability, तेज rollback, और outbound network के जोखिमपूर्ण endpoints को block करना
  • uv की exclude-newer setting से एक निश्चित अवधि के भीतर आए नए packages को exclude किया जा सकता है
    • pyproject.toml में [tool.uv] exclude-newer = "5 days" सेट किया जा सकता है
  • CI/CD में publish tokens के बजाय OIDC-based workflows अपनाकर token को ही हटाना मूल समाधान है
    • GitHub और PyPI दोनों OIDC support करते हैं: अगर केवल publish job को OIDC endpoint access दें, तो Trivy job से चुराने लायक token रहेगा ही नहीं
  • Trivy जैसे security scanning tools को अलग workers पर चलाना चाहिए, जिनके पास publish permissions न हों
  • lockfile management और साप्ताहिक updates के ज़रिए latest version को तुरंत अपनाने से बचना चाहिए
  • Python की .pth files automatic code execution सक्षम करती हैं; -S option से site import रोका जा सकता है, लेकिन compatibility issues हो सकते हैं
  • osv-scanner जैसे tools से पूरे project dependency scan की सिफारिश की गई
  • infection जांचने के commands:
    • find / -name "litellm_init.pth" -type f 2>/dev/null
    • find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
  • package manager ecosystem भर में credential rotation की ज़रूरत भी उठाई गई

SOC2 audit और विश्वसनीयता का सवाल

  • यह भी इंगित किया गया कि LiteLLM का SOC2 audit vendor हाल में विवादों में रहा Delve था
  • SOC2 केवल यह देखता है कि "documented process का वास्तव में पालन हो रहा है या नहीं", यह security level की गारंटी नहीं देता
  • उचित SOC2 होने पर भी इस supply chain attack को रोका जा सकता था या नहीं, यह अनिश्चित है

LiteLLM के विकल्प projects

  • Bifrost (github.com/maximhq/bifrost): Rust-आधारित विकल्प, free open source instances में भी virtual keys सेट की जा सकती हैं
  • Portkey (portkey.ai): proxy service, free plan उपलब्ध, और कुछ के अनुसार LiteLLM से तेज
  • pydantic-ai: Python-आधारित विकल्प
  • any-llm (github.com/mozilla-ai/any-llm): Mozilla project
  • LLM Gateway (llmgateway.io): LiteLLM migration guide देता है
  • InferXgate (github.com/jasmedia/InferXgate): नया project, supported providers सीमित
  • कुछ developers का कहना था कि LLM provider APIs व्यवहार में केवल OpenAI और Anthropic के दो प्रकार हैं, इसलिए सीधे requests.post() से call करना अधिक सुरक्षित हो सकता है
    • जवाब में कहा गया कि Anthropic की OpenAI-compatible API को long-term/production solution के रूप में recommend नहीं किया जाता, और vendor-specific native APIs में ऐसे unique features होते हैं जो OpenAI API पर map नहीं होते

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.