23 marca opisaliśmy kompromitację Trivy'ego jako atak na zaufanie do automatyzacji i napisaliśmy tam zdanie, które wtedy było ostrożną hipotezą: raz przejęte zaufanie w automatyzacji może później służyć do ruchów bocznych, trwałości i rozszerzania promienia rażenia. Blast radius, dodaliśmy, był większy niż jeden release.
Dziś wiemy o ile.
Hudson Rock zdobył archiwum o rozmiarze 153 gigabajtów, zawierające 433 909 plików, i przypisał 118 829 zrzutów ze środowisk CI do 2488 domen korporacyjnych. Na liście są między innymi AWS, Samsung, Cisco, Salesforce, ServiceNow, Siemens, NVIDIA, Microsoft, Volkswagen, Deloitte, Boeing, FedEx i Orange.
Wszystko to wyciekło przez okno, które trwało czterdzieści minut.
Jak skaner bezpieczeństwa doprowadził do bramy AI
Łańcuch jest krótki i każde ogniwo działało dokładnie tak, jak zaprojektowano.
19 marca grupa TeamPCP — ta sama, o której pisaliśmy przy okazji Mini Shai-Huluda — przejęła pipeline Trivy'ego, otwartoźródłowego skanera podatności.
LiteLLM używał Trivy'ego we własnym procesie budowania. Automatycznie, jak każdy porządny projekt, który skanuje swój kod przed wydaniem. Zatruty skaner dostał więc legalny dostęp do środowiska runnera — i wykradł stamtąd tokeny publikacyjne do rejestru pakietów Pythona.
24 marca, używając tych tokenów, atakujący opublikowali dwie złośliwe wersje LiteLLM. Wisiały w rejestrze około czterdziestu minut. W tym czasie, jak podaje współzałożyciel Hudson Rock, doszło do ponad 430 tysięcy przypadków, w których zebrano miliony sekretów.
Zwróćmy uwagę na kształt tej drogi: narzędzie bezpieczeństwa → brama AI → dwa i pół tysiąca firm. Pierwszym ogniwem był program, którego jedynym zadaniem jest szukanie podatności w cudzym kodzie — i który z definicji musi mieć dostęp do wszystkiego, co buduje.
To jest ten sam kształt, który opisywaliśmy dwa dni temu przy Ghostjackingu, gdzie zablokowane przez firewall żądanie stało się kanałem dostawy. Tam mechanizm obronny wiernie zapisywał atak, a agent go wykonywał. Tutaj skaner wiernie skanował, a jego uprawnienia posłużyły do kradzieży kluczy. W obu przypadkach im lepiej narzędzie robi swoje, tym większą wartość ma dla atakującego.
Dlaczego akurat LiteLLM
W kwietniu opisywaliśmy inną lukę w tym samym projekcie i postawiliśmy wtedy tezę, że to nie nowa klasa ataku, tylko nowy dom — stare techniki przeprowadziły się do infrastruktury AI. Dzisiejsze dane pokazują, dlaczego ten dom jest szczególnie atrakcyjny.
LiteLLM to brama routująca zapytania do różnych dostawców modeli. Jej typowe środowisko wdrożeniowe trzyma klucze do każdego dostawcy, z którego korzysta zespół. Nie jedną parę poświadczeń — komplet.
To czyni z niej agregator poświadczeń z samego założenia. Przejęcie takiej biblioteki nie odsłania jednego zestawu kluczy. Odsłania wszystkie naraz.
To jest logika skarbca, którą opisywaliśmy przy Langflow, tylko że tym razem skarbiec nie stał u jednej ofiary. Stał w łańcuchu dostaw dwóch i pół tysiąca firm.
Zawartość archiwum to potwierdza. Zmienne GitLaba, klucze dostępowe AWS, sekrety Azure, klucze podpisujące Slacka, sekrety klienckie Salesforce, wewnętrzne tokeny JWT, tokeny npm, tokeny wdrożeniowe Bitbucketa, klucze API do Elastica — i klucze API do dostawców modeli AI.
Ładunek, którego nie trzeba było importować
Techniczny szczegół tej kampanii jest wart odnotowania, bo pokazuje, jak dojrzały jest ten rodzaj ataku.
Złośliwe wersje umieszczały w katalogu pakietów plik z rozszerzeniem .pth — mechanizm Pythona pozwalający wykonać kod przy starcie interpretera. Skutek: ładunek uruchamiał się za każdym razem, gdy startował Python, nawet jeśli aplikacja w ogóle nie importowała LiteLLM.
Trójstopniowy ładunek zbierał zmienne środowiskowe, czytał lokalne pliki konfiguracyjne — konfigurację Kubernetesa, poświadczenia AWS — próbował ruchu bocznego po klastrach i instalował trwały backdoor w systemd.
Wystarczyło mieć tę bibliotekę wśród zależności. Nie trzeba było jej używać.
Pięć miesięcy później klucze wciąż działają
Najbardziej niepokojąca część tej historii nie dotyczy marca, tylko dzisiaj.
W lipcu FBI wydało ostrzeżenie, w którym stwierdza, że powiązani aktorzy prawdopodobnie wykorzystają zebrane poświadczenia długo po zamknięciu pierwotnego okna włamania. Badacze potwierdzają, że część skradzionych kluczy pozostawała ważna miesiącami po marcowym ataku.
A wiele dotkniętych organizacji wciąż ich nie zrotowało — i tu podana przyczyna jest najbardziej pouczająca w całym tym materiale. Nie chodzi o zaniedbanie. Chodzi o to, że nie wiedzą, że ich to dotyczy. Nie mają żadnego mechanizmu, który powiązałby ich sekrety z tym konkretnym incydentem sprzed pięciu miesięcy.
Firma, której pipeline pobrał zatrutą wersję na czterdzieści minut w marcu, nie dostała o tym żadnego powiadomienia. Zależność zaktualizowała się sama przy następnym budowaniu. Nic nie przestało działać. Nic nie wyglądało źle.
I to jest właściwa lekcja z tej sprawy: przy kompromitacji trwającej czterdzieści minut w warstwie zależności brak sygnału jest stanem domyślnym. Nie ma alertu, nie ma incydentu do obsłużenia, nie ma nic, co skłoniłoby kogokolwiek do rotacji kluczy. Jest tylko cicho rosnąca liczba ważnych poświadczeń w cudzych rękach.
Od dziś krąg tych rąk się poszerzył, bo archiwum krąży poza pierwotnymi napastnikami.
Uczciwie: co wiemy, a czego nie
Kilka rzeczy trzeba postawić proporcjonalnie.
Skradzione poświadczenia nie są dowodem na dalsze włamania. Posiadanie klucza to nie to samo co jego użycie, a nikt nie wykazał, ile z tych 2488 organizacji zostało realnie zaatakowanych w następstwie.
Hudson Rock sprzedaje usługi wywiadu zagrożeń i zintegrował ten zbiór z własną platformą komercyjną, deklarując jednocześnie globalną akcję etycznego ujawnienia. To standardowy układ przy tego typu publikacjach i obowiązuje przy nim zwykłe zastrzeżenie — firma ma interes w tym, żeby sprawa wyglądała poważnie. Z drugiej strony sam mechanizm ataku został niezależnie zbadany przez kilka innych zespołów, a ostrzeżenie FBI pochodzi sprzed miesiąca i jest od tej publikacji niezależne.
Warto też zaznaczyć, że liczba 2488 to liczba domen, do których przypisano zrzuty, a nie liczba potwierdzonych włamań. Część z tych zrzutów może pochodzić ze środowisk testowych albo z pipeline'ów, w których nie było nic wrażliwego.
Co z tego wynika dla obrońcy
Rzecz pierwsza jest konkretna i pilna: sprawdź w historii swoich buildów, czy między 24 a 25 marca pobierałeś wersje 1.82.7 lub 1.82.8 LiteLLM. Jeśli tak — albo jeśli nie potrafisz tego ustalić — rotuj wszystko, co było wtedy dostępne w środowisku: poświadczenia chmurowe, tokeny rejestrów, sekrety CI, klucze API do dostawców modeli. Sprawdź też trwałość w systemd na maszynach budujących.
Rzecz druga jest szersza i wynika z roli Trivy'ego w tej historii. Narzędzia bezpieczeństwa w pipeline mają uprawnienia adekwatne do swojego zadania, czyli bardzo szerokie — muszą widzieć wszystko, co budujesz. To czyni je celami o wyjątkowej wartości. Warto zadać sobie pytanie, ile sekretów widzi twój skaner i czy naprawdę potrzebuje ich wszystkich, żeby wykonać swoją pracę.
Rzecz trzecia dotyczy bibliotek, które agregują dostęp. Brama do wielu dostawców modeli, menedżer wielu integracji, wspólny klient do kilku chmur — każde takie narzędzie zamienia rozproszone ryzyko w skoncentrowane. To bywa dobra decyzja architektoniczna, ale trzeba ją podejmować świadomie, z osobnym zabezpieczeniem środowiska, w którym taki agregator działa.
Rzecz czwarta jest procesowa i wynika z braku sygnału. Skoro nikt cię nie powiadomi, że twój build pobrał zatrutą wersję na czterdzieści minut pięć miesięcy temu, to jedynym mechanizmem, który to wyłapie, jest twoja własna historia zależności. Warto sprawdzić, czy przechowujesz pliki blokad i logi buildów na tyle długo, żeby dało się odpowiedzieć na takie pytanie z przeszłości.
Jedna myśl na koniec
W marcu napisaliśmy, że w CI/CD nie wystarczy już pytać, czy artefakt jest czysty — trzeba pytać, komu i czemu w procesie wykonania przyznano zaufanie. Wtedy była to teza. Dziś jest to rachunek: jeden skaner, jedna brama, czterdzieści minut, dwa i pół tysiąca firm.
Najbardziej niepokojące nie jest to, że łańcuch był długi. Jest to, że nikt na żadnym jego etapie nie zrobił niczego niewłaściwego. LiteLLM skanował swój kod przed wydaniem, bo tak należy. Tysiące zespołów pobierały aktualizacje zależności, bo tak należy. Pipeline'y budowały się automatycznie, bo po to istnieją.
Cała ta poprawność złożyła się w system, w którym jedno przejęte konto w jednym projekcie otwartoźródłowym przekłada się na sekrety dwóch i pół tysiąca firm — i w którym większość z nich do dziś o tym nie wie.
Źródła
Help Net Security — omówienie ustaleń Hudson Rock z pełnym opisem łańcucha od Trivy'ego do LiteLLM, cytatem o czterdziestominutowym oknie i ponad 430 tysiącach instancji oraz listą dotkniętych organizacji: https://www.helpnetsecurity.com/2026/08/13/litellm-breach-stolen-credentials-leak/
Hudson Rock — oryginalna analiza archiwum: 153 GB, 433 909 plików, 118 829 zrzutów przypisanych do 2488 domen, wraz z opisem hooka .pth i trójstopniowego ładunku: https://www.infostealers.com/article/largest-ai-supply-chain-breach-of-2026-litellm-hack-impacts-thousands-of-global-enterprises-claim-your-ethical-disclosure/
Cyber Press — potwierdzenie ustaleń śledczych zespołów Snyk, Trend Micro i Cycode dotyczących pochodzenia ataku z pipeline'u Trivy'ego oraz szczegółowa lista typów wykradzionych sekretów: https://cyberpress.org/litellm-breach-steals-ci-cd-credentials/
Cybernews — informacja o utrzymującej się ważności części poświadczeń miesiącami po ataku oraz zastrzeżenie, że wykradzione dane nie dowodzą dalszych włamań: https://cybernews.com/security/litellm-supply-chain-attack-credentials-leak/
TechJuice — kontekst lipcowego ostrzeżenia FBI o możliwości wykorzystania zebranych poświadczeń długo po zamknięciu okna włamania oraz o braku rotacji kluczy w wielu dotkniętych organizacjach: https://www.techjuice.pk/litellm-supply-chain-attack-2500-companies-434000-pipelines-credentials-leaked/
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł