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

 (github.com/BerriAI)
2 पॉइंट द्वारा GN⁺ 2026-03-25 | 1 टिप्पणियां | 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 नहीं होते

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

1 टिप्पणियां

 
GN⁺ 2026-03-25
Hacker News की राय

  • मैं LiteLLM का maintainer हूँ। मौजूदा स्थिति की अभी जाँच चल रही है, लेकिन अब तक जो समझ में आया है, वह यह है

    1. लगता है कि समस्या CI/CD में इस्तेमाल हुए trivy से शुरू हुई (संबंधित खोज लिंक, विश्लेषण लेख)
    2. अगर आप proxy docker का उपयोग कर रहे हैं, तो उस पर असर नहीं है। क्योंकि requirements.txt में version pin किया गया था
    3. PyPI पर संबंधित package को quarantine कर दिया गया है, इसलिए download रोका गया है
      हम अभी root cause analysis और security hardening के उपायों की समीक्षा कर रहे हैं, और हुई असुविधा के लिए क्षमा चाहते हैं
    • प्रभावित versions (v1.82.7, v1.82.8) को PyPI से हटा दिया गया है। सभी maintainer accounts और keys (GitHub, Docker, CircleCI, pip) बदल दिए गए हैं। हम अभी भी पूरे project को scan कर रहे हैं, और security experts की मदद का स्वागत है (संपर्क: krrish@berri.ai)
    • किसी ने कहा कि मेरा निजी GitHub account भी शायद compromise हो गया है। search results में उससे जुड़े निशान दिखाई देते हैं
    • यह कहने के लिए धन्यवाद कि मेरा “माफ़ कीजिए” वाला बयान मानवीय लगा। औपचारिक माफ़ीनामे की जगह सच्चे मन से प्रतिक्रिया देना बेहतर है—ऐसी प्रतिक्रिया से हौसला मिलता है
    • एक सवाल था कि credential rotation तुरंत क्यों नहीं किया गया। लगता है, कम समय में इसे पहचान न पाने की वजह समझानी पड़ेगी
    • किसी ने अपने सिस्टम पर installed litellm version खोजने के लिए एक सरल script बनाकर साझा की (script link)। यह पूरी तरह परफेक्ट नहीं है, लेकिन conda, .venv, uv, और system environment को जल्दी scan कर सकती है

  • हम अब भी dependencies और development environment पर भरोसा नहीं कर सकते। dev containers में isolation कम है और usability भी सीमित है। अब sandbox-आधारित development environment की ओर जाना चाहिए। VM-level isolation, egress filters, seccomp, gVisor जैसी defense layers वाले environment की ज़रूरत है। ऐसे environment में compromise होने पर भी container तुरंत terminate हो जाएगा और समस्या पहचानना आसान होगा

    • लगता है कि पिछले 50 वर्षों की security shortcuts अब पलटकर हमारे सामने आ रही हैं। trust-आधारित development culture अब समाप्ति की ओर है। साधारण sandboxing से आगे बढ़कर security model का ही redesign चाहिए
    • अब “पहले की तरह” वाली बात नहीं चलेगी। cryptographically verifiable safety अब अनिवार्य है। Red Hat के DISA STIG की तरह external repositories के उपयोग पर रोक लगाने की दिशा में जाना होगा
    • credentials को containers से अलग रखने वाले मेरे project पर राय माँगी गई (tightbeam, airlock)
    • मैं smolvm नाम का एक open source project बना रहा हूँ (link)। यह VM-level isolation और container support को जोड़ने वाली तकनीक है, जिसका लक्ष्य पूरा virtual machine unit deployment है। साथ काम करने के लिए लोगों की तलाश है
    • हाल की supply-chain attacks में क्या वास्तव में dev container escape हुआ है, इस पर सवाल उठा

  • macOS के लिए बनाए गए canary tool का परिचय दिया गया (link)। यह एक सरल Go binary है, जो उन files को detect करती है जिन्हें package को access नहीं करना चाहिए। यह WebDAV या NFS के जरिए नकली secret data expose करती है और access होने पर alert भेजती है। honeypot approach से असामान्य गतिविधि पकड़ी जा सकती है

  • यह हाल के कुछ हफ्तों में हुई TeamPCP activity से जुड़ा मामला है। मेरे द्वारा तैयार की गई timeline उपयोगी हो सकती है

    • इसे शानदार summary बताया गया। हालांकि “playlist” प्रभावशाली थी—ऐसा मज़ाक भी किया गया
    • TeamPCP नाम कई जगह देखा था, लेकिन इस तरह एक नज़र में सजा हुआ विवरण पहली बार दिखा—ऐसी प्रतिक्रिया आई
    • updates को इतनी तेज़ी से कैसे बनाए रखते हैं, इस पर भी सवाल पूछा गया

  • GitHub का spam detection system बहुत कमज़ोर है—ऐसी टिप्पणी आई। कहा गया कि litellm issue पर 170 से अधिक spam comments आए

    • कुछ दिन पहले trivy repository में भी यही हुआ था। hacking से जुड़ी चर्चा बंद होते ही 700 से अधिक spam comments आ गए। कुछ accounts का वास्तविक activity history भी था। लगता है credential-stealing attacks काफ़ी व्यापक रूप से फैल चुके हैं। कई accounts में फरवरी में “Update workflow configuration” नाम के commit के जरिए CI में credential stealer डाले जाने के निशान मिले
    • GitHub पर spam report करने के लिए कई steps से गुजरना पड़ता है, इसलिए इसे inefficient कहा गया
    • कुछ लोगों ने यह भी कहा कि इनमें से कुछ केवल bot accounts हो सकते हैं

  • मुझे लगा था कि ऐसा कभी न कभी होगा। dependency version pinning से बचाव की कोशिश की गई थी, लेकिन वह भी पूरी तरह पर्याप्त नहीं है। open source की supply-chain complexity के कारण हर code को verify करना असंभव है। LLM की वजह से malicious code के बड़े पैमाने पर फैलने का जोखिम 100 गुना बढ़ गया है

    • एक राय थी कि Rust ecosystem में dependency tree बहुत गहरा होता है, इसलिए verification कठिन है। Rust, Node, Python—सभी इसी समस्या से जूझ रहे हैं। इसके विपरीत C/C++ system package managers का उपयोग करते हैं, इसलिए dependency जोड़ने की लागत अधिक होने से वे तुलनात्मक रूप से अधिक सुरक्षित हैं

  • अगर AI द्वारा लिखा गया code LLVM या Linux में घुसपैठ कर जाए, तो हम सचमुच “trusting trust” समस्या का सामना करेंगे

    • “Trusting Trust” समस्या का समाधान पहले ही Diverse Double-Compiling जैसे तरीके से प्रस्तावित किया जा चुका है। लेकिन supply-chain attacks अब भी कठिन चुनौती हैं। AI केवल attack scale बढ़ाने का tool है
    • अब सब कुछ असुरक्षित लगता है। शायद केवल airgap environments ही सुरक्षित हों। लेकिन अधिकांश data cloud में है, और हम उसके backups तक पर नियंत्रण नहीं रखते
    • deterministic build chains के जरिए पूरी तरह verifiable software बनाने की कोशिशें चल रही हैं। Debian के 93% packages reproducible builds हैं। लेकिन अब भी कई developers बिना झिझक “curl | bash” चला देते हैं। XZ backdoor incident ने इस वास्तविकता की याद दिलाई थी
    • एक राय यह भी थी कि LLM को kernel code सीखने से रोकने का एकमात्र तरीका internal APIs को बार-बार बदलना है
    • अगर ऐसा हमला वास्तविकता बनता है, तो government servers या cloud infrastructure को बड़े पैमाने पर नुकसान हो सकता है। खासकर अगर इसमें nation-state hacking जुड़ जाए, तो क्षति खरबों डॉलर तक पहुँच सकती है। फिर भी Linux अपेक्षाकृत सुरक्षित लगता है

  • यह उल्लेख किया गया कि LiteLLM की SOC2 audit firm Delve थी।

    • लेकिन यह सवाल बना रहा कि क्या SOC2 certification ऐसे हमले को रोक सकती थी। अनुभव साझा किए गए कि वास्तव में SOC2 कोई पूर्ण ढाल नहीं है

  • Harbor install करते ही CPU 100% पर चला गया और system रुक गया। grep -r rpcuser\rpcpassword process शायद cryptocurrency wallets खोजने की कोशिश कर रहा था। अच्छी बात यह रही कि backdoor install नहीं हुआ

    • किसी और ने कहा कि browser-use में भी उसे यही अनुभव हुआ। litellm dependency के रूप में install हुआ था और system रुक गया। उसने GitHub और HuggingFace tokens revoke कर दिए, लेकिन पूछा कि क्या OS reinstall ज़रूरी होगा
    • एक सवाल था, “आपने process को इतनी जल्दी कैसे पहचान लिया?” यह भी पूछा गया कि क्या Activity Monitor हमेशा खुला रखते हैं
    • “Harness क्या है?”—ऐसा सवाल भी आया

  • यह घटना Trivy को hack करने वाले TeamPCP के उसी attacker group का काम लगती है। issues में bot comments की बाढ़ आना भी उसी pattern का हिस्सा है। संभावना है कि यह LLM-आधारित automated attack हो

    • सवाल उठा कि attacker bot comments से issue को भर क्यों देते हैं। शायद इसका उद्देश्य अराजकता फैलाना और response में देरी करना है