Jeśli Twoje proxy AI trzyma klucze do modeli, zegarek po ujawnieniu podatności nie tyka. On wali młotkiem w obudowę. Krytyczna podatność SQL injection w LiteLLM (CVE-2026-42208), popularnej bramce AI, została aktywnie wykorzystana około 36 godzin po zindeksowaniu ostrzeżenia na GitHubie. Atakujący nie przyszli z mazakiem po defacement strony. Celowali prosto w szafkę z kluczami, tam gdzie naprawdę leżą pieniądze.

LiteLLM to proxy open-source, którego deweloperzy używają do routingu zapytań do różnych dostawców LLM, takich jak OpenAI, Anthropic czy AWS Bedrock. Przy ponad 45 tysiącach gwiazdek na GitHubie stało się wygodną zwrotnicą dla kluczy API, kosztów i logów zapytań. Dla zespołu to porządek w jednym miejscu. Dla napastnika to ta sama zaleta, tylko bez kosztu wdrożenia.

Oficjalne ostrzeżenie bezpieczeństwa na GitHubie opisuje błąd oceniony na 9.3 w skali CVSS. To SQL injection możliwy do wykorzystania bez uwierzytelnienia, czyli zamek w drzwiach przyklejony taśmą. Atakujący może wysłać spreparowany nagłówek Authorization do dowolnego endpointu API przepuszczanego przez proxy. Logika obsługi błędów w proxy niepoprawnie sklejała ten złośliwy ciąg znaków z zapytaniem do bazy danych, dając atakującemu dostęp.

Najgorszy element nie siedzi w samym skrócie "SQL injection", bo ten przypadek wraca tak często, że powinien mieć własną szufladę w muzeum webdevu. Mój wniosek po zestawieniu ostrzeżenia bezpieczeństwa z raportem Sysdig oraz relacją The Hacker News jest prosty: atakujący celowali precyzyjnie w tabelę litellm_credentials.

Pojedynczy wiersz w tej tabeli może zawierać klucz organizacji OpenAI z pięciocyfrowym miesięcznym limitem wydatków, klucz Anthropic z uprawnieniami administratora obszaru roboczego czy poświadczenia IAM do AWS Bedrock. Zamiast zwykłej wysypanej tabelki użytkowników dostajesz ryzyko z gatunku "nie mamy Pańskiego płaszcza" w wersji cloud: jeśli klucz zniknie, faktura zostaje.

Ta błyskawiczna eksploatacja nie wygląda jak jednorazowy pech. Wpisuje się w ten sam schemat, co podatność w LMDeploy (CVE-2026-33626), wykorzystana w zaledwie 13 godzin. W obu przypadkach atakujący ruszyli na infrastrukturę AI krótko po zindeksowaniu ostrzeżenia. Założenie, że publiczny PoC dopiero zaczyna odliczanie, ma dziś wartość kartki z napisem "proszę nie kraść" przy otwartym sejfie.

Naprawa jest technicznie prosta, czyli dokładnie ten rodzaj pracy, który w organizacjach potrafi utknąć między "zaraz" a "po sprincie". Oficjalny komunikat zostawia trzy praktyczne działania:

  1. Natychmiastowa aktualizacja: Podatność jest załatana w wersji 1.83.7-stable i nowszych. Wszystkie wersje od 1.81.16 do wersji wcześniejszych niż 1.83.7 są podatne.
  2. Zastosowanie obejścia: Jeśli nie możesz od razu zaktualizować, możesz zminimalizować ryzyko, ustawiając disable_error_logs: true w swojej konfiguracji LiteLLM. To blokuje ścieżkę kodu, którą wykorzystują atakujący.
  3. Założenie ekspozycji: Biorąc pod uwagę 36-godzinne okno, każdą publicznie wystawioną, niezałataną instancję traktuj jako narażoną. Sprawdź logi dostępu i wymień klucze dostawców LLM, jeśli widzisz oznaki ekspozycji albo podejrzewasz kompromitację. Ja przy takim oknie nie negocjowałbym z nadzieją. Nadzieja nie rotuje sekretów.

To drugi poważny incydent bezpieczeństwa LiteLLM w ciągu dwóch miesięcy, po ataku na łańcuch dostaw w marcu. Status narzędzia jest więc prosty: wygodne dla deweloperów, smaczne dla napastników. Jeśli element stosu zbiera klucze do OpenAI, Anthropic i AWS Bedrock, nie traktuj go jak pomocniczego skryptu z katalogu tools/. Traktuj go jak brzegowy router z portfelem przyklejonym do obudowy.