Włamanie do LiteLLM ukrywano przez pięć miesięcy

Co wydarzyło się w pipeline budowania LiteLLM w marcu

Włamanie nie zaczęło się od samego LiteLLM. TeamPCP najpierw przejęła otwartoźródłowy skaner bezpieczeństwa Trivy, wykorzystując wyciekniętego tokena automatyzacji, co dało grupie około 20 dni niezauważonego dostępu do własnego repozytorium Trivy. W tym czasie grupa wymusiła (force-push) złośliwy kod w tagach wersji Trivy - konkretnych znacznikach wydań, do których odwołują się projekty zależne, gdy pobierają zależność.

Pipeline ciągłej integracji LiteLLM instalował Trivy bez przypięcia do konkretnej, zweryfikowanej wersji, więc przy następnym uruchomieniu automatycznie pobrał zatrutą wersję. Ta jedna nieprzypięta zależność była całą luką, której potrzebowała TeamPCP: złośliwy kod trafił do własnego procesu budowania LiteLLM, a stamtąd do dwóch opublikowanych pakietów, wersji 1.82.7 i 1.82.8 LiteLLM, przesłanych do Python Package Index.

Zabezpieczenie, któremu wszyscy ufają, i jak zostało ominięte

Większość programistów obawiających się złośliwych pakietów PyPI polega na fladze --ignore-scripts, która blokuje wykonywanie dowolnego kodu przez skrypty instalacyjne pakietu. Ładunek TeamPCP nie potrzebował skryptu instalacyjnego. Był ukryty w pliku .pth, pliku konfiguracji ścieżek Pythona, który sam interpreter wykonuje automatycznie przy każdym uruchomieniu, niezależnie od sposobu instalacji pakietu. Ten wybór projektowy to szczegół, który pominęły wszystkie nagłówki dotyczące tego włamania, i to właśnie on liczy się najbardziej dla każdego zespołu inżynierskiego, który sądził, że --ignore-scripts chroni go dokładnie przed tym typem ataku.

Po uruchomieniu ładunek przechwytywał klucze SSH, dane uwierzytelniające w chmurze AWS, Google Cloud i Azure, tokeny Kubernetes, zawartość plików .env oraz klucze API dostawców AI z każdej maszyny, na której zainstalowano zatruty pakiet. Skradzione dane były szyfrowane algorytmem AES-256 i wysyłane albo na domenę typosquattingową zaprojektowaną tak, by wyglądać jak legalny zasób LiteLLM lub Trivy, albo przesyłane bezpośrednio do repozytoriów na własnym koncie GitHub ofiary - szczegół, który pozwalał operacji wtopić się w normalnie wyglądającą aktywność programistyczną, zamiast wywołać oczywisty alarm o ruchu wychodzącym.

2500 firm, osiem wymienionych z nazwy w Europie i pięciomiesięczna luka

CloudSEK opublikował swoje badania 11 sierpnia 2026 roku, pięć miesięcy po marcowym naruszeniu, identyfikując ponad 2500 organizacji i około 434 000 pipeline'ów CI/CD jako potencjalnie narażonych - co firma nazywa największą jak dotąd ujawnioną w 2026 roku naruszeniem łańcucha dostaw AI. Wśród trafień wskazanych z wysoką pewnością przez CloudSEK znajdują się Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, fiński koncern energetyczny Fortum Oyj oraz reasekurator Munich Re, obejmujące produkcję, telekomunikację, kolej, finanse i ubezpieczenia w kilku europejskich jurysdykcjach.

CloudSEK wyraźnie podkreśla, że pojawienie się firmy w jej zbiorze danych nie jest automatycznym dowodem udanego włamania - ustalenie oznacza, że dane uwierzytelniające, domeny, repozytoria lub infrastruktura związane z tą organizacją pojawiły się w przechwyconych danych, a każda organizacja musi przeprowadzić własne dochodzenie, aby potwierdzić, co - jeśli cokolwiek - faktycznie zostało skradzione lub wykorzystane niewłaściwie. Bezsporna pozostaje pięciomiesięczna luka między marcowym włamaniem a sierpniowym ujawnieniem - okno, w którym każda z wymienionych organizacji mogła działać na infrastrukturze z przejętymi danymi uwierzytelniającymi bez żadnego publicznego ostrzeżenia, że doszło do naruszenia.

Co to oznacza dla każdego, kto zarządza narzędziami infrastruktury AI

Ostrzeżenie FLASH FBI z lipca 2026 roku dodaje niewygodny szczegół do osi czasu: dane uwierzytelniające przechwycone w marcu wciąż uznaje się za aktywne i nadające się do użycia miesiące później, a agencja spodziewa się, że TeamPCP lub powiązani z nią aktorzy wykorzystają je w przyszłych, niepowiązanych włamaniach, zamiast pozwolić im wygasnąć. Dla każdej organizacji, która uruchamiała wersje 1.82.7 lub 1.82.8 LiteLLM w produkcji lub CI w marcu 2026 roku, właściwa reakcja to nie czekanie na indywidualne potwierdzenie od CloudSEK lub LiteLLM - to potraktowanie każdych danych uwierzytelniających, które miały kontakt z tą pipeline budowania, jako przejętych i natychmiastowa ich rotacja, niezależnie od tego, czy jest to pięć miesięcy za późno, czy nie.

Strukturalna lekcja wykracza poza LiteLLM. Każda organizacja, która pozwala swojemu pipeline CI pobierać zależność narzędzi bezpieczeństwa, taką jak skaner, bez przypięcia jej do zweryfikowanej wersji, ma dokładnie taką samą lukę, jaką wykorzystała tu TeamPCP, a --ignore-scripts nie jest zabezpieczeniem, za jakie uważa je większość zespołów, wobec ładunku dostarczanego przez plik .pth. Europejscy odpowiedzialni za bezpieczeństwo, którzy zarządzają narzędziami infrastruktury AI zbudowanymi na tym samym otwartoźródłowym łańcuchu dostaw, powinni traktować to mniej jako historię LiteLLM, a bardziej jako zapowiedź tego, jak najprawdopodobniej zostanie dostarczone następne naruszenie narzędzi AI.

Czytaj dalej: 141 006 testów, trzy prawdziwe włamania  |  Micron: rok 2027 będzie trudniejszy niż 2026