LiteLLM सप्लाई चेन हमले पर मिनट-दर-मिनट प्रतिक्रिया रिकॉर्ड

 (futuresearch.ai)
3 पॉइंट द्वारा GN⁺ 2026-03-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PyPI के जरिए वितरित LiteLLM 1.82.8 malicious package के संक्रमण को रियल-टाइम में डिटेक्ट और विश्लेषित करने वाली मिनट-दर-मिनट प्रतिक्रिया डायरी
  • संक्रमण Cursor IDE auto update के दौरान हुआ, और litellm_init.pth फ़ाइल चलकर credentials theft और system infection का कारण बनी
  • malicious code ने SSH keys और cloud credentials collection, Kubernetes में फैलने की कोशिश, fork bomb बनाना जैसी कई तरह की गतिविधियाँ कीं
  • PyPI security team और LiteLLM maintainers को तुरंत रिपोर्ट किया गया, जिसके बाद package quarantine और CVE registration हुआ
  • Claude Code जैसे AI-आधारित code analysis tools ने हमले की पहचान में अहम भूमिका निभाई और AI ecosystem supply chain security को मज़बूत करने की ज़रूरत को उजागर किया

LiteLLM सप्लाई चेन हमले की प्रतिक्रिया का रिकॉर्ड

  • LiteLLM 1.82.8 version को PyPI के जरिए वितरित malicious package के रूप में पहचाना गया, और संक्रमण की पहचान से लेकर quarantine तक की प्रक्रिया को मिनट-दर-मिनट दर्ज किया गया
  • संक्रमण Cursor IDE के auto update process के दौरान हुआ, और Claude Code तथा uv package manager के जरिए इंस्टॉल की गई dependencies में मौजूद litellm_init.pth फ़ाइल के चलने से system infection हुआ
  • हमले में credentials theft, system persistence installation, Kubernetes propagation attempt, और fork bomb सहित कई तरह की गतिविधियाँ शामिल थीं
  • PyPI security team और LiteLLM maintainers को तुरंत रिपोर्ट किया गया, जिसके बाद package quarantine और CVE issuance हुआ
  • AI-आधारित code analysis tools ने रियल-टाइम malicious activity detection और analysis में मुख्य भूमिका निभाई

शुरुआती पहचान और सिस्टम असामान्यता के संकेत

  • 11:13 UTC के आसपास macOS laptop पर 11,000 से अधिक Python processes बन गए, जिससे सिस्टम लगभग ठप हो गया
    • exec(base64.b64decode('...')) जैसे command बार-बार चल रहे थे, जिससे CPU और memory पूरी तरह भर गए
    • force quit और reboot के बाद persistence से जुड़े निशान नहीं मिले
  • शुरुआत में इसे Claude Code के internal loop या uv run script error से पैदा हुई non-malicious loop phenomenon माना गया
  • बाद में htop screenshot और logs से यह पुष्टि हुई कि base64-encoded Python script बार-बार चल रही थी

संक्रमण के कारण की पहचान

  • 11:40 UTC के आसपास इंस्टॉल किए गए Python tools में litellm_init.pth फ़ाइल मिली, जिससे इसे malicious activity के रूप में पहचाना गया
    • .pth फ़ाइलें Python startup पर अपने-आप चलती हैं और हर Python process में काम करती हैं
    • यह SSH keys, cloud credentials, database passwords, environment variables, shell history आदि इकट्ठा करती थी
    • इकट्ठा किया गया डेटा RSA encryption के बाद https://models.litellm.cloud/ पर भेजा जाता था
    • ~/.config/sysmon/sysmon.py में persistence install करने की कोशिश की गई, लेकिन force reboot के कारण यह रुक गया
  • संक्रमण Cursor IDE के auto update (10:58 UTC) के दौरान हुआ
    • futuresearch-mcp-legacy extension ने uvx के जरिए litellm 1.82.8 डाउनलोड किया
    • यह version सिर्फ PyPI पर मौजूद था और GitHub release tag मौजूद नहीं था
    • PyPI upload time 10:52 UTC था, यानी संक्रमण से ठीक पहले इसे वितरित किया गया था

malicious code की संरचना

  • Stage 1 (litellm_init.pth): Python startup पर अपने-आप चलकर base64-encoded payload को decode कर execute करता है
  • Stage 2: इसमें RSA public key शामिल थी, जिसका उपयोग चोरी किए गए डेटा को encrypt करने में होता था
  • Stage 3 (B64_SCRIPT): असली credentials collection और transmission करता था
  • Persistence installation: sysmon.py को systemd service के रूप में register करने की कोशिश
  • Kubernetes propagation code: alpine:latest image का उपयोग कर हर node पर privileged pod बनाने की कोशिश
  • Fork bomb का कारण: subprocess.Popen([sys.executable, "-c", ...]) call ने child processes में भी .pth को फिर से चलाया, जिससे infinite loop बना

नुकसान का दायरा और प्रतिक्रिया कदम

  • उजागर हुए credentials

    • SSH keys, GCloud और Kubernetes authentication info, .env फ़ाइलों में API keys, Supabase·ClickHouse·Grafana passwords आदि
    • तुरंत सुझाए गए कदम
    1. सभी SSH और cloud credentials rotate करें
    2. .env और .mcp.json में मौजूद secret keys फिर से जारी करें
    3. ~/.cache/uv cache हटाएँ
    4. PyPI security team (security@pypi.org) और LiteLLM maintainers को रिपोर्ट करें

  • Kubernetes cluster inspection results

    • malicious pod (node-setup-*, sysmon) नहीं मिले
    • macOS environment में execution होने के कारण cluster के अंदर propagation असफल रहा
    • लेकिन ~/.kube/config के exposed होने की संभावना के कारण credentials rotation ज़रूरी है

PyPI और सार्वजनिक प्रतिक्रिया

  • 11:58 UTC पर Docker-isolated environment में PyPI से litellm 1.82.8 डाउनलोड कर malicious .pth फ़ाइल की मौजूदगी फिर से पुष्टि की गई
  • PyPI security team और BerriAI/litellm repository को तुरंत रिपोर्ट किया गया
    • बाद में इसे PYSEC-2026-2 (CVE) के रूप में दर्ज किया गया
  • 12:01 UTC पर FutureSearch blog में supply chain attack disclosure post लिखकर प्रकाशित किया गया
    • 3 मिनट के भीतर PR लिखकर merge भी कर दिया गया
  • 12:04 UTC पर r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning, r/devops communities में साझा करने का प्रस्ताव दिया गया
    • इससे Python और security communities में तेज़ प्रतिक्रिया को बढ़ावा मिला

इस घटना का महत्व

  • AI-आधारित code analysis tool Claude Code ने रियल-टाइम में malicious activity की पहचान की और security researcher के हस्तक्षेप से पहले ही warning बनाई
  • यह supply chain attack का ऐसा मामला था जिसने AI developer ecosystem को सीधे निशाना बनाया, और PyPI account security तथा auto update verification को मज़बूत करने की ज़रूरत को रेखांकित किया
  • यह दिखाता है कि AI tools सिर्फ development assistance तक सीमित नहीं हैं, बल्कि cyber threat detection और response automation में भी उपयोग किए जा सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2026-03-28
Hacker News की टिप्पणियाँ

  • मैं वही डेवलपर हूँ जिसने सबसे पहले litellm vulnerability खोजी और रिपोर्ट की थी
    मैंने उस समय की स्थिति का ठीक-ठीक रिकॉर्ड किया हुआ real-time analysis transcript साझा किया था
    Claude ने किससे संपर्क करना है और किस क्रम में कार्रवाई करनी है, यह step-by-step बताया, इसलिए यह non-security experts के लिए भी बहुत मददगार अनुभव था
    मैं जानना चाहता हूँ कि क्या इस तरह non-experts का vulnerabilities ढूँढना और रिपोर्ट करना security community के लिए मददगार है, या इससे उलझन पैदा होती है

    • security industry में काम करने वाले व्यक्ति के तौर पर, Claude की मदद से यह ढूँढ लेना प्रभावशाली लगा
      लेकिन “Cursor दोबारा खोलते ही malicious package चल पड़ा” वाला हिस्सा थोड़ा खतरनाक लगता है
      शक होते ही सबसे पहले device isolation और security team से संपर्क होना चाहिए था
    • मैंने भी लगभग उसी समय, लगभग उसी तरीके से यह समस्या खोजी थी
      अगर .pth फ़ाइल fork bomb की तरह काम न करती, तो शायद यह बहुत देर से पकड़ में आती
      Claude से संपर्क के रास्ते पूछना अच्छा फ़ैसला था
      मुझे PyPI के संबंधित संपर्क नहीं पता थे, इसलिए मैंने maintainer को मेल भेजा और Hacker News पर भी पोस्ट किया
      मेरा मानना है कि security community का हिस्सा न होने पर भी, ऐसी गंभीर vulnerability report कोई भी कर सके यह संभव होना चाहिए
    • मुझे कई कंपनियों में vulnerability disclosure programs मैनेज करने का अनुभव है
      ज़्यादातर समस्याएँ उन लोगों की वजह से आती हैं जो पैसे के लिए किसी भी चीज़ को vulnerability बताने लगते हैं
      लेकिन आपकी report की quality बहुत अच्छी थी, और ऐसी चीज़ों को हम सीधे patch priority में ऊपर रखते हैं
      अगर business disruption के बिना हल हो सकता, तो तुरंत कार्रवाई करते, और अगर बहुत गंभीर होता तो सीधे CISO या CTO को रिपोर्ट करते
    • पोस्ट अच्छी लगी. मुझे लगा कि Claude ऐसी स्थिति में खास तौर पर उपयोगी है
      आपकी report की वजह से बड़ी घटना टल गई
      हमने भी इससे जुड़ी बातों को दो हिस्सों में ब्लॉग पर संकलित किया है
      grith.ai ब्लॉग पोस्ट
    • हाल में सुना है कि open source projects vulnerability reports और PR की बाढ़ से जूझ रहे हैं
      लेकिन मुझे लगता है कि यह मामला एक अच्छा उदाहरण है कि AI की मदद से root cause analysis और reporting कितनी तेज़ हो सकती है

  • मेरे claude-code-transcripts टूल को ब्लॉग पोस्ट में data के रूप में embed किया गया है, यह मैंने पहली बार देखा
    मैं आम तौर पर इसे Gist की HTML page के रूप में साझा करता था, इसलिए यह उपयोग दिलचस्प लगा

    • हमारी कंपनी में भी इसका सक्रिय उपयोग हो रहा है
      ब्लॉग स्टाइल के हिसाब से ढालने की कोशिश की, लेकिन सफल नहीं हुए, और इससे फिर महसूस हुआ कि base experience कितना महत्वपूर्ण है
      Claude मेरे पूरे कंप्यूटर को scan करने जैसा logs इकट्ठा कर लेता है, इसलिए लगा कि automatic log redaction system की ज़रूरत है
    • Claude Code sessions के बीच जानकारी साझा करना अब भी एक बड़ी समस्या है
      emergency debugging के दौरान टीम के साथ collaboration में यह खास तौर पर असुविधाजनक है

  • “क्या malicious script की सामग्री को चलाए बिना output किया जा सकता है?” जैसी requests जोखिमभरी हैं
    LLM agents में जिम्मेदारी की अवधारणा नहीं होती, इसलिए गलती से execution command दे दी जाए तो बड़ा हादसा हो सकता है
    PyPI से फ़ाइलें लेते समय हमेशा sandbox environment का इस्तेमाल करना चाहिए

    • मुझे भी यही चिंता थी
      “मत करो” कहा जाए तो उल्टा उसी चीज़ पर अटक जाने की प्रवृत्ति होती है

  • सुना है कि PyPI “digital attestation” को support करता है, तो जानना चाहता हूँ कि क्या यह package signed था
    PyPI Trusted Publishers दस्तावेज़

  • मेरा मानना है कि GitHub, npm, PyPI जैसे package registries को real-time security analysis के लिए event stream (firehose) उपलब्ध करानी चाहिए
    ऐसे attacks को automated scanners तुरंत पकड़ सकते थे

    • PyPI पहले से ऐसी सुविधा दे रहा है
      security partners packages को scan कर सकते हैं, और invite-based API के ज़रिए report कर सकते हैं
      PyPI ब्लॉग पोस्ट देखें
    • मैंने भी इस घटना के बाद dependency cooldown लागू किया है
      संबंधित लेख
      इसका उद्देश्य automated scanners को .pth फ़ाइल जैसी anomalies पकड़ने का समय देना है
    • npm package change feed देता है, और GitHub event firehose तथा BigQuery public dataset चलाता है
    • मुझे लगता है कि ऐसी infrastructure provision को कानूनी दायित्व बनाया जाना चाहिए
      आर्थिक नुकसान बहुत बड़ा हो सकता है, और सिर्फ litellm infection के शिकार लोगों की संख्या ही 47,000 से अधिक है

  • “ब्लॉग पोस्ट लिखना, PR, और merge तक 3 मिनट से कम” वाला हिस्सा सबसे चौंकाने वाला था
    यह पढ़ने में लगने वाले समय से भी तेज़ है, इसलिए बेचैनी होती है

  • अगर 11,000 processes वाला fork bomb न होता, तो शायद यह attack बहुत लंबे समय तक छिपा रहता

    • मैं भी package install करते समय तुरंत system freeze होने की वजह से infection से बच गया
      अगर bomb की speed धीमी होती, तो नुकसान बहुत बड़ा हो सकता था
    • शायद इसे इस पीढ़ी का internet worm कहना चाहिए

  • बड़ी कंपनियाँ untrusted open source code चलाने के दो तरीके अपनाती हैं

    1. Google की तरह सब कुछ source से सीधे build करना
    2. सिर्फ company-internal mirror से लेना और सभी packages की signature verification करना
      व्यवहारिक रूप से (1) सबसे सुरक्षित है
      छोटे-मध्यम व्यवसायों या व्यक्तिगत उपयोगकर्ताओं के लिए dependency pinning और पर्याप्त waiting time सबसे अच्छा बचाव है
      Bazel का उपयोग करें तो (1) के काफ़ी करीब पहुँचा जा सकता है, लेकिन ज़्यादातर लोग बाहरी sources पर निर्भर रहने को मजबूर हैं

  • report के 30 मिनट के भीतर PyPI का package quarantine करना सचमुच बहुत तेज़ response था

    • supply chain attacks के प्रति इसकी कमजोरी को लेकर बहुत चिंता रहती है, लेकिन इस बार यह काफ़ी अच्छी तरह संभाला गया मामला लगा

  • AI/LLM की सबसे अच्छी बातों में से एक है reverse engineering का लोकतंत्रीकरण
    पहले यह सीखना मुश्किल और कम rewarding skill थी, लेकिन अब AI दिशा दिखा देता है

    • लेकिन यह मामला reverse engineering नहीं बल्कि basic system administration issue है
      exec(base64.b64decode(...)) pattern Python tools में code delivery के लिए अक्सर इस्तेमाल होता है, लेकिन
      मूल रूप से /tmp या /var/tmp, /dev/shm से चलने वाला code बहुत संदिग्ध माना जाना चाहिए
      अगर Lulu या LittleSnitch जैसे network monitoring tools होते, तो abnormal traffic को रोका जा सकता था
      हालांकि Claude पर binaries upload करके analysis करवाना अपने आप में एक अलग जोखिम है
    • CTF videos देखकर मेरी भी दिलचस्पी जगी थी, लेकिन वास्तविक कामकाज में ऐसी चीज़ों का सीधे सामना करना बहुत कम होता है