gik|iewicz

szukaj
LiteLLM Supply Chain Attack: 97 milionów pobrań narażonych na kradzież danych

LiteLLM Supply Chain Attack: 97 milionów pobrań narażonych na kradzież danych

24 marca 2026 o godzinie 10:39 UTC na PyPI opublikowano złośliwą wersję jednego z najpopularniejszych pakietów Python w ekosystemie AI. LiteLLM — biblioteka służąca jako proxy dla API modeli językowych — z 97 milionami miesięcznych pobrań stała się wektorem ataku na dane uwierzytelniające tysięcy firm i deweloperów.

Porównanie skali ataków supply chain: LiteLLM 97M, SolarWinds 100M, Log4j 100M
Źródło: Snyk, Sonatype, Datadog Security Labs, marzec 2026

TL;DR: Wersje 1.82.7 i 1.82.8 pakietu litellm na PyPI zawierały trójstopniowy malware kradnący klucze API, dane uwierzytelniające chmury i tokeny Kubernetes. Atak trwał ~3 godziny zanim PyPI poddało pakiet kwarantannie. Bezpieczne wersje to ≤1.82.6. Sprawdź swoje zależności natychmiast.

Co się stało z LiteLLM na PyPI?

Grupa TeamPCP opublikowała zainfekowane wersje 1.82.7 i 1.82.8 pakietu litellm po skompromitowaniu tokena PYPI_PUBLISH maintainera (Snyk, marzec 2026). Atak wykorzystywał mechanizm .pth w Pythonie, który uruchamia złośliwy kod w momencie startu dowolnego procesu Pythona — włącznie z samym pip.

Pakiety były dostępne na PyPI przez około 3 godziny. W tym czasie LiteLLM pobierano średnio 3,4 miliona razy dziennie, co czyni go jednym z najważniejszych komponentów infrastruktury AI.

Terminal z kodem Python i błędami bezpieczeństwa
Wizualizacja błędu bezpieczeństwa w terminalu Python

Nasza analiza: To nie był izolowany incydent — TeamPCP prowadzi kampanię od grudnia 2025, atakując kolejno Trivy (19 marca), Checkmarx KICS (23 marca) i LiteLLM (24 marca). Wszystkie ataki wykorzystują tę samą infrastrukturę C2 i podobny payload, co wskazuje na zaplanowaną operację supply chain.

Jak działał atak na łańcuch dostaw?

Atak rozpoczął się pięć dni wcześniej od skompromitowania narzędzia Trivy — popularnego skanera bezpieczeństwa używanego w CI/CD (Snyk, marzec 2026). Napastnicy nadpisali tagi Git w repozytorium trivy-action, kierując do złośliwej wersji v0.69.4 zawierającej credential harvester.

Łańcuch ataku wyglądał następująco:

  1. 19 marca: Skompromitowanie Trivy GitHub Action
  2. 23 marca: Rejestracja domeny models.litellm.cloud (wygląda jak oficjalna)
  3. 24 marca, 10:39 UTC: Publikacja litellm 1.82.7 na PyPI
  4. 24 marca, 10:52 UTC: Publikacja litellm 1.82.8 na PyPI
  5. 24 marca, ~13:38 UTC: PyPI poddaje pakiet kwarantannie

Kluczowym momentem było przejęcie tokena PYPI_PUBLISH z GitHub Actions runner environment. LiteLLM używało Trivy w swoim pipeline bez przypiętej wersji, co pozwoliło na pobranie skompromitowanej wersji.

Według analizy Snyk, mechanizm .pth uruchamia się przy każdym starcie procesu Pythona, włącznie z pip (Snyk, marzec 2026). W środowiskach CI/CD oznacza to, że payload może wykonać się już podczas budowania aplikacji, nie tylko w runtime.

Co kradł malware z LiteLLM?

Payload składał się z trzech etapów:

Etap 1: Credential Harvester — wykradał klucze API OpenAI, Anthropic, Google, AWS, Azure, GCP i zmienne środowiskowe zawierające słowa takie jak „API_KEY”, „SECRET”, „TOKEN”.

Etap 2: Encrypted Exfiltration — szyfrował dane AES-256 i wysyłał do models.litellm.cloud przez HTTPS. Domena wyglądała jak oficjalna infrastruktura LiteLLM.

Etap 3: Persistence + Kubernetes Worm — instalował backdoor jako systemd service i próbował rozprzestrzenić się na klastry Kubernetes, czytając sekrety z wszystkich namespace’ów i instalując złośliwe pody na węzłach.

Gdy sprawdzaliśmy własne projekty po doniesieniach o ataku, okazało się, że jedna z naszych zależności transitives pobierała litellm>=1.82.0. Na szczęście nasz lock file wskazywał wersję 1.82.5, więc byliśmy bezpieczni. To pokazuje, jak ważne jest pinowanie wersji w plikach requirements.

Kto jest zaangażowany w atak TeamPCP?

TeamPCP (znany też jako PCPcat, Persy_PCP, ShellForce, DeadCatx3) jest aktywny od grudnia 2025 (Wiz Threat Center, marzec 2026). Grupa utrzymuje kanały Telegram @Persy_PCP i @teampcp oraz osadza string „TeamPCP Cloud stealer” w swoich payloadach.

LiteLLM to Faza 09 trwającej kampanii. Wcześniejsze fazy obejmowały:

  • Checkmarx Open VSX plugins na npm
  • Trivy GitHub Actions
  • Checkmarx KICS GitHub Action

To wskazuje na systematyczne atakowanie narzędzi bezpieczeństwa i infrastruktury DevOps.

Jak sprawdzić, czy jesteś dotknięty?

Natychmiastowe działania:

  1. Sprawdź wersję litellm w swoim środowisku:
    pip show litellm | grep Version
  2. Jeśli wersja to 1.82.7 lub 1.82.8 — natychmiast zaktualizuj:
    pip install litellm==1.82.6
  3. Przeskanuj system pod kątem plików backdoor:
    find ~ -name "sysmon.py" -o -name "sysmon.service"
    ls -la ~/.config/sysmon/ 2>/dev/null
  4. Sprawdź, czy domena models.litellm.cloud pojawia się w logach sieciowych
  5. Rotuj wszystkie klucze API, które mogły zostać wykradzione

Jakie projekty zostały dotknięte?

W ciągu 3 godzin zainfekowane wersje zostały użyte w co najmniej kilku znanych projektach:

ProjektStatus
DSPyPR #9498 merged — pin do bezpiecznej wersji
nanobotPR #2441 — naprawiono
dreadnode/riggingPR #356 — naprawiono
CoPawIssue #2209 — zgłoszono
Aider✅ Bezpieczny (pin litellm==1.82.3)

Aider — popularne narzędzie AI do programowania — było bezpieczne, ponieważ pinowało konkretną wersję w requirements.txt. To najlepsza praktyka, która uratowała wielu użytkowników.

Jak chronić się przed atakami supply chain?

Dla deweloperów:

  1. Pinuj wersje zależności — używaj requirements.txt z dokładnymi wersjami, nie >=x.y.z
  2. Używaj lock filespip-tools, poetry.lock, Pipfile.lock
  3. Weryfikuj sygnatury — sprawdzaj checksumy pakietów przed instalacją
  4. Monitoruj zależności — używaj narzędzi typu Dependabot, Snyk, Socket

Dla organizacji:

  1. Private PyPI mirror — buforuj pakiety przed użyciem w produkcji
  2. Skany bezpieczeństwa — automatyczne sprawdzanie nowych wersji
  3. Separacja środowisk — izoluj CI/CD od produkcyjnych sekretów
  4. Audit trail — loguj, jakie wersje pakietów są używane

Najczęściej zadawane pytania

Czy muszę się martwić, jeśli używam starszej wersji LiteLLM?

Nie. Tylko wersje 1.82.7 i 1.82.8 zawierały malware. Wersje ≤1.82.6 są bezpieczne. Jeśli masz zainstalowaną wersję 1.82.6 lub starszą, nie musisz nic robić poza monitorowaniem komunikatów bezpieczeństwa.

Co jeśli pobrałem zainfekowaną wersję, ale jej nie użyłem?

Payload uruchamiał się automatycznie przy imporcie pakietu poprzez mechanizm .pth. Jeśli wykonałeś import litellm lub uruchomiłeś jakikolwiek proces Pythona w środowisku z zainfekowaną wersją, rotuj wszystkie klucze API i sprawdź system pod kątem backdoor.

Czy atak dotyczy tylko Pythona?

Kampania TeamPCP obejmuje także npm (Checkmarx Open VSX) i GitHub Actions. Jeśli używasz narzędzi typu Trivy lub KICS w swoim CI/CD, sprawdź, czy nie używały wersji z okresu ataku (19-24 marca 2026).

Gdzie znajdę oficjalne aktualizacje?

Śledź Snyk Trust Center, oficjalne kanały LiteLLM oraz komunikaty PyPI. Zespół LiteLLM opublikował szczegółowy raport i narzędzie do sprawdzania, czy Twoje pakiety były dotknięte.

Podsumowanie

Atak na LiteLLM to przypomnienie, że łańcuch dostaw oprogramowania pozostaje jednym z najsłabszych ogniw w bezpieczeństwie. Pakiet z 97 milionami miesięcznych pobrań stał się wektorem ataku na infrastrukturę AI tysięcy firm — wszystko przez skompromitowany token w CI/CD.

Kluczowe wnioski:

  • ✅ Pinuj wersje zależności — to uratowało Aider i wielu innych
  • ✅ Oddziel sekrety produkcyjne od środowisk CI/CD
  • ✅ Monitoruj zależności przez narzędzia typu Snyk, Dependabot
  • ✅ Reaguj szybko — 3 godziny wystarczyły, by zainfekować setki projektów