Wyciek klucza głównego LiteLLM doprowadził do przejęcia pipeline’u wydawniczego i kradzieży tokenów GitHub

Wprowadzenie do problemu / definicja

Incydent dotyczący LiteLLM pokazuje, jak pojedynczy błąd w zarządzaniu sekretami może przerodzić się w poważny atak na łańcuch dostaw oprogramowania. W tym przypadku ujawniony klucz główny platformy agentowej otworzył drogę do przejęcia dostępu operacyjnego, pozyskania tokenów GitHub o zbyt szerokich uprawnieniach oraz modyfikacji procesu publikacji pakietów i obrazów kontenerowych.

To przykład nowoczesnej kompromitacji typu supply chain, w której celem nie jest wyłącznie pojedynczy serwer, lecz zaufany mechanizm dystrybucji oprogramowania do użytkowników końcowych.

W skrócie

Źródłem incydentu był klucz główny LiteLLM, który został przypadkowo ujawniony w publicznym repozytorium w maju 2026 roku. Mimo wykrycia problemu sekret nie został skutecznie unieważniony, co pozostawiło długie okno ekspozycji.

W październiku 2026 roku napastnik wykorzystał ten dostęp do przejęcia tokenu GitHub CLI, pozyskania kolejnych poświadczeń utrzymaniowych i zmiany pipeline’u wydawniczego. Efektem było opublikowanie złośliwej wersji pakietu litellm==1.107.0 oraz skażonych obrazów kontenerowych.

wykorzystanie nieodwołanego sekretu z publicznego repozytorium,
kradzież tokenów GitHub i innych poświadczeń środowiskowych,
modyfikacja procesu release w repozytorium,
dystrybucja złośliwego artefaktu do zaufanych kanałów.

Kontekst / historia

Według dostępnej rekonstrukcji zdarzeń problem rozpoczął się 27 maja 2026 roku, gdy do publicznego repozytorium testowego trafił plik konfiguracyjny zawierający klucz główny wdrożenia platformy agentowej LiteLLM. Choć commit został usunięty, sam sekret nie został finalnie odwołany.

10 października 2026 roku atakujący użył tego klucza do uzyskania dostępu do środowiska i przechwycenia tokenu GitHub CLI wykorzystywanego przez agentów chmurowych. Token był powiązany z kontem o wysokich uprawnieniach, co znacząco zwiększyło zakres możliwych działań.

Następnie uruchomiono krótkotrwałe workflowy w repozytoriach wewnętrznych, których zadaniem było wykradanie kolejnych tokenów maintainerów oraz innych sekretów. Kulminacja nastąpiła 21 października 2026 roku, kiedy napastnik zmienił konfigurację procesu release i opublikował złośliwy pakiet oraz obrazy kontenerowe.

Analiza techniczna

Atak miał charakter wieloetapowy. Pierwszym etapem było wykorzystanie sekretu nadrzędnego zapewniającego dostęp do platformy orkiestrującej agentów. Z tego środowiska wyciągnięto token GitHub CLI z nadmiernymi uprawnieniami, a następnie przygotowano tymczasowe gałęzie i workflowy GitHub Actions uruchamiane przy zdarzeniach typu push.

Workflowy były maskowane jako zwykłe zmiany konfiguracyjne i działały na krótko istniejących branchach, co utrudniało ich wykrycie. Ich celem było przejęcie kolejnych danych uwierzytelniających oraz sekretów środowiskowych, w tym tokenów GitHub, kluczy aplikacyjnych, danych dostępowych do usług AI, baz danych oraz innych zasobów wspierających proces developmentu i bezpieczeństwa.

Najgroźniejszy element incydentu stanowił jednak sam artefakt litellm==1.107.0. Złośliwa wersja została przygotowana tak, aby uruchamiać kod automatycznie przy starcie interpretera Python, nawet bez bezpośredniego importu biblioteki przez aplikację. Wykorzystano do tego mechanizmy startowe osadzone w środowisku site-packages, w tym pliki .pth oraz sitecustomize.py.

Payload pełnił dwie główne funkcje. Po pierwsze działał jako stealer, zbierając zmienne środowiskowe, klucze SSH, tokeny Git, poświadczenia do chmury i narzędzi AI. Po drugie zawierał komponent backdoor, który umożliwiał pobieranie i wykonywanie dalszego kodu, co dawało napastnikowi możliwość rozwoju infekcji zależnie od wartości przejętego hosta.

Konsekwencje / ryzyko

Skutki incydentu wykraczają poza sam pakiet Python. Jeżeli organizacja zainstalowała skażoną wersję lub pobrała zainfekowany obraz kontenera, należy przyjąć założenie pełnej kompromitacji środowiska wykonawczego. Dotyczy to zwłaszcza serwerów CI, środowisk deweloperskich, bram LLM i hostów przechowujących liczne tokeny integracyjne.

Dodatkowe ryzyko wynika z faktu, że złośliwy kod aktywował się przy starcie interpretera Python. Oznacza to, że samo usunięcie biblioteki mogło nie wystarczyć, jeśli w systemie pozostały komponenty startowe zapisane poza katalogiem aplikacji. Taki scenariusz zwiększa ryzyko niepełnej remediacji i dalszej obecności mechanizmów infekcji.

Z perspektywy bezpieczeństwa łańcucha dostaw incydent ten potwierdza, że przejęcie jednego sekretu lub jednego workflow może skutkować masową dystrybucją złośliwego kodu. Szczególnie niebezpieczne są tokeny organizacyjne o szerokim zakresie oraz brak separacji obowiązków przy publikacji release’ów.

Rekomendacje

Organizacje, które mogły pobrać wersję 1.107.0 lub powiązane obrazy, powinny traktować takie systemy jako naruszone. W praktyce oznacza to potrzebę izolacji hostów, analizy artefaktów startowych Pythona, kontroli katalogów site-packages oraz pełnej rotacji sekretów obecnych w środowisku podczas działania złośliwego pakietu.

unieważnić i ponownie wystawić tokeny GitHub, klucze API, sekrety chmurowe i poświadczenia bazodanowe,
przeanalizować aktywne sesje i tokeny aplikacyjne, a nie ograniczać się wyłącznie do zmiany haseł,
zweryfikować integralność pipeline’ów release, workflowów GitHub Actions oraz ustawień ochrony branchy,
wymuszać minimalne uprawnienia dla tokenów automatyzacji i kont organizacyjnych,
wdrożyć skanowanie sekretów w commitach, historii repozytoriów i logach,
stosować kontrolę pochodzenia artefaktów, pinowanie wersji oraz weryfikację integralności pakietów,
wdrożyć rozdzielenie ról pomiędzy inicjowanie i zatwierdzanie publikacji.

W środowiskach AI i LLM szczególne znaczenie ma także ograniczanie ekspozycji logów, odpowiedzi modeli i danych sesyjnych, jeśli mogą one zawierać tokeny lub inne wrażliwe informacje.

Podsumowanie

Przypadek LiteLLM jest czytelnym przykładem nowoczesnego ataku supply chain, w którym punktem wejścia był stary, nieodwołany sekret, a końcowym celem zaufany pipeline publikacji oprogramowania. Napastnik połączył błędy w zarządzaniu kluczami, nadmierne uprawnienia tokenów GitHub, krótkotrwałe workflowy do kradzieży sekretów oraz techniki trwałego uruchamiania kodu w Pythonie.

Dla zespołów bezpieczeństwa i DevSecOps najważniejszy wniosek jest jednoznaczny: ochrona procesu release, rygorystyczna kontrola sekretów i ścisła minimalizacja uprawnień są dziś równie istotne jak klasyczne zabezpieczenia infrastruktury produkcyjnej.