21 października 2026 r. doszło do kolejnego poważnego incydentu bezpieczeństwa związanego z LiteLLM, popularnym rozwiązaniem open source wykorzystywanym do integracji aplikacji z modelami językowymi. Atakujący przejęli kontrolę nad częścią procesu publikowania oprogramowania i doprowadzili do udostępnienia złośliwej wersji LiteLLM 1.107.0 w repozytorium PyPI oraz rejestrach obrazów Docker. Pakiet zawierał malware pozwalający na kradzież poświadczeń i zdalne wykonywanie kodu.

Autor: 7 min czytania

LiteLLM pełni często funkcję centralnej bramy komunikacyjnej pomiędzy aplikacjami a dostawcami modeli AI, takimi jak OpenAI czy Anthropic. Może przechowywać klucze API, zarządzać dostępem użytkowników i pośredniczyć w komunikacji z wieloma usługami. Kompromitacja takiego komponentu jest więc szczególnie niebezpieczna. Atakujący mogą uzyskać dostęp nie tylko do poświadczeń związanych z AI, ale również do innych zasobów dostępnych z zainfekowanego środowiska.

Jak doszło do ataku?

Zgodnie z oficjalnym komunikatem LiteLLM napastnicy wykorzystali poświadczenia powiązane z trzema kontami deweloperów GitHub. Pozwoliło im to zmodyfikować proces wydawniczy, ominąć zabezpieczenia repozytorium i uruchomić publikację pakietów z kodem pochodzącym z kontrolowanego przez nich repozytorium.

Wykorzystano przy tym bardzo podobną nazwę organizacji GitHub. Zamiast prawidłowego BerriAI/litellm proces budowania odwoływał się do Berri-AI/litellm. Różnica sprowadzała się do jednego znaku, ale konsekwencje były poważne. Przygotowane przez atakujących artefakty zostały opublikowane przy użyciu oficjalnej infrastruktury wydawniczej projektu.

Co ciekawe, oficjalny tag wersji 1.107.0 na GitHubie nie zawierał złośliwych plików. Zostały one umieszczone w dystrybuowanych pakietach. Oznacza to, że sama weryfikacja kodu źródłowego w prawidłowym repozytorium mogła nie wystarczyć do wykrycia zagrożenia.

Producent przedstawił również wstępną hipotezę dotyczącą sposobu pozyskania poświadczeń. Według jego ustaleń w określonych sytuacjach Claude Code może umieszczać token GitHub CLI OAuth w treści odpowiedzi, która następnie trafia do logów LiteLLM. Twórcy podejrzewają, że napastnicy uzyskali dostęp do logów wewnętrznego wdrożenia LiteLLM dostępnego z Internetu i w ten sposób zdobyli potrzebne tokeny. Ten element łańcucha ataku nie został jeszcze ostatecznie potwierdzony.

Jak działało złośliwe oprogramowanie?

Badacze z Socket oraz JFrog Security Research wykryli w zainfekowanych pakietach trzy dodatkowe pliki: cook.pth, cook.py oraz sitecustomize.py.

Mechanizm ich działania wykorzystywał standardowe funkcje inicjalizacji interpretera Python. Złośliwy kod mógł uruchamiać się automatycznie podczas startu Pythona, nawet jeśli aplikacja nie importowała bezpośrednio biblioteki LiteLLM. Było to szczególnie niebezpieczne dla środowisk deweloperskich i serwerów CI/CD, w których Python jest uruchamiany regularnie.

Malware próbował zbierać między innymi poświadczenia AWS, Azure i Google Cloud, klucze SSH, tokeny GitHub, dane uwierzytelniające z przeglądarek oraz sekrety zapisane w zmiennych środowiskowych. Atak obejmował również konfiguracje narzędzi AI, a w przypadku wdrożeń LiteLLM Proxy także próby odczytania danych z tabel przechowujących poświadczenia dostawców modeli.

Skradzione informacje były szyfrowane i przesyłane na serwer kontrolowany przez atakujących. Dodatkowy mechanizm umożliwiał okresowe pobieranie i wykonywanie kodu zdalnego, stwarzając możliwość dalszej kompromitacji środowiska.

Kto mógł zostać zaatakowany?

Według danych opublikowanych przez LiteLLM złośliwe pakiety PyPI w wersji 1.107.0 były dostępne 21 października od godziny 11:39 do 13:23 UTC. Niebezpieczne były również obrazy Docker oznaczone jako v1.107.0, latest, main-latest i main-stable. W Docker Hub wskazywały one na skompromitowany obraz od 11:46 do 14:20 UTC.

Oznacza to, że zagrożone mogły być także organizacje, które nie instalowały świadomie wersji 1.107.0, ale korzystały z automatycznych wdrożeń pobierających najnowszy obraz kontenera.

Producent potwierdził usunięcie złośliwych artefaktów i poinformował, że prywatna dystrybucja LiteLLM Enterprise nie została objęta incydentem. Dla użytkowników wersji open source zalecono tymczasowe korzystanie z wcześniejszego wydania 1.106.2.

Co powinny zrobić organizacje korzystające z LiteLLM?

W pierwszej kolejności należy ustalić, czy w organizacji zainstalowano lub uruchomiono złośliwą wersję biblioteki albo jeden ze skompromitowanych obrazów kontenerów. Weryfikacja powinna objąć nie tylko serwery produkcyjne, ale także środowiska testowe, stacje deweloperskie i systemy CI/CD.

Istotne jest sprawdzenie obecności plików cook.pth, cook.py i sitecustomize.py oraz identyfikacja uruchomionych obrazów po ich identyfikatorach SHA-256. Należy pamiętać, że brak tych artefaktów nie daje pewności, że środowisko nie zostało wcześniej zainfekowane.

Producent ostrzega również, by nie rozpoczynać analizy podejrzanego środowiska od uruchamiania poleceń pip. Sam start interpretera Python może bowiem ponownie aktywować złośliwy kod.

W przypadku potwierdzonej kompromitacji zalecane jest odizolowanie środowiska, jego odtworzenie z zaufanych artefaktów i rotacja wszystkich potencjalnie ujawnionych poświadczeń. Dotyczy to zarówno kluczy dostawców AI, jak i haseł baz danych, tokenów dostępowych oraz poświadczeń usług chmurowych. Samo usunięcie złośliwego pakietu nie wystarcza, ponieważ wykradzione wcześniej dane mogą nadal pozostawać w posiadaniu atakujących.

Podsumowanie

To już drugi udokumentowany przypadek kompromitacji łańcucha dostaw LiteLLM w 2026 roku. W marcu napastnicy doprowadzili do publikacji złośliwych wersji 1.82.7 i 1.82.8. Październikowy incydent wykorzystuje inny mechanizm i na obecnym etapie nie ma dowodów, by oba ataki przeprowadziła ta sama grupa. Przypadek LiteLLM pokazuje, jak istotnym elementem bezpieczeństwa systemów AI staje się ochrona procesu wytwarzania i publikowania oprogramowania. Nawet dobrze zabezpieczone środowisko produkcyjne może zostać skompromitowane przez komponent pobrany z oficjalnego źródła. Szczególnego znaczenia nabierają więc ochrona tożsamości deweloperów, kontrola procesów CI/CD oraz weryfikacja faktycznie instalowanych artefaktów, a nie wyłącznie kodu w repozytorium.