Z aktualnych doniesień i analiz badaczy bezpieczeństwa wynika, że LiteLLM 1.107.0 był złośliwym wydaniem dystrybuowanym 21 października 2026 r. za pośrednictwem PyPI oraz wybranych oficjalnych tagów kontenerów. Wskazywaną bezpieczną wersją do wycofania zmian jest 1.106.2, a zalecana reakcja dla osób, które zainstalowały lub uruchomiły zagrożone artefakty, wykracza poza zwykłą aktualizację: należy odizolować środowisko, odtworzyć je z czystej bazy i zmienić dostępne dla niego poświadczenia.

Które artefakty LiteLLM miały zostać naruszone

Obecne doniesienia wskazują na LiteLLM 1.107.0 jako naruszone wydanie, przy czym ekspozycja miała obejmować zarówno pakiet PyPI, jak i oficjalne obrazy kontenerów. Dostarczony alert wymienia pakiety PyPI i obrazy Docker, w tym latest oraz main-stable, natomiast analizy bezpieczeństwa Wiz i Aikido wskazują również v1.107.0 oraz main-latest.

Zakres ten ma znaczenie, ponieważ część poszkodowanych użytkowników mogła nie wybrać wersji 1.107.0 bezpośrednio. Zespoły korzystające ze zmiennych tagów obrazów mogły pobrać skażoną kompilację w ramach standardowego wdrożenia, a nie w wyniku jawnej zmiany wersji.

W ramach opisywanego zakresu najważniejsze obecnie informacje są następujące:

Dostępne doniesienia nie wskazują jednolitego momentu oczyszczenia wszystkich kanałów. Fragment zgłoszenia GitHub powiązanego z BerriAI/litellm informował, że PyPI zostało już oczyszczone, podczas gdy zmienne tagi Docker były jeszcze zainfekowane w pewnym momencie 21 października. Wiz opisał później, że tagi zostały następnie usunięte. Potwierdza to ogólny obraz incydentu, lecz nie pozwala ustalić jednej ostatecznej godziny zakończenia działań naprawczych.

Dlaczego zgłoszony ładunek był szczególnie ryzykowny

JFrog twierdzi, że złośliwy pakiet LiteLLM w formacie wheel wykorzystywał hak uruchomieniowy Pythona. Oznaczałoby to, że ładunek uruchamiał się wraz ze startem Pythona w zagrożonym środowisku, bez konieczności bezpośredniego importowania LiteLLM przez aplikację. W dostępnym fragmencie JFrog wiąże to działanie z plikiem cook.pth, przetwarzanym podczas standardowej inicjalizacji środowiska site w Pythonie.

Jeżeli mechanizm ten rzeczywiście był obecny, granica ekspozycji wykracza poza pojedyncze wadliwe wywołanie biblioteki. Samo uruchomienie Pythona w zagrożonym środowisku mogło aktywować mechanizm kradzieży poświadczeń, co wyjaśnia, dlaczego zalecenia koncentrują się na izolacji i zmianie sekretów, a nie tylko na zastąpieniu jednej wersji pakietu.

Dostarczony alert wskazuje, że zagrożone dane wrażliwe obejmowały poświadczenia chmurowe, klucze API usług AI oraz prywatne klucze SSH. Odrębne doniesienia z marca 2026 r. streszczały wpis Andreja Karpathy'ego, opisujący szerszy atak na LiteLLM w PyPI, w którym wykradano klucze SSH, poświadczenia chmurowe, konfiguracje Kubernetes, dane dostępowe Git, zmienne środowiskowe, klucze CI/CD i hasła do baz danych. Wcześniejszy raport nie potwierdzał jednak zakresu tagów Docker ani dokładnej listy artefaktów 1.107.0 związanych z październikowym zdarzeniem.

Co powinni teraz zrobić użytkownicy objęci ryzykiem

Zgłaszana rekomendacja zakłada zaprzestanie używania wersji 1.107.0, wycofanie zmian lub przypięcie wersji 1.106.2, odizolowanie każdego hosta lub kontenera, na którym zainstalowano bądź uruchomiono zagrożony artefakt, odtworzenie środowiska z czystej bazy oraz zmianę poświadczeń dostępnych z tego środowiska. Zarówno Aikido, jak i JFrog oceniają ryzyko przez pryzmat tego, czy złośliwy pakiet lub obraz został zainstalowany albo wykonany, a nie tego, czy jest nadal dostępny.

To rozróżnienie jest kluczowe. Aktualizacja w miejscu może usunąć wadliwą wersję na przyszłość, ale nie rozstrzyga, czy sekrety zostały już ujawnione, gdy skażony pakiet wheel lub obraz był aktywny.

Dla operatorów próg działania jest szeroki: każdy, kto zainstalował litellm==1.107.0, pobrał zgłoszony zagrożony zmienny tag lub uruchomił Pythona w narażonym środowisku, powinien uznać hosta albo kontener za potencjalnie naruszony. Dostępne doniesienia przemawiają za odtworzeniem środowiska z czystych obrazów lub środowisk oraz zmianą wszelkich poświadczeń chmurowych, API, SSH, bazodanowych i podobnych, dostępnych z tego środowiska wykonawczego.