97 milionów pobrań i jeden złośliwy commit – jak hakerzy zatruli popularną bibliotekę AI?

24 marca 2025 na PyPI pojawiły się dwie złośliwe wersje biblioteki LiteLLM – 1.82.7 i 1.82.8. Wystarczyło zainstalować, by uruchomić kod atakującego. Dla firm budujących na LLM to nie tylko news, to dzwonek alarmowy. Pokazuje, jak kruchy jest łańcuch dostaw w AI i dlaczego standardowe procedury bezpieczeństwa nie wystarczą.

97 milionów pobrań i jeden złośliwy commit – jak hakerzy zatruli popularną bibliotekę AI?

LiteLLM to open‑source’owa bramka API, która pozwala łączyć się z wieloma modelami językowymi – od GPT‑4 przez Claude po lokalne modele – za pomocą jednego interfejsu. Jej popularność jest ogromna: według danych PyPI biblioteka została pobrana ponad 97 milionów razy [1]. Używają jej startupy, średnie firmy i korporacje, które budują własne aplikacje AI bez konieczności pisania integracji z każdym dostawcą osobno.

24 marca 2025 na PyPI pojawiły się wersje 1.82.7 i 1.82.8. Nie były to oficjalne wydania autora – ktoś podmienił paczkę, wstrzykując złośliwy kod. Mechanizm był prosty: instalacja biblioteki oznaczała natychmiastowe uruchomienie kodu atakującego na maszynie dewelopera lub serwerze produkcyjnym [1]. Żadnego dodatkowego kliknięcia, żadnej drugiej paczki – wystarczyło pip install litellm==1.82.7.

Skala zagrożenia jest trudna do oszacowania, ale biorąc pod uwagę liczbę pobrań i fakt, że wiele firm używa pip install bez pinningu wersji, potencjalnie setki tysięcy instalacji mogły być narażone. Na szczęście incydent został szybko wykryty i złośliwe wersje usunięto, ale to nie zmienia faktu, że okno podatności istniało.

Jak działała złośliwa wersja? Co zmieniono w kodzie?

Knowledge pack nie podaje dokładnej treści złośliwego kodu, ale z opisu ataku wynika, że podmiana paczki polegała na dodaniu skryptu instalacyjnego, który wykonywał się automatycznie podczas pip install. Tego typu ataki – znane jako dependency confusion lub typosquatting – są dobrze znane w ekosystemie Pythona, ale rzadko dotyczą tak popularnych bibliotek.

W przypadku LiteLLM hakerzy nie musieli modyfikować logiki bramki – wystarczyło dodać złośliwy kod do pliku setup.py lub __init__.py, który uruchamiał się przy imporcie. Instalacja = infekcja. To klasyczny atak na łańcuch dostaw, tyle że w środowisku AI, gdzie zależności są często traktowane mniej rygorystycznie niż w tradycyjnym oprogramowaniu.

Dlaczego to działa tak dobrze?

Wiele polskich firm – zwłaszcza startupy i działy R&D – instaluje paczki na produkcji bez weryfikacji sum kontrolnych, bez skanowania zależności i bez blokowania wersji. pip install litellm to standardowe polecenie w Dockerfile’ach i skryptach CI/CD. Jeśli atakujący podmieni paczkę na PyPI, infekcja rozprzestrzenia się błyskawicznie.

Ograniczeniem tego typu ataku jest to, że działa tylko na wersje, które nie są spinned. Jeśli twój projekt używa litellm==1.82.6, jesteś bezpieczny. Ale jeśli używasz litellm>=1.82.0, mogłeś pobrać złośliwą wersję automatycznie.

Kto jest zagrożony? Czy Twój stack AI jest bezpieczny?

LiteLLM jest używany głównie przez:

• Firmy budujące własne chatboty i asystenty – integrujące wiele modeli (GPT, Claude, Gemini) za jednym API.
• Agencje i studia deweloperskie – które tworzą aplikacje AI dla klientów.
• Zespoły Data Science i MLOps – które automatyzują dostęp do modeli w pipeline’ach.
• Startupy AI – które szybko prototypują i wdrażają rozwiązania.

Nie wiemy, czy atak dotknął polskie firmy. Nie ma publicznych raportów o konkretnych przypadkach w Polsce. Ale ryzyko jest realne – wiele polskich firm korzysta z LiteLLM, a procedury bezpieczeństwa w małych i średnich zespołach często ograniczają się do pip freeze > requirements.txt. To za mało.

Profile ryzyka

Jeśli nie wiesz, której wersji LiteLLM używasz – sprawdź to dziś. To kwestia jednej komendy: pip show litellm.

Dlaczego to wydarzenie to punkt zwrotny dla bezpieczeństwa AI?

Atak na LiteLLM różni się od typowych incydentów z PyPI. To nie jest kolejna paczka do parsowania JSON-a, którą podmieniono – to bramka do modeli AI. Konsekwencje infekcji mogą być znacznie poważniejsze.

Łańcuch dostaw w AI – nowy wektor ataku

Gdy haker przejmuje kontrolę nad biblioteką typu requests czy numpy, może kraść dane, instalować backdoory, ale nie ma bezpośredniego dostępu do modeli językowych. W przypadku LiteLLM – jeśli atakujący dostał się do kodu bramki, mógł:

• przechwytywać klucze API do modeli (OpenAI, Anthropic, Google),
• modyfikować zapytania i odpowiedzi,
• podszywać się pod model,
• kraść dane przesyłane przez bramkę.

To zupełnie inna skala. Bramka LLM to punkt centralny, przez który przepływa cała komunikacja z modelami. Zainfekowana bramka to nie tylko wyciek danych – to możliwość manipulacji odpowiedziami AI, co w zastosowaniach biznesowych (np. customer support, analiza dokumentów) może prowadzić do katastrofalnych decyzji.

Różnica między atakiem na zwykłą paczkę a na bramkę LLM

Zwykła paczka: kradzież danych, backdoor, cryptominer. Bramka LLM: kradzież kluczy API, modyfikacja promptów i odpowiedzi, podszywanie się pod model, wyciek całej historii konwersacji. W praktyce oznacza to, że atak na LiteLLM może być wstępem do ataku na cały system AI – nie tylko na pojedynczy serwer.

To nie jest incydent, to trend. W miarę jak firmy budują coraz więcej na LLM, ataki na łańcuch dostaw AI będą częstsze. LiteLLM to pierwszy głośny przypadek, ale nie ostatni.

Jakie wnioski dla polskich firm? 3 kroki, które musisz podjąć już dziś

Nie czekaj na kolejny incydent. Oto konkretne działania, które możesz wdrożyć w ciągu kilku godzin.

Krok 1: Audyt zależności w projektach AI

Sprawdź, które projekty używają LiteLLM i w jakiej wersji. Użyj komendy:

pip freeze | grep litellm

Jeśli widzisz wersję 1.82.7 lub 1.82.8 – natychmiast usuń ją i zainstaluj poprzednią stabilną (np. 1.82.6). Jeśli używasz zakresów wersji (>=), zamień je na konkretną wersję.

Krok 2: Wdrożenie pinningu wersji i skanowania paczek

• Pinning wersji: w requirements.txt wpisz litellm==1.82.6, a nie litellm>=1.82.0. To najprostsza i najskuteczniejsza ochrona przed atakami na łańcuch dostaw.
• Skanowanie zależności: użyj narzędzi takich jak Snyk, Dependabot (GitHub) lub Safety. Skanują one paczki pod kątem znanych podatności i podejrzanych wersji.
• Hashowanie paczek: w requirements.txt możesz dodać --hash=sha256:... dla każdej paczki. To uniemożliwia instalację podmienionej wersji.

Krok 3: Monitorowanie oficjalnych kanałów bezpieczeństwa

• Subskrybuj kanały PyPI i GitHub dla kluczowych bibliotek, których używasz.
• Śledź polskie źródła takie jak Niebezpiecznik – to oni pierwsi opisali ten atak [1].
• Włącz powiadomienia o nowych wydaniach na GitHubie – jeśli pojawi się nowa wersja, możesz szybko sprawdzić, czy jest bezpieczna.

Dodatkowy krok dla firm z poważniejszym stackiem AI

Rozważ uruchomienie własnego mirrora PyPI (np. z użyciem devpi lub Nexus) i blokowanie instalacji z zewnętrznych repozytoriów bez zatwierdzenia. To więcej pracy, ale daje pełną kontrolę nad tym, co trafia do twojego środowiska.

Źródła

[1] Niebezpiecznik – „Ktoś zatruł popularną pythonową paczkę z 97 milionami pobrań…” – https://niebezpiecznik.pl/post/litellm-pypi-python-hack/