Krytyczny incydent bezpieczeństwa w LiteLLM: malware infekuje klastry Kubernetes

Bezpieczeństwo ekosystemu sztucznej inteligencji stanęło pod dużym znakiem zapytania po wykryciu zaawansowanego ataku na otwartoźródłową bibliotekę LiteLLM. Narzędzie, które dla wielu programistów stało się standardowym proxy do obsługi wielu modeli językowych (LLM), zostało zainfekowane złośliwym oprogramowaniem dystrybuowanym przez oficjalne repozytorium PyPI. Badacz bezpieczeństwa Callum McMahon z Futuresearch zidentyfikował, że wersje 1.82.7 oraz 1.82.8, opublikowane 24 marca 2026 roku, zawierają kod, którego nie znajdziemy w oficjalnym repozytorium GitHub projektu. Oznacza to najprawdopodobniej pełne przejęcie konta autora i wstrzyknięcie złośliwego kodu bezpośrednio do paczek instalacyjnych.

Precyzyjna kradzież poświadczeń i infekcja klastrów

Skala zagrożenia jest określana jako ekstremalna. Wykryte złośliwe oprogramowanie nie tylko wykrada dane, ale robi to w sposób ukierunkowany na infrastrukturę korporacyjną. Mechanizm ataku obejmuje ekstrakcję kluczy SSH, haseł do baz danych, poświadczeń chmurowych oraz – co najbardziej niepokojące – konfiguracji klastrów Kubernetes. Przejęte informacje są szyfrowane i wysyłane na serwer zewnętrzny, co utrudnia ich wykrycie przez proste systemy monitoringu sieciowego. Co więcej, złośliwe oprogramowanie posiada zdolność do samoistnego rozprzestrzeniania się wewnątrz środowisk kontenerowych i instalowania stałych tylnych furtek (backdoorów), co pozwala napastnikom zachować dostęp nawet po aktualizacji biblioteki do bezpiecznej wersji.

Sygnał alarmowy dla deweloperów AI

Incydent wyszedł na jaw niemal przypadkowo, gdy zainfekowana paczka zaczęła powodować błędy w popularnym edytorze kodu Cursor. Jim Fan, dyrektor ds. AI w Nvidii, określił sytuację mianem „paliwa dla koszmarów”. Fan ostrzega, że w erze autonomicznych agentów AI, każdy plik tekstowy w kontekście modelu staje się potencjalnym wektorem ataku. Jeśli agent operujący na zainfekowanym środowisku zostanie zmanipulowany, może podszywać się pod użytkownika w niemal każdej powiązanej usłudze.

Eksperci zalecają natychmiastową rotację wszystkich poświadczeń, które mogły mieć kontakt ze środowiskiem, w którym uruchomiono trefne wersje LiteLLM. Sytuacja ta rzuca nowe światło na problem nadmiernego zaufania do rozbudowanych łańcuchów zależności w Software 3.0. Rozwiązaniem może być powrót do „chudych”, dedykowanych rozwiązań oraz rozwój nowej gałęzi bezpieczeństwa – audytowanego, konserwatywnego oprogramowania, które będzie sprawować nadzór nad dynamicznym i wciąż nieprzewidywalnym światem narzędzi opartych na sztucznej inteligencji.