लेखक: 
Updated: 27 October 2026. Indian Computer Emergency Response Team (CERT-In) ने 23 October 2026 को CIAD-2026-0053 advisory जारी की। विषय है LiteLLM version 1.107.0 का reportedly compromised PyPI release और related Docker images का targeted software supply-chain compromise। LiteLLM Python SDK और AI API gateway/proxy के माध्यम से organisations कई LLM providers की services integrate करती हैं। अगर compromised package किसी privileged developer workstation, CI runner या production environment में execute हुआ, तो उस environment में उपलब्ध cloud credentials, repository secrets तथा upstream AI API keys जोखिम में आ सकती हैं।
Quick action: पहले dependency manifests, build logs, container digests और running workloads से exposure confirm करें; suspicious environment isolate और forensic evidence preserve करें; clean build environment से affected deployments rebuild करें; संभावित रूप से accessible secrets revoke/rotate करें तथा access logs monitor करें। March 2026 के LiteLLM 1.82.7/1.82.8 incident को October 1.107.0 advisory के साथ confuse न करें। CERT-In की language ‘reportedly’ है—installed version देखे बिना हर LiteLLM system compromised घोषित नहीं करना चाहिए।
CERT-In CIAD-2026-0053 का summary और audience
CERT-In भारत की national cyber incident response agency है। उसकी 23 October 2026 advisory software developers, DevOps/SRE teams, cloud administrators, CI/CD maintainers और security operation centres के लिए है। उसमें LiteLLM PyPI package और associated GHCR/Docker Hub images से जुड़ी reportedly targeted compromise story दी गई है। Incident के दो प्रमुख concern credential theft और remote code execution हैं।
LiteLLM खुद एक AI integration utility है; इसका उपयोग होने मात्र से attack सिद्ध नहीं होता। जांच का focus installed artifact, resolved dependency version, build timestamp, image origin और deployment permissions पर होना चाहिए। Application में “AI” लिखा होना अलग matter है; actual exposure तभी assessed हो सकता है जब compromised library या image environment में पहुँची हो।
LiteLLM क्या करता है और supply-chain risk क्यों बड़ा है
LiteLLM कई LLM API providers को एक shared interface या proxy layer से access करने की सुविधा देता है। इसका अर्थ backend services को API routing, authentication, spend tracking और provider switching के लिए SDK या gateway मिल सकता है। इसी कारण proxy service के पास कभी-कभी अनेक upstream AI providers के access tokens, database connections तथा cloud services के configuration secrets भी होते हैं।
यदि dependency publish channel compromised हो जाए और developer ordinary package update समझकर malicious code install कर दे, तो application logic सुरक्षित होने के बावजूद running environment खतरे में पड़ सकता है। यह supply-chain compromise है: भरोसेमंद दिखने वाले upstream component के जरिए downstream consumers प्रभावित होने की आशंका। Open-source होना malicious release के विरुद्ध automatic protection नहीं देता; reproducible builds और verified provenance जरूरी हैं।
October 2026 में कौन-सा version और artifacts प्रभावित बताए गए
CERT-In specifically LiteLLM 1.107.0 PyPI release की बात करती है। Advisory में इसके अलावा GHCR और Docker Hub पर reportedly compromised images का भी उल्लेख है। इसलिए जांच केवल pip list के installed version तक सीमित नहीं रखनी चाहिए; अगर team image tags से production containers deploy करती है तो actual image digest, pull history और build pipeline को भी check करना होगा।
किस exact image digest का malicious status है, यह official current advisory, provider registries तथा published incident analysis से determine करें। केवल tag string देखकर सभी image repositories को infected कह देना सही नहीं। यदि कोई server LiteLLM use नहीं करता, तो unrelated system को “confirmed compromised” घोषित न करें। Version-digest inventory सबसे पहले बने।
March 1.82.7/1.82.8 incident से स्पष्ट अंतर
March 24, 2026 को LiteLLM के 1.82.7 और 1.82.8 PyPI builds backdoored होने का अलग public incident सामने आया था। उस समय LiteLLM project की security update में compromised PyPI versions और March CI/CD issue का disclosure था। Project ने बाद में v1.83.0 को clean pipeline के जरिए release किया था। उस incident में official LiteLLM Proxy Docker images उस specific PyPI path के वजह से प्रभावित न होने की बात project ने कही थी।
लेकिन October 23 CERT-In advisory का affected version 1.107.0 है और उसमें Docker images भी investigate करने की बात है। इसलिए March 2026 का “official Docker image impacted नहीं था” statement October 2026 की all-clear guarantee नहीं है। Security response को incident-specific रखें; पुरानी advisory screenshot से नई report को dismiss करना unsafe हो सकता है।
Compromise की reported delivery chain क्या थी
CERT-In के अनुसार reported incident analysis में Berri-AI/litellm नाम का lookalike GitHub repository और release workflow misuse होने की बात सामने आती है। Attacker reportedly build configuration pyproject.toml बदलकर malicious files package artifacts में पहुँचा सका। यह case दिखाता है कि repository name में छोटी spelling variation और release pipeline trust boundary कितनी महत्वपूर्ण है।
हम यहाँ exploit दोहराने की instructions नहीं दे रहे हैं। Defender के लिए lesson है कि GitHub organisation identity, build-signing, publish permissions, protected release workflow, package checksum तथा repository origin verify करें। Branch/tag का नाम genuine दिखना provenance का independent proof नहीं। CI/CD में long-lived broad publisher tokens कम से कम permissions तक सीमित रखें।
Python startup hooks: import किए बिना risk कैसे हो सकता है
Advisory में cook.pth, cook.py और sitecustomize.py नाम की reportedly injected files का वर्णन है। Python interpreter के startup-related processing mechanisms के कारण malicious functionality सामान्य execution में initiate हो सकती है, भले application explicitly LiteLLM import न करे। यह distinction खतरे को गंभीर बनाता है क्योंकि dependency environment-wide Python processes के साथ shared हो सकती है।
Investigation में affected virtual environment/site-packages inventory, suspicious startup files और running process lineage देखना उपयोगी है। किसी production environment में हर existing sitecustomize.py file को malicious मान लेना भी गलत होगा—legitimate customisations exist करती हैं। Trusted baseline से checksum, creation date तथा owner changes compare करके incident responder decision ले।
Credential-stealing component की reported पहुंच
CERT-In ने reportedly privcollect credential stealing component का उल्लेख किया है। उसका target surface browser sessions/cookies, SSH और GPG private keys, cloud tokens, CI/CD secrets, environment variables, source repository credentials तथा AI developer-tool tokens तक जा सकता है। LiteLLM proxy environment में database access available हो तो upstream model provider keys या proxy-managed credentials भी risk में आ सकते हैं।
हर compromised host से यही सभी secrets चुराए गए, ऐसा कहने के लिए forensic evidence जरूरी है। लेकिन incident response में conservative assumption useful हो सकती है: process को कौन-से identities, scopes और environment variables access थे? उनके owners से revoke/rotate decision करवाएँ। Password change contaminated host से करने के बजाय trusted device/environment उपयोग करें।
Remote code execution और persistence के indicators
CERT-In description में reportedly sitecustomize.py component एक process initiate कर सकता है जो GitHub-hosted dead-drop style location से additional code retrieve करने की कोशिश करता है। Advisory suspicious outbound connections, unexpected GitHub-hosted content requests और paths containing /codepy review करने को कहती है। इससे security team network telemetry और endpoint events की correlation कर सकती है।
किसी outbound GitHub request को अकेले malicious evidence न मानें: सामान्य development workflow में GitHub traffic होता है। संदिग्ध process origin, time, installed package version, domain, URL और activity pattern साथ verify करें। Arbitrary additional code की संभावना होने पर standard malware scan alone complete assurance नहीं देता; privileged affected hosts में rebuild और scoped credentials rotation आवश्यक हो सकती है।
एक practical exposure matrix कैसे बनाएँ
IT administrator Excel या ticket system में चार columns से शुरू कर सकता है: asset, LiteLLM version/image digest, exposure evidence और access privilege। Example: Developer A workstation ने 23 October को LiteLLM 1.107.0 install किया हो और cloud-admin token environment में था, तो investigation high priority है। दूसरी machine ने verified separate version use किया और उसी affected registry से कोई artifact pull नहीं हुआ, तो evidence के आधार पर exposure अलग हो सकती है।
ये hypothetical scenarios हैं; किसी actual Nexeons, WordPress या n8n server पर LiteLLM installed होने का दावा नहीं है। Vulnerability scanner का version finding start है; build history, runtime artefact तथा secrets’ reach confirm करनी होती है। Sharing report में individual secret values कभी paste न करें।
Inventory step 1: Python dependency versions कैसे देखें
Development teams requirements.txt, poetry.lock, uv.lock, Pipfile.lock, pyproject.toml और installed package metadata inspect कर सकती हैं। python -m pip show litellm जैसा read-only command current Python environment में installed version समझने में मदद करता है। लेकिन workstation में कई virtual environments, containers और build caches हो सकते हैं; सिर्फ default terminal के Python interpreter की output definitive complete inventory नहीं है।
Dependency lock में direct या transitive LiteLLM reference हो सकता है। Internal build artifacts में older wheels cached रह सकते हैं। इसलिए SBOM और package artifact hashes maintain करें। Code changes या package uninstall करने से पहले affected machine के relevant logs और artifact evidence preserve करना forensic chain में मदद करता है।
Inventory step 2: Docker image digest और registries
Container tag mutable हो सकता है: आज वही tag किसी दूसरे digest को refer करे। इसलिए actual deployed image digest, container registry repository, pull timestamp, cached layers और CI build definition verify करें। यदि GHCR अथवा Docker Hub से affected images use होने का शक है तो image metadata तथा current CERT-In/maintainer incident note की comparison जरूरी है।
Production workloads में reckless “latest” tag reinstall करने से repeat exposure या incompatibility हो सकती है। Verified clean image digest pin करें, security acceptance testing करें और immutable provenance record रखें। Registry cleanup के दौरान forensic copy और reproducible rollback plan बनाएँ। Avoid creating new deployed copies from contaminated build cache।
Containment step: कौन-से systems isolate करें
CERT-In immediate containment में suspicious hosts और containers को isolate करने की सलाह देती है, साथ में relevant logs तथा evidence preservation भी जरूरी बताती है। यदि compromised builder shared signing credentials use करता था तो downstream deployment environment भी investigate करना होगा। Containment का exact स्तर business impact, access rights और incident command decision पर निर्भर है।
उदाहरण: Public-facing API gateway potentially tainted है तो service traffic clean failover तक reroute करने की जरूरत हो सकती है। लेकिन confirmed evidence बिना पूरे corporate network बंद करना जरूरी नहीं। Security incident owner risk assessment, recovery-point objectives तथा business continuity को balance करे। किसी public user को panic कराने की जगह clear status और relevant services’ factual impact बताएं।
Malicious files और processes की investigation
Advisory specifically cook.pth, cook.py, modified/unexpected sitecustomize.py, suspicious process tree, marker files तथा network egress check करने की बात करती है। Defender relevant endpoint telemetry, filesystem metadata और CI logs retain करे। Dangerous files को forensic image के बिना जल्दी delete कर देने से initial access का time और potential exfiltration investigation कठिन हो सकता है।
अगर infection suspect हो तो trusted incident-response specialist के supervision में evidence capture करके host quarantine करें। Production machine पर random internet “fix scripts” चलाना risky है क्योंकि script authentic है या नहीं जाँचना जरूरी है। Clean media से rebuild और secrets rotation, superficial process kill से अधिक भरोसेमंद recovery दे सकते हैं।
Verified clean version: 1.106.2 वाली सलाह का अर्थ
October CERT-In guidance reportedly supplied analysis में LiteLLM 1.106.2 को clean reference version बताती है, साथ में स्पष्ट सलाह देती है कि pin करने से पहले उसकी integrity और suitability independently verify करें। इसे universal instruction “हर organisation तुरंत 1.106.2 ही install करे” न कहें; software compatibility, subsequent verified releases और upstream official signatures check करना जरूरी है।
Version selection में approved package source, hashes/checksums, reproducible build, code-review signoff और staging tests रखें। यदि affected container deploy हुआ हो तो in-place pip downgrade alone sufficient remediation नहीं, क्योंकि malicious startup files या process persistence बच सकती है। Trusted clean base image तथा new environment deploy करना preferred approach हो सकता है।
Mandatory credential rotation की priority कैसे तय करें
CERT-In advisory credentials revoke/rotate करने को कहती है: cloud provider access tokens, SSH/GPG keys, browser sessions/passwords, source code repository credentials, CI/CD secrets, development-tool tokens तथा upstream LLM provider API keys। LiteLLM proxy operators के लिए master_key और salt_key recovery procedures का भी उल्लेख है। Key rotation order dependencies पर निर्भर है—पहले containment और access preservation, फिर revoked keys के जगह clean credentials install।
सभी secrets एक साथ बिना dependency map rotate करने से critical services fail हो सकती हैं। Incident lead privileged, externally exploitable identities को priority दे, फिर app-specific tokens rotate करे; audit logs में each rotation’s owner और time दर्ज हो। नया token compromised machine में paste न करें। Public article में actual private key, secret value या database URL examples साझा करने से बचें।
AI providers का खर्च अचानक बढ़े तो क्या देखें
अगर compromised AI proxy से LLM provider keys चोरी हों तो unauthorized API usage, unusual geographic requests, high token spend या disabled quotas investigation के signals हो सकते हैं। Provider consoles में model usage, API key audit, request dates और per-project limits review करें। Suspicious requests का meaning समझने के लिए normal workload baseline तथा recent legitimate deployments भी देखना होगा।
Unauthorised request मिलने पर affected key revoke करें, clean secrets replace करें और account owner तथा security team से provider incident support engage करें। केवल expenses बढ़ने से malware साबित नहीं होता; legitimate campaigns, load tests या misconfigured retries भी bills बढ़ा सकते हैं। Financial alerting security controls का useful complementary layer है।
CI/CD pipeline और GitHub identity hardening
Lookalike repository impersonation और compromised release process रोकने के लिए release pipelines पर least-privilege tokens, protected tags, code-review requirements, short-lived signing credentials तथा artifact attestation useful हैं। Github organisation exact spelling जाँचें, tag commit और source provenance compare करें, dependency build sources trusted registry तक सीमित रखें। AI dependencies को lockfiles और allowlisted hashes के साथ pin करें।
Continuous delivery पर post-build software bill of materials (SBOM), environment-specific policy और deployment approval mechanism जोड़ें। यह guaranteed prevention नहीं, attack surface घटाने का practical तरीका है। Team को हर release के लिए manual internet rumours follow करने के बजाय approved security bulletin monitoring तथा vendor advisories की workflow देनी चाहिए।
MSME और छोटे startups के लिए 30-minute assessment
छोटी AI startup के पास अलग SOC team नहीं हो तो भी read-only initial review संभव है। पहले यह देखें कि Python services में LiteLLM installed है या नहीं; दूसरा package versions और image digests की list बनाएं; तीसरा 23 October आसपास के deployment records देखें; चौथा secrets/permissions exposure map करें; पाँचवाँ external-facing gateway और cloud audit logs में anomalies note करें; छठा suspected exposure पर trusted security provider के साथ containment और credential rotation plan बनाएं।
यह 30-minute timeline illustrative self-assessment है, complete forensic investigation की duration का वादा नहीं। यदि developer unsure है कि company container images कहाँ से बनाती है, तो Kubernetes manifests, GitHub Actions, Dockerfile और deploy dashboard को owners के साथ document करना होगा। Least-cost security improvement अक्सर clean inventory और proper access controls हैं।
False positives और incident severity कैसे समझें
CERT-In “reportedly compromised” wording इस्तेमाल करती है और actual impact installed artifacts तथा privileges पर depend होने की बात कहती है। Package metadata में LiteLLM listed होने के बावजूद version different हो सकता है; old vulnerable wheel download हुआ पर execute न हुआ हो; या actual running image build किसी independently verified source से आया हो। हर case की exposure probability और confidentiality/integrity impact अलग होंगे।
लेकिन केवल network logs में attacker domain absent होना clean bill नहीं, क्योंकि visibility incomplete हो सकती है। Suspicious hosts पर forensic timeline, loaded startup files और privilege review relevant हैं। Risk report में categories रखें: confirmed affected, likely exposed, under investigation और evidence of no affected artifact। इससे executive decision panic-driven blanket claims से बेहतर होते हैं।
March बनाम October: checklist में दोनों क्यों रखें
Teams के पास पुराना March incident patch checklist पड़ा हो सकता है, जिसमें affected PyPI versions 1.82.7/1.82.8 और उस समय का clean release लिखा है। October alert v1.107.0 से जुड़ा है और Docker images को भी address करता है। Incident response runbook में दोनों events अलग rows के रूप में रखें—discovery date, affected versions, image status, files/indicators, official source तथा status of recovery।
History इसलिए उपयोगी है कि Python startup hooks और build-pipeline trust attacks बार-बार अलग रूप ले सकते हैं। लेकिन पुरानी “safe versions” को future incidents की permanent whitelist न मानें। October clean remediation के लिए October advisory और verified maintainer status देखें।
Official advisory और responsible incident reporting
CERT-In की advisory list में CIAD-2026-0053 को 23 October date के साथ find कर सकते हैं। Affected systems की technical team incident details, source artifacts और observable impact के साथ internal IR process शुरू करे। Applicable CERT-In Directions के तहत covered entities के incident-reporting obligations अलग हो सकते हैं; reporting deadline/format समझने के लिए current official Directions या legal compliance owner देखें।
Public-facing security communication में unfounded claims से बचें: “100% सभी AI apps hacked” गलत generalisation है। यदि users’ data potentially exposed हुआ हो तो regulator/legal requirements और incident investigation के confirmed facts के अनुसार responsible notification plan बनाएं। Sensitive forensic logs तथा secrets public social media पर share न करें।
Frequently Asked Questions — CERT-In LiteLLM Advisory 2026
23 October advisory किस version पर है? CERT-In ने LiteLLM 1.107.0 PyPI release और reportedly affected Docker images की बात कही है।
क्या March के 1.82.7/1.82.8 और October के 1.107.0 एक ही incident हैं? नहीं, dates और affected artifacts अलग हैं।
क्या package import किए बिना execution risk हो सकता है? Advisory Python startup mechanisms abuse होने की reported संभावना बताती है।
कौन-सी files investigate करें? Reported cook.pth, cook.py और modified/unexpected sitecustomize.py तथा suspicious processes/logs।
क्या हर Docker image affected है? ऐसा blanket claim नहीं; origin और exact digest verify करें।
क्या package uninstall कर देने से everything safe है? नहीं; containers rebuild, persistence investigation और potentially exposed secrets rotation आवश्यक हो सकती है।
Clean version क्या है? October CERT-In analysis 1.106.2 का reference देती है, लेकिन integrity/suitability independently verify करने को कहती है।
क्या WordPress या n8n बिना LiteLLM integration affected हैं? ऐसे unrelated tools के compromise का यह advisory अकेले proof नहीं। Dependencies और deployed artifacts की जांच जरूरी है।
Primary sources और security references
- CERT-In Advisory CIAD-2026-0053 — 23 October 2026, LiteLLM 1.107.0 and Docker images
- CERT-In 2026 Advisory List
- LiteLLM maintainers’ March 2026 incident note — separate older incident 1.82.7/1.82.8
- StepSecurity — Technical analysis referenced by CERT-In for October event
- Nexeons — AI Agent Evaluation and Human Approval
- Nexeons — Understanding Infrastructure Risk and Financial Exposure
Editorial security disclaimer: The advisory is a reported supply-chain compromise; this is a defensive guide, not a tested penetration report on any individual service. No credentials, PII or exploit artifacts were downloaded or inspected on the reader’s systems. Organisations should follow authorised incident-response and verified vendor procedures.
इस विषय पर आगे क्या पढ़ें?
इस खबर से जुड़े विषयों को आसान भाषा में और गहराई से समझें।
