LiteLLM 1.107.0 skompromitowany w ataku na łańcuch dostaw. Złośliwy pakiet kradł sekrety i instalował backdoora

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych incydentów bezpieczeństwa, ponieważ wykorzystują zaufane kanały dystrybucji do dostarczania złośliwego kodu. W przypadku LiteLLM problem dotyczył skompromitowanej wersji 1.107.0, która została opublikowana jako legalny pakiet i mogła trafić bezpośrednio do środowisk deweloperskich, testowych oraz produkcyjnych.

To szczególnie niebezpieczny scenariusz, ponieważ ofiara nie musi paść ofiarą klasycznego phishingu ani ręcznie uruchamiać podejrzanego pliku. Wystarczy instalacja lub uruchomienie zaufanego komponentu, aby złośliwy kod zaczął działać automatycznie i uzyskał dostęp do sekretów obecnych w środowisku.

W skrócie

Skompromitowana wersja LiteLLM 1.107.0 była dystrybuowana przez PyPI oraz powiązane obrazy Docker. Złośliwy kod uruchamiał się automatycznie przy starcie interpretera Pythona, jeszcze zanim aplikacja faktycznie zaczęła korzystać z biblioteki.

zagrożona była wersja LiteLLM 1.107.0,
ładunek zawierał mechanizm kradzieży poświadczeń,
drugi komponent działał jak backdoor umożliwiający zdalne wykonanie kodu,
incydent objął zarówno pakiet PyPI, jak i oficjalne obrazy kontenerowe,
organizacje powinny traktować wszystkie dostępne sekrety jako potencjalnie ujawnione.

Kontekst / historia

LiteLLM jest popularną biblioteką oraz warstwą pośrednią używaną do integracji z dostawcami modeli językowych. W praktyce oznacza to, że komponent ten często operuje na bardzo wrażliwych danych, takich jak klucze API, sekrety środowiskowe, dane konfiguracyjne modeli czy poświadczenia do usług chmurowych.

Incydent z października 2026 roku wpisuje się w szerszy trend kompromitacji ekosystemów open source i procesów CI/CD. W tym przypadku nie chodziło o zwykły błąd programistyczny, lecz o naruszenie procesu publikacji. Według dostępnych informacji atak miał być powiązany z przejęciem tokenów OAuth związanych z GitHub CLI i kontami inżynierów uczestniczących w procesie wydawniczym.

Analiza techniczna

Kluczowym elementem incydentu był obecny w złośliwych kołach binarnych plik cook.pth. To ważny szczegół techniczny, ponieważ pliki z rozszerzeniem .pth mogą powodować automatyczne wykonanie kodu podczas inicjalizacji interpretera Pythona. W efekcie malware uruchamiał się natychmiast po starcie procesu, niezależnie od tego, czy aplikacja zdążyła już zaimportować LiteLLM.

Po aktywacji komponent inicjujący uruchamiał moduł zbierający dane. Jego zadaniem było przejęcie szerokiego zakresu sekretów i artefaktów z hosta oraz środowiska użytkownika.

poświadczeń dostawców chmurowych,
kluczy prywatnych SSH i innych materiałów kryptograficznych,
tokenów oraz konfiguracji narzędzi AI,
danych z przeglądarek opartych o Chromium i Firefox,
zmiennych środowiskowych,
sekretów związanych z LiteLLM Proxy i konfiguracją modeli.

Zebrane informacje były następnie archiwizowane i eksfiltrowane do infrastruktury kontrolowanej przez atakującego. Równolegle działał także drugi komponent o charakterze backdoora, który okresowo pobierał i uruchamiał dodatkowy kod Python dostarczony z zewnątrz. To znacząco zwiększa wagę incydentu, ponieważ otwiera drogę nie tylko do jednorazowej kradzieży danych, ale również do dalszej, trwałej kompromitacji środowiska.

Ważne jest również to, że zagrożenie nie ograniczało się wyłącznie do pakietu w repozytorium PyPI. Kompromitacja objęła także oficjalne obrazy kontenerowe, co rozszerzyło powierzchnię ataku na wdrożenia produkcyjne, systemy testowe, pipeline’y CI oraz środowiska uruchamiane automatycznie na podstawie znanych tagów obrazów.

Konsekwencje / ryzyko

Skutki tego incydentu należy oceniać jako wysokie, a w części organizacji nawet krytyczne. Szczególnie zagrożone są podmioty wykorzystujące LiteLLM jako centralny punkt dostępu do wielu modeli i dostawców usług AI, ponieważ taki komponent często agreguje dużą liczbę cennych sekretów.

wyciek poświadczeń do usług chmurowych i platform AI,
przejęcie kluczy prywatnych używanych w administracji i automatyzacji,
dostęp do danych przeglądarek administratorów i deweloperów,
możliwość ruchu bocznego po zdobyciu sekretów,
utrzymanie dostępu dzięki zdalnie sterowanemu backdoorowi,
kompromitacja systemów korzystających z oficjalnych obrazów kontenerowych.

Z perspektywy obronnej istotne jest to, że samo usunięcie pakietu nie rozwiązuje problemu. Jeżeli złośliwa wersja została uruchomiona choć raz, należy przyjąć, że wszystkie sekrety dostępne z poziomu tego procesu mogły zostać ujawnione. W praktyce oznacza to konieczność pełnej rotacji poświadczeń oraz analizy śladów kompromitacji na hostach, runnerach CI/CD i w kontenerach.

Rekomendacje

Organizacje, które mogły pobrać lub uruchomić LiteLLM 1.107.0, powinny przejść w tryb reagowania na incydent. Priorytetem jest szybka identyfikacja wszystkich systemów, na których zainstalowano zagrożoną wersję pakietu lub odpowiadające jej obrazy.

zidentyfikować hosty, kontenery i pipeline’y używające LiteLLM 1.107.0,
odwołać i wymienić wszystkie sekrety dostępne dla procesu,
sprawdzić cache artefaktów, rejestry obrazów i środowiska developerskie,
przeprowadzić analizę forensic oraz threat hunting,
szukać nietypowych połączeń wychodzących i śladów pobierania dodatkowego kodu.

W zakresie długofalowej ochrony warto wdrożyć bardziej rygorystyczne mechanizmy bezpieczeństwa dla procesu budowy i publikacji oprogramowania.

stosować pinning wersji i digestów pakietów oraz obrazów,
korzystać z zaufanych wewnętrznych mirrorów i repozytoriów artefaktów,
skanować zależności i obrazy pod kątem złośliwych zmian,
rozdzielić uprawnienia w procesie release management,
skracać czas życia tokenów i ograniczać zakres dostępu,
monitorować integralność pipeline’ów oraz podpisywać artefakty.

Dodatkowo środowiska budujące i uruchamiające aplikacje powinny działać zgodnie z zasadą minimalnych uprawnień. Proces instalacji pakietu nie powinien mieć nieograniczonego dostępu do sekretów, a stacje robocze deweloperów nie powinny jednocześnie przechowywać kluczy produkcyjnych i danych administracyjnych.

Podsumowanie

Incydent LiteLLM 1.107.0 to wyjątkowo groźny przykład ataku na łańcuch dostaw, w którym legalny kanał dystrybucji został wykorzystany do dostarczenia stealera i backdoora. Najważniejszy wniosek jest jednoznaczny: zaufanie do popularnego pakietu lub oficjalnego obrazu nie może zastępować kontroli integralności, monitoringu i dojrzałego zarządzania sekretami.

W organizacjach rozwijających rozwiązania AI ryzyko jest jeszcze większe, ponieważ pojedynczy komponent pośredniczący może zapewniać dostęp do wielu usług, modeli i środowisk jednocześnie. Każdy kontakt z wersją 1.107.0 powinien być traktowany jako potencjalna kompromitacja wymagająca pełnej rotacji poświadczeń i dokładnej analizy incydentu.