Wprowadzenie do problemu / definicja
Atak na łańcuch dostaw oprogramowania polega na skompromitowaniu procesu budowania, publikacji lub dystrybucji aplikacji tak, aby zaufany produkt dostarczał użytkownikom złośliwy kod. W najnowszym incydencie celem stał się LiteLLM, popularny komponent wykorzystywany do integracji aplikacji z wieloma modelami AI za pomocą wspólnego API. Naruszenie objęło zarówno pakiety publikowane w ekosystemie Pythona, jak i obrazy kontenerowe, co znacząco zwiększyło potencjalną skalę zagrożenia.
W skrócie
Kompromitacja dotyczyła wydania LiteLLM 1.107.0. Napastnik przejął elementy procesu publikacji i doprowadził do opublikowania złośliwych pakietów oraz obrazów kontenerowych zawierających malware typu infostealer, ukierunkowane na kradzież poświadczeń, sekretów środowiskowych i danych systemowych.
- Zagrożone były instalacje pobierające podatne artefakty w określonym oknie czasowym.
- Złośliwy kod uruchamiał się przed właściwą aplikacją, co zwiększało skuteczność infekcji.
- Ryzyko obejmowało środowiska deweloperskie, CI/CD, testowe i produkcyjne.
- Zalecana reakcja to izolacja systemów, odbudowa z czystych źródeł i natychmiastowa rotacja sekretów.
Kontekst / historia
LiteLLM to otwartoźródłowy projekt pełniący rolę SDK i bramy dla modeli językowych, szeroko używany w środowiskach deweloperskich oraz produkcyjnych. Ze względu na swoją popularność i obecność w pipeline’ach aplikacji AI stanowi atrakcyjny cel dla ataków na łańcuch dostaw.
W tym przypadku naruszenie procesu wydawniczego doprowadziło do opublikowania zainfekowanej wersji 1.107.0 do repozytorium pakietów Pythona oraz do rejestrów obrazów kontenerowych. Co istotne, według ujawnionych informacji nie zmodyfikowano głównego kodu źródłowego widocznego w oficjalnym repozytorium tej wersji. Zamiast tego podmieniono źródło wykorzystywane przez pipeline publikacyjny, przez co dystrybucyjne artefakty zostały zbudowane z komponentów kontrolowanych przez napastnika.
To ważny sygnał ostrzegawczy dla organizacji: nawet jeśli tag w repozytorium wygląda prawidłowo, finalne pakiety i obrazy mogą zostać skompromitowane na etapie release engineering.
Analiza techniczna
Zakres incydentu obejmował wszystkie koła instalacyjne pakietu LiteLLM 1.107.0 publikowane dla PyPI oraz obrazy kontenerowe oznaczone między innymi tagami v1.107.0, latest, main-latest i main-stable. Mimo że złośliwe artefakty były dostępne przez ograniczony czas, nawet krótka ekspozycja mogła narazić automatyczne procesy pobierające najnowsze wersje bez ścisłego pinowania.
Technicznie atak opierał się na umieszczeniu w środowisku Pythona dodatkowych plików, takich jak cook.pth, cook.py oraz sitecustomize.py. To skuteczna metoda, ponieważ interpreter Pythona podczas startu przetwarza pliki .pth, a następnie może automatycznie importować moduł sitecustomize. W praktyce oznacza to wykonanie złośliwego kodu jeszcze przed uruchomieniem właściwej aplikacji.
Takie podejście utrudnia analizę incydentu i zwiększa prawdopodobieństwo wielokrotnego uruchomienia malware przy każdym starcie interpretera lub narzędzi zależnych od Pythona. Szczególnie niebezpieczne jest to w środowiskach automatyzacji, gdzie jeden komponent może być uruchamiany wielokrotnie w krótkich odstępach czasu.
Ładunek miał charakter info stealera i był ukierunkowany na dane o wysokiej wartości operacyjnej. Obejmowało to:
- poświadczenia chmurowe i wdrożeniowe,
- sekrety związane z Kubernetesem, Dockerem i narzędziami infrastrukturalnymi,
- klucze API używane w systemach AI,
- dane z plików
.env, - poświadczenia do repozytoriów kodu i systemów CI/CD,
- klucze SSH, GPG i TLS,
- dane przeglądarek, zapisane loginy, cookies i historię przeglądania,
- zmienne środowiskowe i informacje o hoście.
W analizach wskazywano również mechanizm dalszego ładowania kodu. Jeden ze złośliwych komponentów uruchamiał odłączony loader, który cyklicznie sprawdzał zdalny wskaźnik i mógł pobierać kolejne elementy wykonawcze na zaatakowany system. Taka architektura sugeruje, że kradzież danych mogła być jedynie pierwszym etapem operacji.
Wektor wejścia również jest istotny z perspektywy obrony. Z opublikowanych informacji wynika, że napastnik uzyskał dostęp do poświadczeń deweloperskich i wykorzystał je do obejścia zabezpieczeń procesu publikacji. Następnie zmienił workflow tak, aby wskazywał na repozytorium przypominające oryginalne, lecz kontrolowane przez atakującego. To klasyczny przykład połączenia kradzieży tożsamości, nadużycia automatyzacji CI/CD oraz nadmiernego zaufania do procesu podpisu i publikacji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem incydentu jest możliwość wycieku sekretów umożliwiających dalszą kompromitację organizacji. Pojedyncza instalacja podatnego pakietu na stacji deweloperskiej, runnerze CI lub hoście aplikacyjnym mogła ujawnić klucze chmurowe, tokeny repozytoryjne, dane bazodanowe, klucze dostawców modeli AI i informacje o konfiguracji środowiska.
W organizacjach intensywnie korzystających z automatyzacji taki wyciek może szybko doprowadzić do eskalacji z incydentu lokalnego do naruszenia obejmującego większą część infrastruktury. Szczególnie zagrożone były środowiska, które:
- pobierają najnowsze obrazy lub pakiety bez blokowania wersji,
- uruchamiają buildy automatycznie po publikacji upstream,
- przechowują sekrety w zmiennych środowiskowych procesu,
- wykorzystują współdzielone runnery CI/CD,
- korzystają z kontenerów jako krótkotrwałych, lecz uprzywilejowanych zadań wdrożeniowych.
Dodatkowym problemem jest to, że samo usunięcie pakietu może nie wystarczyć. Jeśli złośliwe pliki startowe pozostały w środowisku lub aktywny był dodatkowy loader, organizacja mogła nadal pozostawać narażona mimo pozornego odinstalowania komponentu. Tego typu incydent należy więc traktować nie jako zwykły problem zależności, ale jako potencjalną pełną kompromitację hosta.
Rekomendacje
Organizacje, które mogły pobrać lub uruchomić podatne artefakty, powinny przyjąć założenie naruszenia i uruchomić działania w trybie incident response.
- Natychmiast zidentyfikować wszystkie systemy, pipeline’y i obrazy bazowe, które mogły używać LiteLLM 1.107.0 lub wskazanych tagów kontenerowych.
- Unikać uruchamiania interpretera Pythona w potencjalnie skażonym środowisku, ponieważ mechanizm autostartu mógłby ponownie aktywować malware.
- Odizolować zainfekowane hosty i kontenery, a następnie odbudować je z zaufanych źródeł zamiast czyścić in place.
- Natychmiast zrotować wszystkie sekrety, do których host mógł mieć dostęp, w tym klucze chmurowe, tokeny CI/CD, dane bazodanowe, klucze API, klucze SSH i certyfikaty prywatne.
- Przeanalizować logi użycia tożsamości, szczególnie w systemach federacyjnych i rolach tymczasowych.
W dłuższej perspektywie warto wdrożyć środki ograniczające podobne incydenty:
- ścisłe pinowanie wersji pakietów i digestów obrazów,
- weryfikację pochodzenia artefaktów oraz polityki podpisu,
- segmentację sekretów i zasadę najmniejszych uprawnień,
- skanowanie zależności pod kątem anomalii publikacyjnych,
- monitorowanie nieoczekiwanych zmian w workflow CI/CD,
- ograniczenie użycia długotrwałych tokenów deweloperskich,
- wprowadzenie kontroli egress dla build runnerów i hostów aplikacyjnych,
- budowanie wewnętrznych mirrorów zależności i opóźnione zatwierdzanie krytycznych wydań upstream.
Podsumowanie
Incydent LiteLLM pokazuje, że nowoczesne ataki na łańcuch dostaw coraz częściej omijają bezpośrednią modyfikację repozytorium źródłowego i koncentrują się na procesach publikacji, poświadczeniach deweloperskich oraz workflow CI/CD. W efekcie legalny kanał dystrybucji może zostać wykorzystany do rozesłania malware kradnącego sekrety i przygotowanego do dalszego pobierania kodu.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest prosty: ochrona zależności nie kończy się na przeglądzie kodu źródłowego. Równie ważne są integralność procesu release, bezpieczeństwo tożsamości deweloperskich, kontrola artefaktów oraz gotowość do szybkiej rotacji sekretów po wykryciu incydentu. W środowiskach AI, gdzie biblioteki pośredniczą w dostępie do wielu zewnętrznych usług, skutki takiego ataku mogą być szczególnie dotkliwe.
Źródła
- LiteLLM release pipeline hacked to distribute info-stealer malware — https://www.bleepingcomputer.com/news/security/litellm-release-pipeline-hacked-to-distribute-info-stealer-malware/
- Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised — https://docs.litellm.ai/blog/security-incident-oct-21-2026
- GitHub – BerriAI/litellm — https://github.com/BerriAI/litellm