Atak na LiteLLM: Jak skompromitowany skaner bezpieczeństwa stał się bronią w ataku na łańcuch dostaw

Utworzone przez Dawid Bakaj • sobota, 28.03.2026, 11:42 • Narzędzia cybersecurity

Atak na LiteLLM: Jak skompromitowany skaner bezpieczeństwa stał się bronią w ataku na łańcuch dostaw

W świecie cyberbezpieczeństwa często powtarza się, że jesteśmy tak silni, jak nasze najsłabsze ogniwo. Incydent z 24 marca 2026 roku, którego celem stała się niezwykle popularna biblioteka Python – LiteLLM – w brutalny sposób przypomniał, że tym najsłabszym ogniwem może być narzędzie, któremu ufamy najbardziej. Atak na LiteLLM, przeprowadzony przez znaną grupę cyberprzestępczą TeamPCP, nie był prostym włamaniem. Był to wieloetapowy, precyzyjnie zaplanowany atak na łańcuch dostaw oprogramowania, w którym skaner bezpieczeństwa został przekształcony w broń, a zaufanie deweloperów stało się głównym wektorem kompromitacji. Zrozumienie, jak doszło do ataku na LiteLLM i jakie lekcje płyną z tego incydentu, jest kluczowe dla każdej organizacji, która tworzy, wdraża lub wykorzystuje nowoczesne oprogramowanie.

Atak ten stanowi doskonały przykład zagrożenia kaskadowego, gdzie pierwotna kompromitacja jednego narzędzia prowadzi do fali kolejnych, znacznie poważniejszych w skutkach incydentów. LiteLLM, biblioteka służąca jako zunifikowany interfejs dla ponad 100 dostawców modeli językowych (LLM) i posiadająca ponad 40 000 gwiazdek na GitHubie, stała się celem ze względu na swoją strategiczną pozycję w ekosystemie sztucznej inteligencji. Przechwycenie kontroli nad nią oznaczało potencjalny dostęp do kluczy API i wrażliwych danych tysięcy projektów i firm na całym świecie.

Anatomia ataku kaskadowego – od Trivy do LiteLLM

Aby w pełni zrozumieć, co stało się z LiteLLM, musimy cofnąć się o kilka dni przed głównym incydentem. Cała operacja rozpoczęła się 19 marca 2026 roku od kompromitacji popularnego skanera podatności open-source – Trivy. To właśnie ten pierwszy krok umożliwił atakującym przeprowadzenie znacznie bardziej zaawansowanej operacji.

Etap 1: Kompromitacja narzędzia bezpieczeństwa (19 marca 2026)

Grupa TeamPCP (znana również jako PCPcat, Persy_PCP, ShellForce czy DeadCatx3) przeprowadziła atak na oficjalne repozytoria Trivy na GitHubie. Atakujący zdołali nadpisać 76 z 77 tagów wersji w repozytorium aquasecurity/trivy-action oraz wszystkie siedem w aquasecurity/setup-trivy. Zmodyfikowane tagi wskazywały na złośliwe commity, które zawierały kod kradnący dane uwierzytelniające z procesów CI/CD (źródło). Tego samego dnia zespół Trivy wykrył i usunął złośliwe artefakty, jednak szkody już zostały wyrządzone – dane uwierzytelniające z wielu potoków CI/CD, które w tym krótkim oknie czasowym pobrały zatrutą wersję, zostały eksfiltrowane (źródło). Incydent ten został sklasyfikowany jako CVE-2026-33634 i otrzymał ocenę CVSS 9.4, co podkreśla jego krytyczną wagę.

Etap 2: Niezabezpieczony potok CI/CD staje się furtką (19-23 marca 2026)

W tym miejscu ujawnia się kluczowe zaniedbanie w procesach bezpieczeństwa projektu LiteLLM. Ich potok ciągłej integracji i ciągłego dostarczania (CI/CD), zdefiniowany w skrypcie ci_cd/security_scans.sh, instalował Trivy za pomocą polecenia sudo apt-get install trivy. To polecenie nie „przypinało” wersji do konkretnej, zweryfikowanej kompilacji. W efekcie, podczas jednego z uruchomień, potok LiteLLM pobrał złośliwą wersję Trivy v0.69.4.

Zatenty skaner, zamiast szukać podatności, sam stał się złośliwym oprogramowaniem. Jego kod został zaprojektowany do przeszukiwania pamięci procesów (/proc/<pid>/mem) w poszukiwaniu wrażliwych danych. W ten sposób, pomimo mechanizmów maskowania sekretów stosowanych przez GitHub, atakującym udało się wyodrębnić z pamięci kluczowy sekret: PYPI_PUBLISH, czyli token autoryzacyjny uprawniający do publikowania nowych wersji pakietu LiteLLM w oficjalnym repozytorium PyPI (źródło). Był to moment, w którym atakujący zdobyli „klucze do królestwa”.

Etap 3: Publikacja złośliwych wersji (24 marca 2026)

Mając w ręku token PyPI, grupa TeamPCP mogła działać. Nie musieli modyfikować kodu źródłowego w repozytorium Git, co mogłoby wzbudzić podejrzenia. Zamiast tego, opublikowali bezpośrednio w repozytorium PyPI dwie nowe, zbackdoorowane wersje biblioteki:

• 10:39 UTC: Opublikowano litellm==1.82.7, zawierającą złośliwy ładunek ukryty w pliku proxy_server.py.
• 10:52 UTC: Opublikowano kolejną wersję, litellm==1.82.8.

Złośliwe pakiety pozostawały dostępne publicznie przez około pięć godzin, zanim zostały zidentyfikowane i usunięte. To wystarczająco dużo czasu, aby automatyczne systemy wdrożeń i deweloperzy na całym świecie pobrali zainfekowane wersje (źródło). Zespół LiteLLM szybko potwierdził, że kompromitacja ich konta PyPI była bezpośrednio powiązana z wcześniejszym incydentem dotyczącym Trivy.

Techniczna analiza złośliwego ładunku

Mechanizm działania złośliwego oprogramowania zaszytego w LiteLLM był równie wyrafinowany co sam wektor ataku. Atakujący zadbali o to, by payload był trudny do wykrycia i aktywował się automatycznie, maksymalizując potencjalny zasięg.

Ukryta aktywacja przez pliki .pth

Najbardziej podstępnym elementem technicznym było wykorzystanie plików .pth. W środowisku Pythona, pliki z takim rozszerzeniem, umieszczone w odpowiednim katalogu, są automatycznie przetwarzane przez interpreter podczas jego uruchamiania. Oznacza to, że złośliwy kod wykonuje się samoczynnie zaraz po instalacji pakietu, bez konieczności jawnego importowania go w kodzie aplikacji (import litellm). Dzięki temu payload aktywował się w niemal każdym procesie Pythona uruchomionym w zainfekowanym środowisku, co gwarantowało jego działanie i utrudniało analizę statyczną (źródło). Celem były przede wszystkim środowiska, w których przetwarzane są klucze API do modeli LLM, takie jak klucze OpenAI czy Anthropic.

Trzyetapowy payload

Po aktywacji, złośliwy kod realizował trzy główne cele:

1. Zbieranie danych uwierzytelniających: Pierwszym zadaniem było aktywne skanowanie pamięci i procesów w poszukiwaniu wszelkich cennych sekretów – kluczy API, tokenów dostępowych, haseł i innych danych uwierzytelniających.
2. Szyfrowana eksfiltracja: Wszystkie zebrane dane były szyfrowane, a następnie wysyłane na serwer kontrolowany przez atakujących, działający pod domeną models.litellm.cloud. Co istotne, domena ta została zarejestrowana zaledwie dzień przed atakiem, 23 marca 2026 roku, co wskazuje na staranne przygotowanie operacji (źródło).
3. Utrzymanie dostępu i propagacja: Ostatnim etapem było wdrożenie trwałego backdoora, zapewniającego atakującym stały dostęp do skompromitowanego systemu. Payload zawierał również komponenty robaka (worm), zaprojektowanego do automatycznego rozprzestrzeniania się w klastrach Kubernetes, co mogło prowadzić do masowej kompromitacji infrastruktury chmurowej ofiar (źródło).

Skala zagrożenia i potencjalne konsekwencje

Chociaż dokładne liczby pobrań złośliwych wersji nie zostały publicznie potwierdzone, popularność LiteLLM sugeruje, że potencjalny zasięg ataku był ogromny. Biblioteka ta jest często wykorzystywana jako kluczowy komponent w bramkach API do modeli AI, serwerach MCP (Model Control Plane) oraz narzędziach do orkiestracji pracy z LLM.

Głównym zagrożeniem była kradzież kluczy API do usług takich jak OpenAI, Google AI, Anthropic i innych. Dla firm intensywnie korzystających z tych technologii, utrata kluczy oznacza nie tylko gigantyczne straty finansowe (atakujący mogą wykorzystywać je do generowania zapytań na koszt ofiary), ale także ryzyko wycieku wrażliwych danych przetwarzanych przez modele.

Atak ten uwypuklił również problem zależności tranzytywnych (transitive dependencies). Wiele firm mogło nawet nie zdawać sobie sprawy, że korzysta z LiteLLM. Biblioteka ta często jest zależnością innych, większych frameworków i narzędzi. Wystarczyło, że deweloper używał narzędzia X, które w swoich zależnościach miało LiteLLM, aby jego środowisko zostało zainfekowane. Atak nie wymagał żadnych zmian w kodzie źródłowym czy procesach wydawniczych, co czyniło go niewidocznym dla standardowych mechanizmów kontroli.

Warto zaznaczyć, że oficjalne obrazy Dockerowe LiteLLM Proxy nie były podatne na ten atak. Powodem była dobra praktyka stosowana w ich przypadku – plik requirements.txt zawierał przypięte, konkretne wersje zależności, co uniemożliwiło automatyczne pobranie złośliwych pakietów 1.82.7 i 1.82.8. To ważna lekcja, pokazująca, jak proste mechanizmy mogą zapobiec katastrofie.

Działania TeamPCP wpisują się w szerszą kampanię tej grupy, która wykorzystuje taktyki znane jako Shai-Hulud 2.0. Podobne ataki były wymierzone również w inne narzędzia deweloperskie, takie jak Checkmarx KICS, co sugeruje, że łańcuchy dostaw oprogramowania stały się dla tej grupy priorytetowym celem.

Kluczowe lekcje i praktyczne zalecenia dla organizacji

Incydent z LiteLLM to gorzka, ale cenna lekcja dla całej branży. Podkreśla, że w nowoczesnym świecie tworzenia oprogramowania, opartym na setkach zewnętrznych zależności, zaufanie musi być ograniczone i stale weryfikowane. Poniżej przedstawiamy najważniejsze wnioski i zalecenia, które każda organizacja powinna wdrożyć.

1. Bezwzględne przypinanie wersji wszystkich zależności (Dependency Pinning)

   To najważniejsza i najbardziej fundamentalna lekcja. Nigdy nie należy ufać tagom takim jak :latest czy poleceniom instalującym najnowszą dostępną wersję. Tagi są mutowalne i mogą zostać w każdej chwili nadpisane, by wskazywać na złośliwy kod.

   • Pakiety PyPI/NPM: Zawsze używaj plików requirements.txt (Python) lub package-lock.json (Node.js) z dokładnymi numerami wersji (np. litellm==1.82.6). Unikaj operatorów takich jak ^ czy >=.
   • Akcje GitHub (GitHub Actions): Zamiast używać tagów wersji (np. actions/checkout@v3), przypinaj akcje do konkretnego, niezmiennego hasha commita (np. actions/checkout@a12a3943b4bdde767164d792f33f40b04645d846).
   • Obrazy Docker: Nigdy nie używaj tagu :latest w środowiskach produkcyjnych. Zamiast tego, odwołuj się do obrazów poprzez ich skrót (digest SHA256), który jednoznacznie identyfikuje konkretną warstwę obrazu (np. ubuntu@sha256:45b23dee...).
   • Pakiety systemowe w CI/CD: Unikaj poleceń typu apt-get install <nazwa-pakietu> w potokach automatyzacji. Zamiast tego, korzystaj ze zweryfikowanych, wewnętrznych repozytoriów pakietów lub bazuj na obrazach kontenerów, które mają już preinstalowane i sprawdzone narzędzia.

2. Narzędzia bezpieczeństwa jako potencjalny wektor ataku

   Paradoksalnie, narzędzie, które miało chronić LiteLLM, stało się wektorem ataku. To pokazuje, że musimy traktować nasz „toolchain” bezpieczeństwa z taką samą, a nawet większą ostrożnością jak kod produkcyjny. Każde narzędzie instalowane w potoku CI/CD, każdy skaner i każdy system monitorujący to potencjalny cel. Należy je również obejmować zasadą przypinania wersji i minimalizacji uprawnień.

3. Zwiększenie widoczności zależności tranzytywnych

   Organizacje muszą wiedzieć, z czego składa się ich oprogramowanie. Niezbędne staje się wdrożenie mechanizmów generowania i analizy SBOM (Software Bill of Materials) – szczegółowej listy wszystkich komponentów, bibliotek i ich zależności, które składają się na finalną aplikację. Narzędzia do analizy składu oprogramowania (SCA – Software Composition Analysis) pozwalają na monitorowanie nie tylko bezpośrednich, ale i pośrednich zależności pod kątem znanych podatności i ryzyk licencyjnych.

4. Rygorystyczne zarządzanie sekretami w CI/CD

   Kradzież tokenu PYPI_PUBLISH była możliwa, ponieważ był on dostępny w środowisku wykonawczym potoku. Należy wdrożyć zasadę jak najmniejszych uprawnień (Principle of Least Privilege) dla sekretów. Warto rozważyć:

   • Krótkożyjące tokeny: Zamiast statycznych, długowiecznych sekretów, należy używać mechanizmów generujących tokeny o ograniczonym czasie życia, na przykład poprzez integrację z systemami OIDC (OpenID Connect).
   • Segregacja uprawnień: Procesy skanujące kod nie powinny mieć dostępu do sekretów wydawniczych. Należy rozdzielić etapy CI (budowanie, testowanie, skanowanie) od CD (wdrażanie, publikowanie) i przyznać im odrębne, minimalne zestawy uprawnień.

Jak możemy pomóc?

Atak na LiteLLM dowodzi, że bezpieczeństwo łańcucha dostaw oprogramowania (Software Supply Chain Security) oraz procesów CI/CD to już nie niszowy, a absolutnie krytyczny obszar dla każdej nowoczesnej firmy. Teoretyczna wiedza to jedno, ale praktyczne wdrożenie zabezpieczeń w złożonych, dynamicznych środowiskach deweloperskich to zupełnie inne wyzwanie.

W VIPentest specjalizujemy się w identyfikacji i eliminacji tego typu zagrożeń. Nasz zespół ekspertów może pomóc Twojej organizacji poprzez:

• Audyty bezpieczeństwa potoków CI/CD: Analizujemy konfigurację Twoich procesów automatyzacji, identyfikując słabe punkty, takie jak nieprzypięte zależności, nadmiarowe uprawnienia czy ryzyko kradzieży sekretów.
• Testy penetracyjne aplikacji i infrastruktury: Symulujemy zaawansowane ataki, aby zweryfikować realną odporność Twoich systemów na techniki stosowane przez grupy takie jak TeamPCP.
• Wdrożenie praktyk DevSecOps: Pomagamy zintegrować bezpieczeństwo z całym cyklem życia oprogramowania (SDLC), od projektowania po wdrożenie i utrzymanie.
• Doradztwo w zakresie bezpieczeństwa łańcucha dostaw: Wspieramy w wyborze i konfiguracji narzędzi do analizy SBOM i SCA oraz w budowaniu polityk zarządzania zależnościami.

Zabezpieczenie łańcucha dostaw to inwestycja, która chroni nie tylko Twoją firmę, ale także Twoich klientów i całą branżę. Jeśli chcesz upewnić się, że Twoje procesy są odporne na ataki nowej generacji, skontaktuj się z nami.

Chętnie porozmawiamy o Twoich wyzwaniach. Kontakt.

Checklista: Zabezpieczenia łańcucha dostaw oprogramowania

FAQ