Wstrzyknięcie SQL w LiteLLM od 1.81.16 do 1.83.6 pozwala bez konta odczytać bazę bramy AI z kluczami do płatnych modeli. CISA potwierdza ataki. Zaktualizuj do 1.83.7 lub nowszej i wymień klucze.
Ten alert jest dla zarządu, CTO i CFO firm, które korzystają z modeli językowych (AI) przez własną bramę LiteLLM, także postawioną „na chwilę” przez jednego programistę. Werdykt: jeśli masz LiteLLM w wersji od 1.81.16 do 1.83.6, zaktualizuj go dziś i wymień klucze do dostawców modeli, bo luka jest aktywnie wykorzystywana i pozwala bez logowania odczytać bazę bramy z tymi kluczami.
Amerykańska agencja CISA 8 maja 2026 roku dopisała podatność CVE-2026-42208 do katalogu KEV, czyli listy luk, o których ma dowody, że są wykorzystywane w prawdziwych atakach. Błąd dotyczy LiteLLM firmy BerriAI, serwera pośredniczącego (bramy AI), przez który aplikacje firmy łączą się z dostawcami modeli językowych, takimi jak OpenAI.
Podczas sprawdzania klucza API brama wklejała wartość podaną przez wywołującego wprost do treści zapytania do bazy danych. Napastnik bez konta i bez ważnego klucza może wysłać spreparowany nagłówek Authorization do dowolnej trasy modelu (np. POST /chat/completions) i przez ścieżkę obsługi błędów odczytać, a potencjalnie zmienić dane w bazie bramy, w tym zarządzane przez nią poświadczenia.
Termin naprawy wyznaczony przez CISA agencjom federalnym minął 11 maja 2026 roku, ponad cztery miesiące temu.
Element | Szczegóły |
|---|---|
Identyfikator CVE | CVE-2026-42208 |
Data dodania do CISA KEV | 2026-05-08 |
Termin naprawy wg CISA | 2026-05-11 (3 dni od wpisu) |
Produkt | BerriAI LiteLLM (serwer proxy, brama AI) |
Wersje zagrożone | Od 1.81.16 włącznie do wersji niższych niż 1.83.7. Dotyczy trybu proxy z bazą danych, w którym brama sprawdza klucze API |
Wersje bezpieczne | 1.83.7 i nowsze (wydanie v1.83.7-stable z 19 kwietnia 2026). Najnowsze stabilne wydanie na GitHubie w dniu publikacji alertu: v1.101.0 (15 września 2026) |
Typ podatności | Wstrzyknięcie SQL (SQL injection); CWE-89 |
Ocena CVSS | NVD: 9.8 KRYTYCZNA (CVSS 3.1). GitHub (zgłoszenie producenta): 9.3 KRYTYCZNA (CVSS 4.0). Red Hat: 9.8 (CVSS 3.1). Atak przez sieć, bez uprawnień i bez udziału użytkownika |
Wyobraź sobie urzędnika, który przyjmuje wnioski na formularzach. Dobrze zorganizowany urząd traktuje to, co petent wpisał w rubryki, wyłącznie jako dane. W tym przypadku urzędnik przepisywał treść rubryki „numer legitymacji” do swojej wewnętrznej instrukcji i wykonywał ją. Wystarczyło wpisać w rubrykę „pokaż mi szafę z kluczami”, a urzędnik to robił, zanim w ogóle stwierdził, że legitymacja jest nieważna.
Brama LiteLLM trzyma w bazie klucze do płatnych kont u dostawców modeli, wewnętrzne klucze aplikacji i limity wydatków. Właśnie do tej bazy napastnik docierał przez nagłówek, który miał zawierać klucz. Co ważne, podatny fragment uruchamiał się na ścieżce obsługi błędów, czyli wtedy, gdy klucz okazywał się nieprawidłowy.
💡 Brama AI (proxy) to serwer, przez który firmowe aplikacje łączą się z modelami językowymi; tylko on zna główny klucz do dostawcy. Wstrzyknięcie SQL to błąd, w którym tekst od użytkownika staje się częścią polecenia dla bazy danych. Nagłówek Authorization to pole w zapytaniu internetowym, w którym przekazuje się klucz lub hasło. KEV (Known Exploited Vulnerabilities) to katalog CISA z lukami potwierdzonymi jako wykorzystywane w atakach.
Scenariusz | Normalnie | Z podatnością |
|---|---|---|
Aplikacja firmowa pyta model przez bramę | Brama sprawdza klucz i przekazuje zapytanie | Tak samo, nic się nie zmienia |
Obca osoba podaje zmyślony klucz | Odrzucenie i wpis w logach | Spreparowany „klucz” wykonuje polecenie w bazie bramy |
Klucze do dostawców modeli | Znane tylko bramie | Mogą zostać odczytane z bazy |
Rachunek u dostawcy modelu | Zgodny z użyciem przez firmę | Rośnie, gdy skradziony klucz jest używany lub odsprzedawany |
Treści wysyłane do modelu | Widoczne tylko dla uprawnionych | Jeśli brama je zapisuje, mogą wyciec razem z bazą |
źródło: Pexels, Ron LachPoniżej typowy przebieg ataku dla tej klasy podatności. To scenariusz poglądowy, a nie odtworzenie konkretnego incydentu. Atak dotyczy bram dostępnych z sieci napastnika, najczęściej wystawionych do internetu. CISA oceniła, że da się go zautomatyzować.
Etap | Czas | Akcja hakerów | Wynik |
|---|---|---|---|
1. Rozpoznanie | T+0 min | Skanowanie internetu w poszukiwaniu serwerów LiteLLM | Lista bram do sprawdzenia |
2. Próba wstrzyknięcia | T+kilka minut | Wysłanie spreparowanego nagłówka Authorization do trasy modelu | Potwierdzenie podatności |
3. Odczyt bazy | T+kilkanaście minut | Wyciągnięcie kluczy do dostawców modeli, kluczy wewnętrznych i ustawień | Poświadczenia w rękach napastnika |
4. Nadużycie kluczy | T+godziny | Używanie lub odsprzedaż dostępu do płatnych modeli na koszt firmy | Rosnący rachunek, zwykle niezauważony do faktury |
5. Utrwalenie | T+1 do 3 dni | Możliwa zmiana danych w bazie, np. dopisanie własnego klucza z wysokim limitem | Stały dostęp do bramy |
6. Wyciek treści | T+dni do tygodni | Odczyt zapisanych zapytań i odpowiedzi, jeśli brama je przechowuje | Ujawnienie dokumentów i danych klientów |
Mogę Ci jakoś pomóc?
Bramy AI rzadko trafiają do rejestru oprogramowania firmy, bo stawia się je szybko, na potrzeby jednego projektu. Tymczasem w ich bazie leżą klucze do płatnych usług i często ślady treści, które pracownicy wysyłali do modeli. Atak nie przerywa pracy, więc może długo pozostać niezauważony.
Obszar biznesu | Potencjalny wpływ | Czas do wystąpienia | Koszty szacunkowe |
|---|---|---|---|
Operacyjny | Zablokowane konto u dostawcy modelu po wykryciu nadużyć, przestój narzędzi AI | Dni do tygodni | 10 tys. do 80 tys. PLN (przestój narzędzi, prace naprawcze) |
Bezpieczeństwo danych | Wyciek kluczy API i zapisanych treści zapytań | Minuty do godzin od ataku | 30 tys. do 150 tys. PLN (analiza powłamaniowa, wymiana poświadczeń) |
Finansowy | Rachunki za wywołania modeli wykonane przez napastnika | Godziny do cyklu rozliczeniowego | 5 tys. do 200 tys. PLN, zależnie od limitów u dostawcy |
Reputacyjny | Utrata zaufania klientów, których dokumenty przechodziły przez narzędzie AI | Tygodnie do miesięcy | 30 tys. do 300 tys. PLN (utracone kontrakty) |
Prawny | Obowiązek oceny naruszenia i zgłoszenia do UODO w ciągu 72 godzin, jeśli wyciekły dane osobowe; możliwa kara RODO do 20 mln EUR lub 4% rocznego obrotu, zależnie od okoliczności | 72 godziny od wykrycia | 15 tys. do 100 tys. PLN (prawnicy, obsługa zgłoszeń), bez ewentualnej kary |
Kwoty są orientacyjnymi widełkami dla małej i średniej firmy, nie danymi z tego incydentu.
Macierz ryzyka: LiteLLM 1.81.16 do 1.83.6
dostępny z internetu
Wpływ
5 | . . . . .
4 | . . . . ■ ← KRYTYCZNE
3 | . . . . .
2 | . . . . .
1 | . . . . .
+--------------------
1 2 3 4 5 Prawdopodobieństwo Interpretacja: prawdopodobieństwo jest najwyższe (ataki potwierdzone, bez logowania, możliwa automatyzacja, EPSS blisko 0,9), a wpływ wysoki, ale nie maksymalny, bo luka daje dostęp do bazy bramy i jej poświadczeń, a nie bezpośrednio do całej sieci firmy.
Lp. | Priorytet | Działanie | Termin | Odpowiedzialny |
|---|---|---|---|---|
1 | 🔴 NATYCHMIAST | Ustalić, czy w firmie działa LiteLLM (serwery, kontenery, konta chmurowe, projekty programistów) i w jakiej wersji | Dziś | CTO / zespół deweloperski |
2 | 🔴 NATYCHMIAST | Zaktualizować LiteLLM do 1.83.7 lub nowszej, najlepiej do bieżącego wydania stabilnego | Dziś | Zespół deweloperski / DevOps |
3 | 🔴 NATYCHMIAST | Jeśli aktualizacja musi poczekać: ustawić | Dziś | DevOps |
4 | 🟠 PILNIE | Wymienić klucze API do wszystkich dostawców modeli skonfigurowanych w podatnej bramie oraz klucz główny bramy | Do 3 dni | DevOps / właściciel kont u dostawców |
5 | 🟠 PILNIE | Przejrzeć listę kluczy wewnętrznych i użytkowników w bazie bramy, usunąć nieznane | Do 3 dni | Zespół deweloperski |
6 | 🟠 PILNIE | Porównać rachunki u dostawców modeli od kwietnia 2026 roku z normalnym zużyciem | Do 7 dni | CFO / CTO |
7 | 🟡 WAŻNIE | Ustawić miesięczne limity wydatków i alerty dzienne u każdego dostawcy modeli | Do 14 dni | CFO / DevOps |
8 | 🟡 WAŻNIE | Dopisać bramy AI i ich wersje do rejestru oprogramowania firmy | Do 30 dni | CTO |
Producent wydał poprawkę w wersji 1.83.7, więc docelowo trzeba ją wdrożyć. Do tego czasu pomagają poniższe miary. Oceny efektywności to ocena ekspercka.
Czasowa miara ochronna | Efektywność | Łatwość wdrożenia |
|---|---|---|
Ustawienie | Wysoka: według producenta usuwa ścieżkę, którą nieuwierzytelnione dane docierają do podatnego zapytania | Łatwa: zmiana konfiguracji i restart |
Ograniczenie dostępu do bramy do sieci firmowej lub znanych adresów IP | Średnia do wysokiej: odcina anonimowych napastników z internetu | Średnia: wymaga zmian w chmurze lub zaporze |
Wymiana kluczy do dostawców modeli | Średnia: nie zamyka luki, ale unieważnia to, co mogło już wyciec | Łatwa |
Limity wydatków i alerty u dostawców modeli | Niska jako ochrona, wysoka jako wczesne wykrycie nadużyć | Łatwa |
Stan | Przed działaniem | Po działaniu |
|---|---|---|
Sprawdzanie kluczy przez bramę | Tekst z nagłówka trafia do zapytania SQL | Wartość przekazywana jako osobny parametr |
Klucze do dostawców modeli | Mogły zostać odczytane | Wymienione, stare unieważnione |
Widoczność kosztów | Nadużycie widać dopiero na fakturze | Alerty dzienne i twardy limit miesięczny |
Dostęp z internetu | Brama otwarta dla każdego | Dostęp ograniczony do potrzebnych aplikacji |
Wiedza o narzędziach AI w firmie | Bramy stawiane poza rejestrem | Bramy AI w rejestrze z wersją i właścicielem |
Aspekt | Informacja |
|---|---|
Czy jest wykorzystywana? | TAK (potwierdzone przez CISA). CISA oceniła wykorzystanie jako aktywne, możliwe do automatyzacji, z całkowitym wpływem technicznym |
Grupy przestępcze | Brak publicznych informacji |
Kampanie ransomware | Brak potwierdzenia (CISA: Unknown) |
Ocena CVSS | 9.8 KRYTYCZNA wg NVD i Red Hat (CVSS 3.1); 9.3 KRYTYCZNA wg GitHub (CVSS 4.0) |
PoC dostępny publicznie? | Brak publicznych informacji |
Liczba atakowanych firm | Brak publicznych informacji |
Kto wykrył błąd | Tencent YunDing Security Lab |
Prognoza EPSS | 0,8942 (około 89% szansy próby wykorzystania w 30 dni), percentyl 0,9978, odczyt z 23 sierpnia 2026 (wg analizy źródłowej) |
Produkty Red Hat | Red Hat sprawdził cztery swoje produkty zawierające LiteLLM i uznał je za niepodatne, bo nie używają podatnych wydań (wg analizy źródłowej) |
Różnica między 9.8 a 9.3 wynika z innej metodologii nowszej skali CVSS 4.0, a nie z różnej oceny zagrożenia. Oba wyniki opisują atak przez sieć, bez uprawnień i bez udziału użytkownika.
Mogę Ci jakoś pomóc?
Sygnały zagrożenia dla CVE-2026-42208
CVSS 3.1 (NVD) 9.8/10 ████████████████████ KRYTYCZNA
CVSS 4.0 (GitHub) 9.3/10 ███████████████████░ KRYTYCZNA
EPSS (próba w 30 dni) ~89% ██████████████████░░ BARDZO WYSOKA
CISA KEV TAK ████████████████████ ataki potwierdzone
Ransomware (CISA) Unknown ░░░░░░░░░░░░░░░░░░░░ brak potwierdzenia 2026-04-19 Wydanie LiteLLM v1.83.7-stable z poprawką
2026-04-20 Publikacja biuletynu GHSA-r75f-5x8p-qvmc na GitHubie
2026-05-08 Publikacja CVE w NVD; CISA dodaje lukę do katalogu KEV
2026-05-11 Termin naprawy wg CISA dla agencji federalnych
2026-08-23 EPSS 0,8942, percentyl 0,9978
2026-09-15 Najnowsze stabilne wydanie LiteLLM: v1.101.0
... ponad 4 miesiące od terminu CISA
2026-09-17: TUTAJ JESTEŚMY Biuletyn producenta z wersją poprawioną i obejściem: GHSA-r75f-5x8p-qvmc na GitHubie . Wydanie z poprawką: LiteLLM v1.83.7-stable . Wpis w NVD: nvd.nist.gov/vuln/detail/CVE-2026-42208 .
Lp. | Zadanie | Kto | Deadline |
|---|---|---|---|
1 | Ustalić, czy jakikolwiek projekt w firmie używa LiteLLM jako bramy do modeli AI | CTO | DZISIAJ |
2 | Uzyskać pisemną informację o wersji i o tym, czy brama jest dostępna z internetu | CTO | DZISIAJ |
3 | Zatwierdzić aktualizację lub włączenie obejścia | CTO | DZISIAJ |
4 | Zlecić wymianę kluczy do dostawców modeli skonfigurowanych w bramie | CTO | DO JUTRA |
5 | Sprawdzić rachunki od dostawców modeli pod kątem nietypowych wzrostów od kwietnia 2026 roku | CFO | DO JUTRA |
6 | Ustawić limity wydatków i alerty na kontach u dostawców modeli | CFO | DO JUTRA |
7 | Ustalić, czy przez bramę przechodziły dane osobowe klientów, na potrzeby ewentualnego zgłoszenia do UODO | CFO / inspektor ochrony danych | DO JUTRA |
# | Pytanie | Odpowiedź | Priorytet |
|---|---|---|---|
1 | Czy w firmie działa LiteLLM (także w kontenerze lub w projekcie testowym)? | TAK / NIE | 🔴 |
2 | Jaka jest wersja każdej instancji LiteLLM? | [wersja] | 🔴 |
3 | Czy brama jest dostępna z internetu? | TAK / NIE | 🔴 |
4 | Kiedy zainstalowano wersję 1.83.7 lub nowszą albo włączono obejście? | [data] | 🔴 |
5 | Czy klucze do dostawców modeli zostały wymienione po aktualizacji? | TAK / NIE, [data] | 🟠 |
6 | Czy brama zapisuje treść zapytań i odpowiedzi w bazie? | TAK / NIE | 🟠 |
7 | Czy u każdego dostawcy modeli ustawiony jest limit wydatków i alert? | TAK / NIE | 🟡 |
CVE-2026-42208 pozwala bez logowania odczytać bazę bramy LiteLLM w wersjach od 1.81.16 do 1.83.6, razem z kluczami do płatnych modeli AI. CISA potwierdza ataki, a termin naprawy minął 11 maja 2026 roku, więc aktualizacja, wymiana kluczy i przegląd rachunków to zadania na dziś i jutro.
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Przepełnienie bufora w FortiOS i FortiSwitchManager pozwala bez hasła uruchomić kod na zaporze. CISA potwierdza ataki, a przestępcy instalują trojana PivotC2. Zaktualizuj FortiOS i sprawdź zapory pod kątem włamania.
Czytaj artykułWykorzystywana przed wydaniem poprawki luka w mechanizmie aktualizacji Windows 11 i Windows Server 2025 pozwala zwykłemu kontu przejąć komputer. Zainstaluj wrześniową aktualizację dziś.
Czytaj artykułBłąd w bibliotece Starlette, podstawie FastAPI, pozwala omijać zabezpieczenia części aplikacji, a w łańcuchu z luką LiteLLM przejąć bramkę AI. CISA potwierdza ataki. Zaktualizuj do 1.0.1 lub nowszej.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.