LiteLLM 1.107.0 był złośliwy: co firmy muszą sprawdzić po incydencie

21 października 2026 roku pipeline wydawniczy LiteLLM opublikował złośliwą wersję 1.107.0 w PyPI oraz rejestrach obrazów kontenerowych. Dwa dni później zespół projektu opisał łańcuch zdarzeń: od klucza pozostawionego w publicznym repozytorium, przez kradzież tokenów GitHub, aż po zmianę procesu wydawniczego i podpisanie złośliwych artefaktów.

To ważna wiadomość nie tylko dla zespołów AI. LiteLLM może działać jako biblioteka, brama do wielu dostawców modeli albo komponent infrastruktury deweloperskiej. Jeżeli złośliwy artefakt został zainstalowany na stacji programisty, runnerze CI/CD lub serwerze proxy, w zasięgu mogły znaleźć się sekrety chmurowe, tokeny repozytoriów, klucze dostawców modeli i sesje użytkowników.

Najważniejsze działanie: nie traktuj aktualizacji pakietu jako pełnego zamknięcia incydentu. Najpierw ustal, gdzie wersja 1.107.0 została pobrana lub uruchomiona, zabezpiecz dowody, odbuduj środowiska z zaufanych artefaktów i obróć wszystkie poświadczenia, które mogły być dostępne dla procesu.

Co potwierdził zespół LiteLLM

Według opublikowanej analizy źródłowej, w maju 2026 roku do publicznego repozytorium trafił plik konfiguracyjny z kluczem głównym eksperymentalnej platformy agentowej. Commit szybko nadpisano, ale klucz nie został skutecznie unieważniony. 10 października napastnik użył go do dostępu do API platformy, z którego pozyskał token GitHub CLI należący do właściciela organizacji.

Ten token miał szerokie uprawnienia. Atakujący użył go do uruchamiania krótkotrwałych workflow wykradających kolejne sekrety CI. Zdobył w ten sposób tokeny dwóch maintainerów. Następnie zmienił prywatny proces wydawniczy tak, aby pobierał kod z łudząco podobnego repozytorium Berri-AI/litellm, a skradzionymi tożsamościami uruchomił i zatwierdził wydanie.

21 października między 11:39 a 11:40 UTC do PyPI trafiło siedem złośliwych wheelów. Kilka minut później opublikowano obrazy w Docker Hub i GitHub Container Registry. Projekt podaje, że artefakty pozostawały dostępne około dwóch godzin. Rekordy uruchomień pipeline’u zostały usunięte, a historia zmiany nadpisana, lecz działania pozostały widoczne w logach audytowych.

CERT-In wskazuje, że w artefaktach znalazły się pliki cook.pth, cook.py i sitecustomize.py. Mechanizmy startowe Pythona mogły uruchamiać kod bez jawnego importu LiteLLM. Opisany komponent zbierający dane celował między innymi w poświadczenia przeglądarek, klucze SSH i GPG, sekrety AWS, Azure i Google Cloud, zmienne środowiskowe, tokeny CI/CD oraz dane narzędzi AI.

Kogo dotyczy ryzyko

Do pilnej weryfikacji kwalifikują się organizacje, które 21 października lub później:

• zainstalowały litellm==1.107.0 z PyPI;
• pobrały albo uruchomiły obraz LiteLLM z Docker Hub lub GHCR w czasie incydentu;
• przechowują pakiety w wewnętrznym mirrorze, cache’u CI albo własnym rejestrze kontenerów;
• zbudowały obraz aplikacji na bazie skażonej warstwy;
• uruchomiły Pythona w środowisku, w którym złośliwe pliki znalazły się w site-packages.

Brak jawnego importu biblioteki nie wyklucza ekspozycji. To istotna różnica między typową podatnością a złośliwym pakietem: wystarczające mogło być przygotowanie środowiska i uruchomienie interpretera.

Plan reakcji dla firmy

1. Zbuduj listę ekspozycji

Przeszukaj manifesty zależności, lockfile, SBOM-y, logi budowania, cache pakietów, warstwy obrazów i historię wdrożeń. Sprawdź nie tylko produkcję, ale również laptopy deweloperów, efemeryczne runnery i środowiska testowe. Zanotuj czas instalacji oraz tożsamość procesu.

2. Zabezpiecz materiał przed czyszczeniem

Jeżeli istnieje realna ekspozycja, zachowaj logi EDR, DNS, proxy, CI/CD, rejestru kontenerów, repozytorium i chmury. CERT-In zaleca izolację podejrzanych hostów oraz zachowanie dowodów przed zakończeniem procesów. Pochopne usunięcie pliku może zniszczyć informację potrzebną do określenia zakresu.

3. Odbuduj, zamiast ufać czyszczeniu w miejscu

Kontenery i runnery odtwórz z obrazu oraz zależności o zweryfikowanym pochodzeniu. Usuń skażone artefakty z cache’y, mirrorów i wewnętrznych rejestrów. Samo przesunięcie taga nie usuwa wcześniej pobranej warstwy ani obrazu użytego w kolejnym buildzie.

4. Obróć sekrety z czystego środowiska

Zakres powinien wynikać z tego, co proces mógł odczytać: tokeny GitHub i CI/CD, klucze chmurowe, poświadczenia rejestrów, sekrety Vault, klucze dostawców LLM, master_key i salt_key LiteLLM, a w uzasadnionych przypadkach także sesje przeglądarki oraz klucze SSH/GPG. Rotację wykonuj dopiero z zaufanego hosta.

5. Szukaj użycia skradzionych poświadczeń

Przejrzyj logowania, wywołania API chmury, aktywność repozytoriów, zmiany workflow, użycie kluczy modeli i odczyty bazy LiteLLM. Brak wykrytego pliku na działającym hoście nie dowodzi braku ekspozycji, jeżeli środowisko zostało już usunięte.

Lekcja zarządcza: usunięty sekret nadal jest sekretem wykradzionym

Najważniejszy element analizy LiteLLM wydarzył się pięć miesięcy przed publikacją złośliwego wydania. Klucz został ujawniony, commit nadpisano, ale rotacja nie została doprowadzona do końca. To pokazuje różnicę między usunięciem śladu a odebraniem dostępu.

Firma powinna mierzyć nie tylko liczbę wycieków znalezionych przez skaner, ale także czas do unieważnienia poświadczenia, potwierdzenie wykonania rotacji i zamknięcie wszystkich kopii sekretu. Ochrona gałęzi także nie wystarczy, jeżeli skradziona tożsamość właściciela może ją wyłączyć, a zatwierdzenia należą do innych skompromitowanych kont.

W procesie wydawniczym warto rozdzielić prawo do zmiany źródła, uruchomienia builda, zatwierdzenia produkcji i publikacji. Artefakt powinien być powiązany z konkretnym commitem, a alarmy powinny obejmować zmianę repozytorium źródłowego, obejście reguł, usunięcie logów i force-push do chronionej gałęzi.

Fakty źródłowe i wnioski Breachroad

LiteLLM potwierdza daty, skradzione tokeny, zmianę procesu wydawniczego, publikację wheelów i obrazów oraz około dwugodzinne okno dostępności artefaktów. CERT-In opisuje wersję 1.107.0, pliki złośliwego mechanizmu, potencjalnie zbierane poświadczenia oraz zalecenia dotyczące izolacji, odbudowy i rotacji.

Kolejność reakcji, model rozdzielenia uprawnień i mierniki procesu sekretów są wnioskami Breachroad. Uzupełnia je nasz przewodnik po atakach na łańcuch dostaw oprogramowania oraz zarządzaniu sekretami i rotacji. Zespoły techniczne i właściciele procesów mogą przećwiczyć decyzje incydentowe podczas szkoleń cyberbezpieczeństwa dla organizacji, a rzeczywisty zakres ekspozycji zweryfikować w ramach audytu bezpieczeństwa IT.

Źródła pierwotne: LiteLLM — analiza łańcucha ataku, CERT-In — CIAD-2026-0053, GitHub Advisory Database — GHSA-92x9-889m-jgmw.