SQL injection ma ponad trzydzieści lat. Jeden z pierwszych udokumentowanych przypadków pochodzi z 1998 roku. Przez całą pierwszą dekadę XXI wieku był najczęściej eksploitowaną klasą podatności w aplikacjach webowych. Dziesiątki tysięcy kursów bezpieczeństwa, setki książek, niezliczone audyty — wszystkie z tym samym podstawowym wnioskiem: nie wstawiaj danych użytkownika bezpośrednio do zapytania SQL. Używaj zapytań parametryzowanych.
24 kwietnia 2026 roku opublikowano ostrzeżenie o CVE-2026-42208 w LiteLLM. Podstawowa przyczyna: dane użytkownika wstawione bezpośrednio do zapytania SQL zamiast przez zapytanie parametryzowane.
36 godzin i 7 minut później zarejestrowano pierwszą aktywną eksploitację.
Czym jest LiteLLM i dlaczego przechowuje klucze do wszystkiego
LiteLLM to otwartoźródłowa bramka AI z ponad 45 000 gwiazdkami na GitHubie — warstwa pośrednia między aplikacjami a dostawcami modeli językowych. Zamiast każda aplikacja miała bezpośrednio integrować się z OpenAI, Anthropic, AWS Bedrock, Google Vertex i dziesiątkami innych dostawców, LiteLLM dostarcza jeden ujednolicony interfejs zgodny z formatem OpenAI. Zmiana dostawcy modelu to zmiana konfiguracji w jednym miejscu, nie refaktoryzacja kodu.
Żeby ta architektura działała, LiteLLM musi przechowywać klucze do wszystkich skonfigurowanych dostawców. Klucze OpenAI, klucze Anthropic, klucze AWS, klucze Azure. Do tego wirtualne klucze API wystawiane przez LiteLLM dla aplikacji klienckich, konfiguracje limitów wydatków, dane uwierzytelniające do baz danych wektorowych. Wszystko przechowywane w bazie PostgreSQL.
LiteLLM jest często wdrażany jako centralna bramka dla całej infrastruktury AI organizacji — jeden punkt przez który przechodzi każde wywołanie modelu, z dostępem do każdego klucza API każdego dostawcy. Sysdig ujmuje to precyzyjnie: "Dane uwierzytelniające zarządzające miesięcznymi limitami wydatków rzędu pięciocyfrowych kwot."
Gdzie leży błąd
CVE-2026-42208 siedzi w mechanizmie weryfikacji kluczy API w bramce LiteLLM.
Gdy aplikacja kliencka wysyła żądanie do LiteLLM, dołącza klucz API w nagłówku Authorization: Bearer sk-.... LiteLLM musi sprawdzić ten klucz w swojej bazie danych, żeby zweryfikować tożsamość i uprawnienia klienta.
W wersjach od 1.81.16 do 1.83.6 wartość z nagłówka Bearer była bezpośrednio wklejana do tekstu zapytania SQL przeciwko tabeli LiteLLM_VerificationToken — zamiast przekazywana jako osobny parametr. Jeden apostrof w nagłówku Authorization pozwala uciec z literału łańcuchowego i dołączyć dowolne instrukcje SQL.
Operacja weryfikacji klucza dzieje się przed decyzją o autentykacji — co oznacza że wstrzyknięcie jest w pełni przed-uwierzytelnieniowe. Dowolny klient HTTP który może dotrzeć do portu bramki LiteLLM może wydać dowolne instrukcje SELECT przeciwko bazie PostgreSQL bez żadnych poświadczeń.
Maintainerzy LiteLLM opisują to w ostrzeżeniu wprost: "Nieuwaierzytelniony atakujący mógł wysłać specjalnie spreparowany nagłówek Authorization do dowolnej trasy API LLM — na przykład POST /chat/completions — i dotrzeć do tego zapytania przez ścieżkę obsługi błędów."
36 godzin, dwa adresy IP, dwie tabele
Sysdig zarejestrował pierwszą próbę eksploitacji 26 kwietnia o 16:17 UTC — 26 godzin i 7 minut po indeksowaniu ostrzeżenia w globalnej bazie GitHub Advisory Database. Łatka była dostępna od 19 kwietnia, pięć dni wcześniej.
Zachowanie atakującego pokazuje głęboką znajomość wewnętrznej struktury LiteLLM. Zamiast próbować przeglądać wszystkie tabele bazy danych, atakujący wycelował precyzyjnie w dwie: litellm_credentials.credential_values i litellm_config.
Pierwsza zawiera klucze dostawców modeli językowych — klucze OpenAI, Anthropic, AWS i innych skonfigurowanych upstream. Druga zawiera informacje o środowisku uruchomieniowym bramki. Atakujący nie był zainteresowany tabelami litellm_usersani litellm_team — danymi o użytkownikach systemu. Chciał kluczy dostawców.
Po dwudziestu minutach od pierwszej sesji ten sam atakujący wrócił z innego adresu IP i powtórzył operację. Rotacja adresów IP w trakcie ataku wskazuje na świadome zarządzanie operacją w celu utrudnienia korelacji w dziennikach.
Sysdig komentuje wiedzę atakującego o strukturze bazy danych: "Precyzja celowania sugeruje wcześniejsze rozpoznanie lub dostęp do wewnętrznej dokumentacji LiteLLM."
Czwarty framework AI w tym samym miesiącu
Zestawienie kwietniowe staje się coraz bardziej czytelne.
Marimo CVE-2026-39987 — terminal WebSocket bez uwierzytelnienia, eksploitacja w 9 godzin i 41 minut. SGLang CVE-2026-5760 — wstrzyknięcie szablonu przez plik modelu GGUF. LMDeploy CVE-2026-33626 — SSRF w ładowaniu obrazów przez moduł wizyjny, eksploitacja w 12 godzin. LiteLLM CVE-2026-42208 — SQL injection w bramce AI, eksploitacja w 36 godzin.
Cztery różne klasy podatności. Cztery różne frameworki. Ten sam wzorzec: infrastruktura AI jako cel ataków, szybka eksploitacja, dostęp do kluczy dostawców jako cel.
LiteLLM jest jednak nieco inny od poprzedniej trójki. Marimo, SGLang i LMDeploy to frameworki do uruchamiania modeli — podatności w nich dawały dostęp do maszyny serwującej modele i jej środowiska. LiteLLM to bramka agregująca — podatność w niej daje dostęp do kluczy wszystkich dostawców których bramka obsługuje. Jedno wstrzyknięcie SQL, klucze do OpenAI, Anthropic i AWS jednocześnie.
SQL injection w 2026 roku: jak to możliwe
To pytanie jest nieuniknione i warto na nie odpowiedzieć wprost.
SQL injection jest znane od dekad. Zapytania parametryzowane są standardem nauczanym w każdym kursie programowania webowego od lat dziewięćdziesiątych. OWASP konsekwentnie wymienia SQL injection w pierwszej dziesiątce podatności aplikacji webowych przez ponad dwadzieścia lat. Jak możliwe że nowe oprogramowanie w 2026 roku nadal ma ten błąd?
Odpowiedź jest prosta i niekomfortowa: tempo. LiteLLM jest aktywnie rozwijany — historia commitów pokazuje setki zmian tygodniowo. W środowiskach szybkiego rozwoju, gdzie kod jest pisany i scalany w trybie ciągłym, podstawowe zasady bezpieczeństwa są łatwiejsze do pominięcia niż w projektach z wolniejszym cyklem wydań i formalnymi przeglądami bezpieczeństwa.
Maintainerzy LiteLLM naprawili błąd jedną zmianą: zastąpienie interpolacji łańcuchowej zapytaniami parametryzowanymi. To jest dwie linie kodu. Ale te dwie linie przeoczono przy pisaniu kodu uwierzytelnienia.
Pisaliśmy że NIST oficjalnie przyznał że nie nadąża z uzupełnianiem bazy podatności przy wzroście CVE o 263% w pięć lat — jednym z powodów tej eksplozji jest właśnie to: nowe oprogramowanie tworzone szybko, przez deweloperów skupionych na funkcjonalnościach, bez systematycznych przeglądów bezpieczeństwa. Stare klasy błędów w nowych miejscach.
Połączenie z raportem OX Security
W wpisie o raporcie OX Security o architektonicznym błędzie w STDIO w MCPzwracaliśmy uwagę że LiteLLM był jednym z narzędzi podatnych na tę klasę ataków. Tamta podatność dotyczyła warstwy transportu MCP. Ta dotyczy warstwy uwierzytelnienia HTTP.
LiteLLM pojawia się w kwietniu 2026 dwukrotnie: jako ofiara błędu architektonicznego w protokole MCP i jako ofiara klasycznego SQL injection w własnym kodzie uwierzytelnienia. Dwie różne warstwy, dwie różne klasy podatności, ten sam system.
To nie jest przypadek ani szczególna niekompetencja twórców LiteLLM. To jest obraz oprogramowania które rośnie szybko, integruje wiele zewnętrznych protokołów i warstw, i ma trudność z utrzymaniem spójności bezpieczeństwa w całym stosie.
Co zrobić
Aktualizacja do LiteLLM 1.83.7-stable lub nowszego eliminuje CVE-2026-42208 przez zastąpienie interpolacji łańcuchowej zapytaniami parametryzowanymi.
Dla środowisk które nie mogą natychmiast zaktualizować: ustawienie disable_error_logs: true w sekcji general_settings konfiguracji jako tymczasowe obejście blokuje ścieżkę przez którą wstrzyknięcie dociera do podatnego zapytania.
Jeśli instancja LiteLLM była dostępna publicznie między 19 a 26 kwietnia — czyli między publikacją ostrzeżenia a aktywną eksploitacją — rotacja wszystkich kluczy dostawców przechowywanych w bramce jest zalecana jako krok prewencyjny. Atakujący który zna strukturę tabel LiteLLM i wycelował precyzyjnie w litellm_credentials.credential_values mógł działać wcześniej niż zarejestrowały to pułapki Sysdig.
Podsumowanie
CVE-2026-42208 w LiteLLM to nie jest nowa klasa ataku. To jest jedna z najstarszych klas ataku w historii aplikacji webowych — w narzędziu z centrum ekosystemu infrastruktury AI, eksploitowana 36 godzin po opublikowaniu ostrzeżenia, przez atakującego który wiedział dokładnie w których tabelach siedzą klucze dostawców modeli językowych.
Stare błędy w nowych miejscach — to był jeden z pierwszych wzorców opisywanych przez cyberflux przy okazji pierwszych CVE w ekosystemie MCP. Kwiecień 2026 pokazuje ten wzorzec w pełnej skali: path traversal, brak uwierzytelnienia, wstrzyknięcie szablonu, SSRF, SQL injection — każda z tych klas ma dziesiątki lat historii. Każda znalazła nowy dom w infrastrukturze AI.
Źródła
Sysdig Threat Research Team — pierwotna analiza z danymi z pułapek i chronologią ataku: https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
The Hacker News — szczegóły techniczne CVE i precyzja atakującego: https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html
SecurityWeek — kontekst eksploitacji i rekomendacje: https://www.securityweek.com/fresh-litellm-vulnerability-exploited-shortly-after-disclosure/
GBHackers — analiza mechanizmu wstrzyknięcia i cel ataku: https://gbhackers.com/critical-litellm-flaw-enables-database-attacks/
Cybersecurity News — szczegóły tabel docelowych i aktywnej eksploitacji: https://cybersecuritynews.com/litellm-sql-injection-vulnerability-exploited/
