Útok na dodavatelský řetězec LiteLLM: TeamPCP kompromitoval PyPI balíček po dobu tří hodin

Novinky Date: 24. březen 2026 Zobrazení: 20

Útok na dodavatelský řetězec LiteLLM: TeamPCP kompromitoval PyPI balíček po dobu tří hodin

Dne 24. března 2026 došlo k supply chain útoku na populární open-source knihovnu LiteLLM. Skupina TeamPCP nahrála na PyPI dvě škodlivé verze (1.82.7 a 1.82.8), které obsahovaly backdoor. Balíčky byly dostupné přibližně tři hodiny (od 10:39 do cca 14:00 UTC), než je PyPI odstranil a zablokoval.

LiteLLM slouží jako unifikovaná vrstva pro přístup k více než 100 jazykovým modelům přes jedno API. Knihovna má desítky milionů stažení měsíčně a je často používána jako závislost v projektech jako CrewAI, DSPy, Mem0 nebo Guardrails.

Útočníci získali přístup k PyPI publish tokenu LiteLLM nepřímo přes kompromitaci Trivy (bezpečnostní skener, který LiteLLM používal v CI/CD pipeline). Škodlivý kód v Trivy GitHub Action exfiltroval tajný token, který útočníci následně využili k nahrání pozměněných verzí.

Škodlivý kód

Obě verze obsahovaly malware s několika funkcemi:

Krádež přihlašovacích údajů (SSH klíče, cloud tokeny AWS/GCP/Azure, Kubernetes secrets, .env soubory, přístupy ke kryptoměnovým peněženkám).
Exfiltrace dat na attacker-controlled server models.litellm.cloud.
Nástroje pro laterální pohyb v Kubernetes (nasazování privilegovaných podů).
Persistentní backdoor registrovaný jako systemd služba.

Verze 1.82.8 navíc využívala mechanismus .pth souboru, který spouští kód automaticky při startu Python interpreteru – tedy i bez explicitního importu balíčku.

Kdo byl ohrožen

Uživatelé, kteří v kritickém okně nainstalovali verze 1.82.7 nebo 1.82.8 přes pip.
Oficiální LiteLLM Proxy Docker image (s pinned verzemi) nebyl ovlivněn.

Doporučení

Zkontrolujte historii instalací balíčků v kritickém časovém okně.
Pokud byly instalovány postižené verze → okamžitě rotujte všechny secrets (cloud keys, SSH, Kubernetes, API klíče k LLM providerům atd.).
Zkontrolujte přítomnost neznámých systemd služeb a podezřelých procesů.
V budoucnu preferujte pinned verze (==) a SBOM / integrity checking.

Tento incident opět ukazuje, jak nebezpečné mohou být kompromitace CI/CD nástrojů a bezpečnostních scannerů – útočníci postupně pivotují z jednoho důvěryhodného projektu na další.