CloudSEK łączy luty LiteLLM Supply Chain Breach z 2,500 organizacjami

Firma wywiadowcza CloudSEK poinformowała w raporcie opublikowanym 11 sierpnia 2026 r., że zidentyfikowała ponad 2 500 organizacji, które mogły zostać naruszone w wyniku skompromitowania łańcucha dostaw LiteLLM w marcu 2026 r., a także odtworzyła około 434 000 potencjalnie dotkniętych pipeline’ów CI/CD.

Liczby te pochodzą z raportu badawczego CloudSEK opracowanego na podstawie zestawu danych ofiar, który firma twierdzi, że jej zespół wywiadowczy uzyskał w ramach kampanii w marcu. Zestaw danych CloudSEK zawiera wysokiej jakości dopasowania powiązane z domenami korporacyjnymi, repozytoriami, poświadczeniami lub infrastrukturą należącą do organizacji, w tym NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales i London Stock Exchange Group. Firma jest wyraźna w kwestii znaczenia tych dopasowań: wysokiej jakości dopasowanie opisuje siłę dowodów łączących naruszone informacje z organizacją, a nie dowód na to, że organizacja została naruszona lub że atakujący wykorzystał skradzione informacje.

Incident, który jest centralnym punktem badań, rozpoczął się 24 marca 2026 r., kiedy grupa o nazwie TeamPCP opublikowała złośliwe wersje LiteLLM 1.82.7 i 1.82.8 w Python Package Index. Zainfekowane wydania były dostępne przez około 40 minut, zanim zostały usunięte. Okno to było wystarczające: potoki CI/CD instalują zależności automatycznie i często uruchamiają się z szerokimi uprawnieniami, więc zatruty pakiet rozprzestrzenia się przez systemy budowania korporacji z prędkością maszyny, bez jakiegokolwiek przeglądu przez deweloperów.

Jak jeden wyciekły token dotarł do 434 000 pipeline’ów

LiteLLM nie został bezpośrednio zaatakowany. Łańcuch opisany w raporcie CloudSEK zaczyna się o jeden krok wyżej, z Trivy, powszechnie używanym skanerem bezpieczeństwa open-source. Wyciekły token automatyzacji skojarzony ze skanerem został obrócony, ale nie został w pełni unieważniony, pozostawiając okno około 20 dni, w którym atakujący mogli wymusić nadanie złośliwego kodu nad opublikowanymi tagami wersji. Ponieważ potok budowania LiteLLM zainstalował Trivy nieprzypięte do menedżera pakietów systemu, skompromitowany skaner przepłynął prosto do budowy, a zatruta budowa wyprodukowała i opublikowała złośliwe wydania 1.82.7 i 1.82.8 w PyPI. Jeden niewycofany token, trzy narzędzia głęboko.

Projekt ładunku sprawił, że krótkie okno się liczyło. Wersja 1.82.8 upuściła złośliwy plik .pth do środowiska Python, a pliki .pth są wykonywane za każdym razem, gdy uruchamiany jest interpreter Python, niezależnie od tego, czy LiteLLM jest importowany. To całkowicie omija ochronę skryptów podczas instalacji. Na skompromitowanych uruchomieniach, kradzież poświadczeń, którą FBI nazywa SANDCLOCK, eskalowała do root i przeczesywała klucze SSH, poświadczenia AWS, Google Cloud i Azure, tokeny usług Kubernetes, pliki środowiskowe i sekrety CI/CD, zeskrobały wartości z pamięci procesu, które zwykle próbują maskować narzędzia. Klucze chmury pochodziły bezpośrednio z usługi metadanych instancji, używając dostępu, który już miał uruchomieni, a nie jakiegokolwiek exploitu. Dla budów AI konkretnie, łup obejmował klucze API LLM i konfigurację bramy: poświadczenia do całej sterty AI organizacji.

Skradzione dane były szyfrowane pod kluczem zakodowanym na stałe i wykradzione na adres URL z błędem pisarskim. Tam, gdzie wykradzenie nie powiodło się, złośliwe oprogramowanie utworzyło publiczne repozytorium w ramach konta ofiary w GitHub i przesłało skradzione materiały tam jako zasób wydania, co oznacza, że niektóre organizacje publikowały swoje własne sekrety w zwykłym widoku.

Dlaczego ryzyko przetrwało pakiet

Usunięcie złośliwych wydań z PyPI nie zakończyło incydentu. Każde skopiowane poświadczenie pozostaje ważne, dopóki właściciel nie obróci lub nie unieważni go, a usunięcie pakietu nie ma wpływu na to. FBI zrobiło to samo w FLASH advisory z 2 lipca 2026 r. na temat TeamPCP, ostrzegając, że organizacje, które zostały trafione przez kampanię, powinny traktować wykradzione dane i poświadczenia jako stałe ryzyko, ponieważ powiązani aktorzy prawdopodobnie wykorzystają je długo po początkowej infiltracji.

Doradztwo potwierdza zakres kampanii poza LiteLLM: TeamPCP trojanizował Trivy, skaner KICS Checkmarx, LiteLLM i SDK Python Telnyx, narzędzia osadzone w potokach przedsiębiorstw, infrastrukturze chmury i przepływach zabezpieczeń, oraz połączył infiltracje z wymuszeniem okupu, publikując nazwy ofiar na stronie wycieku publicznego i zagrażając ujawnieniem skradzionych danych.

Zalecane przez FBI środki zaradcze pokrywają się prawie dokładnie z tym, co łańcuch LiteLLM wykorzystał: przypnij GitHub Actions do sprawdzonych commitów zamiast pływających tagów wersji, obróć każdy sekret CI/CD i token publikacji dostępny podczas okna narażenia, egzekwuj najmniejszy zakres uprawnień na kontach usług i tokenach rejestru, oraz wyszukaj organizacje GitHub w poszukiwaniu repozytoriów o nazwach tpcp-docs lub docs-tpcp, które złośliwe oprogramowanie tworzy ze skradzionymi poświadczeniami.

Co oznaczają etykiety zaufania

CloudSEK sortuje organizacje w swoim zestawie danych według siły dowodów. Dopasowanie o wysokiej jakości opiera się na identyfikowalnych domenach korporacyjnych, repozytoriach, poświadczeniach lub infrastrukturze; dopasowanie o średniej jakości ma wiarygodne, ale słabsze wskaźniki. Żadna z tych etykiet nie jest dowodem udanego ataku, a firma podkreśla, że zestaw danych jest odtworzonym narażeniem: pojawienie się w nim oznacza, że skojarzone z organizacją informacje zostały zidentyfikowane i powinny zostać zbadane, a nie to, że naruszenie jest potwierdzone.

Należy zachować pewną ostrożność co do skali. Liczby 2 500 organizacji i 434 000 potoków pochodzą z zestawu danych, który CloudSEK uzyskał za pośrednictwem swoich kanałów wywiadowczych i odtworzył, a firma sprzedaje platformę monitorowania narażenia, AIVigil, na którą wskazuje to badanie. Żadne z tego nie podważa kampanii pod spodem: kompromitacja LiteLLM, jej miejsce w szerszej operacji TeamPCP oraz klasy poświadczeń, które są na ryzyko, potwierdzone są przez doradztwo FBI i przez rekord incydentu z marca.

CloudSEK opublikował bezpłatny sprawdzacz narażenia, gdzie organizacje mogą sprawdzić, czy ich infrastruktura pojawia się w zestawie danych. Jego wskazówki dla każdego dopasowania są takie, aby traktować każde poświadczenie, które dotknięty proces mógł przeczytać, jako potencjalnie narażone, dopóki nie zostanie zweryfikowane, przeglądać dzienniki dostępu w systemach chmury, kontroli źródła, rejestru i klastra, oraz obracać szeroko, a nie tylko klucz LiteLLM lub klucz dostawcy modelu. Dla organizacji, które uruchomiły dotknięte wersje w marcu, decyzja o rotacji ma już pięciomiesięczny zegar.