Jeden z najważniejszych pakietów Python w ekosystemie AI właśnie stał się narzędziem do kradzieży danych. Biblioteka LiteLLM, używana przez dziesiątki milionów instalacji miesięcznie, trafiła do PyPI z ukrytym złośliwym oprogramowaniem, które bez żadnej interakcji użytkownika zbiera i wysyła poufne dane na serwery atakujących.
Jeśli chcesz otrzymać raport przed oficjalną premierą oraz zobaczyć nazwę swojej firmy wśród uczestników badania – zostaw adres email na końcu ankiety.
Co się stało i kto za tym stoi
Za atakiem stoi grupa TeamPCP, ta sama, która w ostatnich tygodniach skompromitowała skaner podatności Trivy firmy Aqua Security oraz akcję GitHub KICS projektu Checkmarx. Wzorzec działania jest identyczny w każdym przypadku: przejąć konto maintainera, wgrać zatrute wersje pakietu, uruchomić wieloetapowy infostealer.
Atakujący przejęli konto jednego z opiekunów projektu i wykorzystali je do opublikowania dwóch złośliwych wersji LiteLLM na PyPI: 1.82.7 oraz 1.82.8. Wersja 1.82.8 pojawiła się na PyPI 24 marca 2026 roku o godzinie 10:52 UTC. Co istotne, nie towarzyszył jej żaden odpowiadający tag ani release na GitHubie, co oznacza, że pakiet trafił do repozytorium z pominięciem normalnego procesu wydania.
Dlaczego LiteLLM to szczególnie atrakcyjny cel
LiteLLM to nie jest zwykła biblioteka. Pakiet umożliwia kierowanie zapytań do ponad 100 dostawców modeli językowych i stanowi warstwę pośrednią dla tysięcy aplikacji AI. Pobierany jest około 97 milionów razy miesięcznie. Oznacza to, że na maszynach, gdzie jest zainstalowany, zwykle znajdują się klucze do OpenAI, Anthropic, Google, AWS i wielu innych serwisów. To idealny cel.
Co więcej, LiteLLM jest zależnością pośrednią dla rosnącej liczby frameworków agentów AI, serwerów MCP i narzędzi do orkiestracji modeli. Oznacza to, że nawet jeśli nigdy samodzielnie nie uruchomiło się komendy pip install litellm, biblioteka mogła trafić na maszynę przez jakieś inne narzędzie. Osoba, która jako pierwsza odkryła atak, znalazła złośliwy pakiet, bo jej środowisko Cursor IDE pobrało go przez plugin MCP.
Jak działa złośliwe oprogramowanie
Tu zaczyna się naprawdę nieprzyjemna część.
Plik litellm_init.pth zawarty w wersji 1.82.8 waży 34 628 bajtów i wykonuje się automatycznie przy każdym uruchomieniu interpretera Pythona, bez konieczności importowania biblioteki. Wystarczy, że jest zainstalowany. Atak przebiega w trzech etapach:
- Zbieranie danych: klucze SSH, zmienne środowiskowe, dane uwierzytelniające AWS, GCP, Azure, Kubernetes, hasła do baz danych, historia powłoki, pliki
.gitconfig - Portfele kryptowalut: Bitcoin, Litecoin, Ethereum, Solana, Cardano i inne
- Dane z narzędzi DevOps: pliki CI/CD (Travis, GitLab, Jenkins, Drone), konfiguracje Terraform, klucze Slack i Discord, ogólne klucze API
- Lateral movement: próby przejęcia klastrów Kubernetes przez wdrożenie uprzywilejowanych podów na każdym węźle
Zebrane dane są szyfrowane kluczem AES, a sam klucz sesji jest dodatkowo zaszyfrowany 4096-bitowym kluczem RSA. Całość trafia na serwer C2 pod adresem models[.]litellm[.]cloud, czyli domenę celowo zaprojektowaną, żeby wyglądała jak oficjalny serwis projektu.
Domena litellm.cloud (nie mylić z oficjalną litellm.ai) została zarejestrowana 23 marca 2026, czyli zaledwie kilka godzin przed pojawieniem się złośliwych pakietów.
Komentarz redaktora
Ten atak to modelowy przykład tego, dlaczego bezpieczeństwo łańcucha dostaw oprogramowania jest jednym z największych nierozwiązanych problemów w branży IT. Z jednej strony mamy ogromną wartość ekosystemu open source, który pozwala tysiącom deweloperów budować zaawansowane aplikacje AI w krótkim czasie. Z drugiej, jeden skompromitowany maintainer wystarczy, żeby zainfekować miliony środowisk produkcyjnych na całym świecie.
Nie demonizowałbym tutaj open source. To nie jest wada modelu, to wada braku wystarczających zabezpieczeń w procesie publikacji pakietów. PyPI, npm, czy inne repozytoria muszą wdrożyć znacznie bardziej rygorystyczne kontrole tożsamości i mechanizmy weryfikacji nowych wersji. Pytanie, które chcę postawić głośno: ile podobnych ataków przeszło niezauważonych?
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Skala wycieku danych
Według nieoficjalnych informacji przekazanych redakcji BleepingComputer, liczba dokonanych eksfiltracji danych wynosi około 500 000, przy czym wiele z nich to duplikaty. Wersja 1.82.7 różni się mechaniką działania od wersji 1.82.8: złośliwy ładunek w 1.82.7 był osadzony bezpośrednio w pliku proxy/proxy_server.py i wymagał importu biblioteki do aktywacji, podczas gdy 1.82.8 uruchamiał się automatycznie przy każdym starcie interpretera Pythona.
Jeden z deweloperów opisał na GitHubie, jak pierwszym objawem zainfekowania był brak pamięci RAM, bo złośliwy kod niezamierzenie tworzył nieskończony łańcuch procesów potomnych. Mechanizm fork bomb był błędem w samym złośliwym oprogramowaniu, a nie zamierzonym działaniem.
Co zrobić, jeśli używasz LiteLLM
Działaj natychmiast. Kolejność kroków:
- Sprawdź, czy masz zainstalowane wersje
1.82.7lub1.82.8(pip show litellm) - Jeśli tak, natychmiast wymień wszystkie klucze i tokeny obecne na danej maszynie lub w zmiennych środowiskowych
- Przeszukaj system pod kątem pliku
~/.config/sysmon/sysmon.pyi powiązanych usług systemd - Sprawdź przestrzeń nazw
kube-systemw klastrach Kubernetes pod kątem nieautoryzowanych podów - Monitoruj ruch wychodzący pod kątem komunikacji ze znanymi domenami atakujących
Obie złośliwe wersje zostały usunięte z PyPI. Aktualna, czysta wersja to 1.82.6. Projekt MLflow, jako jeden z pierwszych, zablokował awaryjnie wersje wyższe niż 1.82.6.
Szerszy kontekst: TeamPCP uderza seryjnie
To nie jest izolowany incydent. W ciągu zaledwie tygodnia TeamPCP:
- 19 marca: skompromitowali Trivy, popularny skaner podatności Aqua Security
- 23 marca: przejęli akcję GitHub KICS projektu Checkmarx
- 24 marca: zaatakowali LiteLLM
Grupa wdraża też skrypt celujący w klastry Kubernetes, który niszczy wszystkie maszyny skonfigurowane dla Iranu, a w innych regionach instaluje nowy backdoor o nazwie CanisterWorm.
Wzorzec jest jasny. Atakujący systematycznie przechodzą przez kluczowe narzędzia ekosystemu DevOps i AI, jedno po drugim. Jeśli Twoja organizacja korzysta z jakiegokolwiek narzędzia open source w obszarze AI lub bezpieczeństwa, teraz jest dobry moment, żeby zweryfikować, skąd pochodzi każda z jego zależności.
