Krytyczna luka SQL Injection w LiteLLM aktywnie wykorzystywana. Zagrożone klucze API i sekrety środowiskowe - Security Bez Tabu

Krytyczna luka SQL Injection w LiteLLM aktywnie wykorzystywana. Zagrożone klucze API i sekrety środowiskowe

Cybersecurity news

Wprowadzenie do problemu / definicja

LiteLLM to popularna warstwa pośrednia i brama API dla dużych modeli językowych, używana do ujednolicania dostępu do wielu dostawców AI. Najnowszy incydent dotyczy krytycznej podatności typu SQL Injection oznaczonej jako CVE-2026-42208, która może być wykorzystana bez uwierzytelnienia podczas weryfikacji klucza API w komponencie proxy.

Problem jest szczególnie poważny, ponieważ dotyczy elementu stojącego często w centrum architektury aplikacji AI. W praktyce taka brama może przechowywać klucze dostępu do usług zewnętrznych, sekrety środowiskowe, konfigurację oraz dane niezbędne do routingu ruchu do modeli.

W skrócie

Podatność CVE-2026-42208 wynika z nieprawidłowego osadzania danych wejściowych w zapytaniu SQL podczas sprawdzania klucza API. Atakujący może przesłać spreparowany nagłówek Authorization do endpointów API i uruchomić podatny kod bez wcześniejszego logowania.

  • Zagrożone są wersje LiteLLM od 1.81.16 do 1.83.6.
  • Poprawka została opublikowana w wersji 1.83.7.
  • Zaobserwowano aktywne próby wykorzystania krótko po publicznym ujawnieniu luki.
  • Możliwy jest odczyt danych z bazy oraz potencjalna ich modyfikacja.

Kontekst / historia

LiteLLM zyskał dużą popularność jako warstwa pośrednia upraszczająca integrację z wieloma modelami za pomocą jednego interfejsu. To sprawia, że rozwiązanie staje się atrakcyjnym celem dla cyberprzestępców, ponieważ kompromitacja jednej instancji może otworzyć drogę do wielu backendów jednocześnie.

W przypadku CVE-2026-42208 problem został opisany jako krytyczna luka w ścieżce weryfikacji klucza API. Poprawka pojawiła się 20 kwietnia 2026 roku, a pierwsze publicznie odnotowane próby wykorzystania wykryto już około 36 godzin później. Taka dynamika potwierdza, że infrastruktura AI jest obecnie monitorowana przez atakujących niemal natychmiast po publikacji informacji o nowych błędach.

Znaczenie incydentu zwiększa szerszy kontekst bezpieczeństwa projektu. W ostatnim czasie wokół LiteLLM pojawiały się również informacje o incydentach związanych z łańcuchem dostaw, co dodatkowo podnosi poziom ryzyka dla organizacji korzystających z tego narzędzia w środowiskach produkcyjnych.

Analiza techniczna

Źródłem podatności jest sposób budowania zapytania do bazy danych podczas weryfikacji klucza API przez proxy. Zamiast bezpiecznego użycia parametryzowanych zapytań, podatny kod miał osadzać dane wejściowe bezpośrednio w treści SQL, co otwiera drogę do klasycznego SQL Injection.

Szczególnie niebezpieczny jest fakt, że luka jest osiągalna bez uwierzytelnienia. Atakujący może wysłać odpowiednio przygotowany nagłówek Authorization: Bearer do jednego z endpointów obsługujących ruch do modeli i uruchomić podatny fragment kodu jeszcze przed poprawną walidacją dostępu.

Z analiz badaczy wynika, że obserwowane działania nie przypominały prostego, masowego skanowania. Kampanie miały charakter bardziej ukierunkowany i skupiały się na tabelach zawierających klucze API, dane konfiguracyjne, poświadczenia dostawców modeli oraz sekrety środowiskowe. W kolejnych etapach ataku zmieniano adresy IP i dopasowywano ładunki do rozpoznanego schematu bazy, co sugeruje iteracyjne doskonalenie exploitu.

Usunięcie błędu polegało na zastąpieniu konkatenacji tekstu parametryzowanymi zapytaniami SQL. Producent wskazał również obejście tymczasowe polegające na ustawieniu disable_error_logs: true w general_settings, jednak należy je traktować jedynie jako środek awaryjny, a nie pełne rozwiązanie problemu.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-42208 jest bardzo wysokie, ponieważ łączy zdalny wektor ataku, brak potrzeby logowania, niski poziom złożoności oraz możliwość uzyskania dostępu do danych o wysokiej wartości operacyjnej i finansowej.

Potencjalne skutki kompromitacji instancji LiteLLM obejmują:

  • wyciek kluczy API do usług AI i platform chmurowych,
  • przejęcie kluczy wirtualnych i kluczy nadrzędnych,
  • ujawnienie sekretów środowiskowych oraz konfiguracji aplikacyjnej,
  • możliwość modyfikacji danych w bazie proxy,
  • ryzyko dalszego ruchu bocznego do innych systemów zależnych od przechowywanych poświadczeń.

Dla organizacji wykorzystujących LiteLLM jako centralną bramę do wielu modeli skutki mogą być szczególnie dotkliwe. Jeden skuteczny atak może zapewnić przeciwnikowi dostęp do wielu usług jednocześnie, w tym środowisk produkcyjnych, kont rozliczeniowych oraz integracji chmurowych.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja LiteLLM do wersji 1.83.7 lub nowszej. Organizacje korzystające z wersji od 1.81.16 do 1.83.6 powinny przyjąć, że instancje wystawione do internetu mogły już zostać objęte próbami wykorzystania.

  • zaktualizować wszystkie instancje do bezpiecznej wersji,
  • jeśli aktualizacja nie jest możliwa od razu, wdrożyć obejście z wyłączeniem wskazanej ścieżki logowania błędów,
  • obrócić wszystkie klucze przechowywane w bazie LiteLLM, w tym master keys, virtual keys i poświadczenia dostawców modeli,
  • przeanalizować logi HTTP pod kątem nietypowych nagłówków Authorization i podejrzanych żądań do endpointów LLM,
  • sprawdzić historię połączeń do bazy danych oraz anomalie związane z odczytem wrażliwych tabel,
  • ograniczyć ekspozycję endpointów LiteLLM do zaufanych sieci lub warstwy VPN,
  • wdrożyć reguły WAF i mechanizmy detekcji anomalii dla wzorców charakterystycznych dla SQL Injection,
  • przeprowadzić pełny przegląd tajemnic i integracji zależnych od LiteLLM.

W środowiskach o wysokiej krytyczności uzasadnione jest także wszczęcie standardowego postępowania incydentowego, obejmującego analizę artefaktów, weryfikację integralności systemu, przegląd zmian konfiguracyjnych oraz ocenę ewentualnego wtórnego wykorzystania przechowywanych poświadczeń.

Podsumowanie

CVE-2026-42208 pokazuje, że komponenty pośredniczące w ruchu do modeli AI stały się infrastrukturą wysokiej wartości dla atakujących. W przypadku LiteLLM pre-auth SQL Injection może prowadzić do ujawnienia najbardziej wrażliwych danych przechowywanych przez proxy, a szybkie pojawienie się prób wykorzystania potwierdza, że okno reakcji dla obrońców jest dziś bardzo krótkie.

Dla zespołów bezpieczeństwa oznacza to konieczność priorytetowego patchowania, rotacji sekretów oraz traktowania publicznie dostępnych, podatnych instancji jako potencjalnie naruszonych do czasu przeprowadzenia pełnej weryfikacji.

Źródła

  1. LiteLLM: SQL injection in Proxy API key verification — https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
  2. BerriAI/litellm repository — https://github.com/BerriAI/litellm
  3. Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw — https://www.bleepingcomputer.com/news/security/hackers-are-exploiting-a-critical-litellm-pre-auth-sqli-flaw/
  4. Popular LiteLLM PyPI package backdoored to steal credentials, auth tokens — https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
  5. Sysdig blog: CVE-2026-42208 targeted SQL injection against LiteLLM — https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure