Pipeline wydań LiteLLM przejęta po raz kolejny: infostealer rozesłany jako v1.107.0 na PyPI i Docker Hub
W poranek 21 października 2026 na PyPI i w oficjalnych obrazach Dockera projektu wylądowało złośliwe wydanie LiteLLM. Wersja 1.107.0 przewoziła stealer danych uwierzytelniających i loader zdalnego kodu zamiast kodu napisanego przez maintainerów. Zgodnie z własnym biuletynem bezpieczeństwa LiteLLM skompromitowany został sam pipeline wydań — z użyciem wycieku danych logowania GitHub z kont deweloperów projektu. Złośliwe pakiety wheel spędziły na PyPI mniej niż dwie godziny, a zarażone tagi Dockera przetrwały całe popołudnie. W ekosystemie automatycznych buildów i przypiętych zależności to aż nadto wystarczająco długo, by zrobić szkody.
Czysty tag, zatruty build
Ujawnienie czyta się jak listę kontrolną kruchości zaufania do pakietów. LiteLLM informuje, że atakujący zdobył tokeny OAuth GitHub CLI z trzech kont deweloperów — najwyraźniej zapisane w logach wystawionej do internetu wewnętrznej instancji LiteLLM; jedno z kont należało do właściciela organizacji na GitHubie. Za pomocą tych danych wyłączono ochronę branchy, wymuszono zmianę w workflow i skierowano pipeline na bliźniacze repozytorium: Berri-AI/litellm — jeden myślnik od prawdziwego BerriAI/litellm. Oficjalny tag git v1.107.0 pozostał czysty; złośliwe artefakty zbudowano z podróbki."Ta wersja zawierała skompilowane złośliwe oprogramowanie kradnące dane uwierzytelniające i ładujące narzędzia zdalnego wykonywania kodu." — biuletyn bezpieczeństwa LiteLLM, 21 października 2026Wykrycie przynajmniej było szybkie. Jak relacjonuje BleepingComputer, firmy bezpieczeństwa, w tym Socket i Endor Labs, oflagowały wydanie w około sześć minut, a PyPI usunął pakiety do 13:23 UTC; Docker Hub wyczyszczono po południu. LiteLLM twierdzi, że klienci prywatnego rejestru enterprise nie zostali dotknięci. Sześć minut nadal się liczy, gdy pakiet notuje około 92 mln pobrań miesięcznie, a wśród jego użytkowników wymienia się NVIDIA, Netflixa czy Okta — według BleepingComputer.
Co zbiera stealer
Mechanika ładunku wyjaśnia surowość zaleceń. Pakiety wheel zrzucały trzy pliki — cook.pth, cook.py i sitecustomize.py — do katalogu site-packages Pythona. Python wykonuje takie pliki przy każdym starcie interpretera, więc złośliwe oprogramowanie uruchamiał każdy proces Pythona na maszynie, nawet jeśli LiteLLM nigdy nie został zaimportowany. Techniczna analiza Datadog Security Labs dodaje, że odinstalowanie pakietu litellm nie usuwa tych plików — trzeba je skasować ręcznie. Analiza incydentu od Kodem dokumentuje, po co stealer powstał:- Dane uwierzytelniające chmury i infrastruktury: klucze AWS, Azure i GCP, w tym tokeny metadanych instancji, oraz sekrety Kubernetes, Docker i Terraform
- Materiał specyficzny dla AI: klucze API dostawców LLM, poświadczenia zapisane w bazie proxy LiteLLM i pliki sesji narzędzi do programowania z AI
- Tokeny deweloperskie i rejestrowe: dane logowania Git, tokeny GitHub, npm i PyPI, klucze SSH, GPG i TLS
- Lokalne sekrety: pliki .env, zmienne środowiskowe, historie powłoki i baz danych
- Dane przeglądarki: zapisane hasła, ciasteczka i wpisy autouzupełniania
Drugi incydent z pipeline'em w tym roku
To drugie skompromitowane wydanie LiteLLM w 2026 roku. W marcu aktor znany jako TeamPCP wsadził backdoora do wersji 1.82.7 i 1.82.8 po skompromitowaniu skanera Trivy w CI/CD projektu i kradzieży tokenu PyPI. Datadog łączy obie kampanie tylko celem: związku między sprawcami nie potwierdzono. Niepokoi schemat — brama siedząca w środku tysięcy stosów AI, trzymająca klucze dostawców i dane chmurowe, dwukrotnie w osiem miesięcy miała skażony kanał dystrybucji.Pierwsza godzina wg runbooka
Kodem opatrzył swoje wskaźniki runbookiem reakcji na pierwszą godzinę, a zalecenie LiteLLM jest równie stanowcze. Wspólny rdzeń:- Zablokować litellm 1.107.0 na proxy pakietów, przestać wdrażać pływające tagi jak latest i przypiąć ostatnie czyste wydanie 1.106.2 po hashu — obrazy po digeście
- Nie uruchamiać pythona ani pipa na dotkniętych hostach przed sprzątaniem, bo każdy start interpretera ponownie wykonuje ładunek
- Izolować hosty i kontenery, a potem ręcznie usunąć cook.pth, cook.py, sitecustomize.py i ich skompilowane pliki .pyc
- Rotować z czystej maszyny: role chmurowe, klucze dostawców z bazy proxy, master- i virtual-key LiteLLM, hasło bazy danych, tokeny rejestrów i GitHuba
- Przejrzeć logi audytu chmury pod kątem wywołań GetCallerIdentity i użycia poświadczeń z nieoczekiwanej infrastruktury od 11:39 UTC 21 października