Wiz: prawie co dziesiąta wystawiona brama LiteLLM akceptuje przykładowy klucz administratora sk-1234

9 września 2026 r. Wiz Research opublikował badanie dotyczące LiteLLM — bramy AI typu open source, która znajduje się między aplikacjami a dostawcami modeli, za których usługi płacą — i poinformował, że 294 spośród 3074 wdrożeń LiteLLM, do których mógł dotrzeć w publicznym internecie — 9,6%, niemal co dziesiąte — akceptowało sk-1234, przykładowy klucz główny wydrukowany w dokumentacji konfiguracji samego projektu, albo w ogóle nie wymagało poświadczeń. Ten ciąg nie jest zwykłym kluczem API: w LiteLLM jest jednocześnie poświadczeniem administratora i przełącznikiem, który włącza uwierzytelnianie, więc każdy, kto go przedstawi, może odczytać każdy klucz dostawcy modeli przechowywany na bramie, obserwować każde zapytanie i każdą odpowiedź, które przez nią przechodzą, oraz uzyskać dostęp do każdego serwera narzędzi połączonego przez Model Context Protocol. Współautorzy raportu Wiz, Amitai Cohen i Yaara Shriki, połączyli ten dostęp z wykonaniem kodu na poziomie roota i z kradzieżą poświadczeń IAM chmury hosta. Ten opis opiera się na raporcie Wiz, własnych biuletynach bezpieczeństwa LiteLLM oraz późniejszym wpisie CISA w wykazie Known Exploited Vulnerabilities, a archiwum incydentów AI przechowuje ten rekord obok sąsiednich rekordów, z których każdy ma własne źródła, poziom istotności i ocenę pewności.

Data publikacji to jedyna data, jaką zawiera rekord, i jest to data publikacji. Skan stojący za nagłówkiem przeprowadzono w lutym 2026 r.; dwie opisane przez Wiz wady kodu miały poprawki wydane najpóźniej do połowy maja, w wydaniach, które według własnej dokumentacji projektu datuje się na marzec i maj; identyfikatory CVE wydano w lipcu; a wpis w katalogu pojawił się we wrześniu. Niemal wszystko w raporcie było już przestarzałe, zanim go wydrukowano, co stanowi znaczną część argumentacji raportu.

Te 9,6% pochodzi z jednego skanu, a Wiz twierdzi, że jego własnego sierpniowego badania uzupełniającego nie można z nim porównać.

Pomiar jest prosty, a Wiz jasno opisuje swoją metodę: 3 074 wystawione do internetu proxy LiteLLM znalezione przez Shodan w lutym 2026 r., z których każde sprawdzono, czy uwierzytelni się przy użyciu udokumentowanego przykładowego klucza. Spośród nich 294 to zrobiło. W tej grupie 191 nie miało w ogóle skonfigurowanego klucza głównego i zaakceptowałoby dowolny podany mu ciąg; pozostałe pozostawiły wartość zastępczą z przewodnika konfiguracji. Żaden z tych trybów awarii nie wymaga błędu oprogramowania. Oba potrzebują jedynie adresu bramy i wartości podanej w README samego projektu.

To również skan przeprowadzony przez jednego dostawcę. Liczba podana przez Wiz została powtórzona przez AI Safety Initiative Cloud Security Alliance 10 września oraz przez The Hacker News tego samego dnia, ale oba źródła powtarzają ją, wskazując źródło, a na potrzeby tego artykułu nie udało się znaleźć niezależnego potwierdzenia liczby 3,074. Wiz przeprowadził drugi skan w sierpniu 2026 r. i znalazł ponad 85 000 wystąpień, około dwadzieścia siedem razy więcej niż wynosiła liczba z lutego. Firma twierdzi, że większość z nich to prawdopodobnie honeypoty lub wdrożenia testowe oraz że tych dwóch liczb nie można porównywać. Nie istnieje aktualna liczba ekspozycji, a każdy artykuł, który taką liczbę podaje, powtarza dane z lutego.

Kolejna liczba w raporcie pochodzi z własnej telemetrii Wiz, a nie ze skanowania: firma twierdzi, że LiteLLM występuje w około jednej trzeciej obserwowanych przez nią środowisk chmurowych. To spojrzenie dostawcy na własną bazę klientów, które warto traktować z dystansem, ale wyjaśnia, dlaczego badacze uznali błędną konfigurację bramy za problem chmurowy, a nie aplikacyjny.

Klucz główny pełni zarówno rolę poświadczenia administratora, jak i przełącznika włączającego uwierzytelnianie.

Konstrukcja LiteLLM sprawia, że jeden sekret pełni dwie funkcje. Klucz główny uwierzytelnia żądania administracyjne, a to jego obecność w ogóle umożliwia uwierzytelnianie: bez klucza głównego oraz bez konfiguracji JWT lub OAuth2 proxy działa otwarcie i akceptuje każde żądanie. Wiz podeszło do bazy kodu z Claude Code firmy Anthropic, szukając funkcji, które przyjmują dane kontrolowane przez użytkownika i przekazują je do kontekstu wykonania, a handler uwierzytelniania był jedną z trzech powierzchni, które wskazało.

Przed wersją v1.82.0-stable konsekwencja tego drugiego zadania była gorsza niż otwarte proxy. Wiz odkrył, że gdy nie ustawiono klucza głównego, handler uwierzytelniania przypisywał rolę PROXY_ADMIN każdemu przychodzącemu żądaniu, więc nieuwierzytelniony wywołujący nie tylko został wpuszczony, ale wpuszczony jako administrator. Pull request #22095, cytowany w raporcie, zmienił rolę domyślną na INTERNAL_USER i dodał sprawdzanie uprawnień administratora do punktów końcowych guardrail.

Administracyjny dostęp do bramy nie jest wąskim przywilejem. Instancja przechowuje klucz API dla każdego dostawcy, do którego kieruje ruch, co czyni ją celem ataków typu LLMjacking — uruchamiania obciążeń modeli na koszt ofiary. Widzi prompty i uzupełnienia. Łączy się na zewnątrz z serwerami narzędzi MCP, które w wewnętrznym wdrożeniu prawdopodobnie obejmują systemy śledzenia zgłoszeń, czat, bazy danych i potoki wdrożeniowe.

Wiz zademonstrował także ścieżkę od tego stanowiska administracyjnego do tożsamości chmurowej hosta. LiteLLM pozwala administratorowi zarejestrować trasę przekazywania do dowolnego docelowego adresu URL, a cel nie jest sprawdzany pod kątem prywatnych zakresów adresów, localhost ani adresu metadanych chmury. Wskazanie trasy na usługę metadanych instancji zwraca poświadczenia IAM, na których działa obciążenie. Przełączenie usługi metadanych na IMDSv2, które normalnie udaremnia tę klasę fałszowania żądań, wymagając osobno uzyskanego tokena sesji, nie pomaga: LiteLLM przekazuje dowolny nagłówek z prefiksem x-pass- do celu po usunięciu prefiksu, więc nagłówek tokena można przemycić. Wiz twierdzi, że funkcja prawdopodobnie działa zgodnie z przeznaczeniem w modelu zagrożeń zakładającym zaufanie do administratorów, a zatem nie ma przypisanego CVE ani poprawki.

Ten ostatni akapit jest demonstracją, a nie zaobserwowanym atakiem. The Hacker News, omawiając badanie 10 września, podaje, że żadne źródło nie donosi, by ktokolwiek przeprowadził to przeciw rzeczywistemu wdrożeniu, oraz że wymaga to najpierw dostępu administratora. Sposób przedstawienia sprawy przez Wiz jest taki sam: pass-through to właściwość konstrukcyjna, która staje się podatnością tylko wtedy, gdy dane uwierzytelniające administratora są ciągiem znaków z dokumentacji.

8.8 i 2.1 oceniają ten sam łańcuch z różnych pozycji startowych

Dwa CVE zawierają ustalenia techniczne, a ich opublikowane punktacje są niemal skrajnie różne.

CVE-2026-59822 to obejście uwierzytelniania w MCP, a biuletyn LiteLLM ocenia je jako High — 8,8 w CVSS 4.0 — bez wymaganych uprawnień, bez interakcji użytkownika i bez wymagań dotyczących ataku. Punkt końcowy MCP ma własny mechanizm uwierzytelniania, zbudowany tak, aby akceptować klucz LiteLLM albo token OAuth2 przeznaczony dla nadrzędnego serwera narzędzi. Gdy token nie przeszedł walidacji LiteLLM, mechanizm przechwytywał 401 i zamiast odrzucić żądanie, podstawiał pusty obiekt uwierzytelniania. W związku z tym każdy token Bearer tworzył prawidłową sesję MCP, w tym pojedynczy znak: proof of concept Wiz wysyła jednoliterowy token bearer i otrzymuje z powrotem identyfikator sesji. Błąd naprawiono w wersji 1.84.0.

CVE-2026-59821 to luka w guardrailu, a biuletyn tego samego projektu ocenia ją jako niską (Low), 2.1, z wymaganymi wysokimi uprawnieniami i występującymi wymaganiami dotyczącymi ataku. Funkcja guardrail z niestandardowym kodem pozwala administratorowi przesłać kod Python, który serwer kompiluje i wykonuje. Punkt końcowy testowy interfejsu Web UI walidował kod względem listy zabronionych wzorców i usuwał wbudowane funkcje (builtins) przed uruchomieniem; produkcyjne punkty końcowe tworzenia i aktualizacji nie robiły ani jednego, ani drugiego. Python ponownie zapełnia wbudowane funkcje, gdy ich brak, więc przesłany kod docierał do biblioteki standardowej. Proof of concept firmy Wiz rejestruje guardrail, który uruchamia polecenie powłoki w momencie rejestracji — przed jakimkolwiek żądaniem do modelu — i zwraca wynik polecenia jako powód blokady, który w jego teście zwrócił root. Luka została naprawiona w wersji v1.82.0-stable.

Obie opisy są zgodne, a zdanie godzące je znajduje się w samym biuletynie: LiteLLM zauważa, że we wdrożeniach bez skonfigurowanego klucza głównego wywołujący mogą być traktowani jako administratorzy proxy, co właśnie postawiło endpointy guardrail w zasięgu. A 2.1 zakłada uprzywilejowanego użytkownika. Łańcuch Wiz opisuje to, co dzieje się, gdy domyślny klucz czyni każdego wywołującego uprzywilejowanym. Żaden z wyników nie myli się co do własnego punktu wyjścia; różnią się co do tego, jak często ten punkt wyjścia jest wolny.

Do twierdzenia Wiz, że po wersji 1.82.0 atakujący dysponujący domyślnym kluczem mógł wykonywać kod wyłącznie wewnątrz piaskownicy, należy dodać jedno zastrzeżenie. Hacker News wskazuje na osobną poradę z maja 2026 r., CVE-2026-40217, która opisuje ucieczkę z tej piaskownicy za pomocą technik bajtkodu w wersjach od 1.81.8 do wersji przed 1.83.10, wewnątrz procesu proxy, który – jak podaje porada – działa jako root w domyślnym obrazie kontenera. Dotarcie do tego punktu końcowego wymaga poświadczeń administratora proxy, a tym właśnie jest klucz główny.

8.8 również nie jest uniwersalne. Nota badawcza Cloud Security Alliance zauważa, że biuletyn GitLab podaje dla tej samej luki ocenę bazową 8,2 i nie rozstrzyga między obiema metodologiami, wskazując jedynie, że obie mieszczą się w wysokim zakresie. Wysoka waga tego rekordu nie zależy od tego, która liczba zostanie użyta.

Jedno CVE zostało wykorzystane w rzeczywistych atakach; w przypadku ekspozycji klucza domyślnego nie wskazano żadnej ofiary

CISA dodała CVE-2026-59822 do katalogu Known Exploited Vulnerabilities 2 września 2026 r. i wyznaczyła federalnym agencjom cywilnym termin usunięcia luki na 16 września 2026 r.; wpis w katalogu zawiera CWE-287 i CWE-306 — nieprawidłowe uwierzytelnianie i brak uwierzytelniania. Notatka Cloud Security Alliance podaje, że branżowe serwisy monitorujące określiły ją jako pierwszą lukę specyficzną dla MCP na tej liście. Firma Wiz opublikowała szczegóły zaobserwowanego wykorzystania: od 7 lipca 2026 r. jej honeypoty rejestrowały żądania zawierające jednoliterowe tokeny bearer sondujące punkty końcowe listowania modeli, a Wiz nie opisuje żadnego innego wykorzystania tej luki.

Dla klucza domyślnego nie istnieje nic porównywalnego. Nie wymienia się żadnej ofiary, nie wskazuje się żadnej bramy jako przejętej za pośrednictwem sk-1234 i żadna telemetria nie pokazuje wykorzystywania 294 hostów. Wpis archiwalny nie odnotowuje żadnych rzeczywistych szkód, co jest stwierdzeniem o dowodach, a nie o mechanizmie: ekspozycję zmierzono, ale nie zaobserwowano jej wykorzystania.

Dwie inne pozycje są często zestawiane z nimi, ale nie są tym samym. CVE-2026-42271, czyli wykonanie poleceń przez dwa testowe punkty końcowe MCP, to luka LiteLLM, której atakujący faktycznie użyli do uruchomienia kodu; honeypoty Wiz odnotowały, że za jej pomocą instalowano koparkę kryptowalut. Opublikowany przez Microsoft przypadek z sierpnia 2026 r., w którym intruz odczytał zmienne środowiskowe kontenera bramy, odzyskał klucz główny, klucze dostawców i ciąg połączenia do bazy danych, a następnie skopiował rekordy z tabel modeli i kluczy wirtualnych LiteLLM, ilustruje, ile warta jest skompromitowana brama, a nie nowy sposób dostania się do środka; The Hacker News donosi, że Microsoft ocenia punkt wejścia jako łańcuch CVE-2026-42271.

Stanowisko opiekunów projektu jest takie, że brak klucza głównego to błąd konfiguracji, a nie luka w zabezpieczeniach.

Polityka bezpieczeństwa LiteLLM jest jednoznaczna. Wśród kwestii poza zakresem wymienia „ataki wymagające błędnej konfiguracji podczas instalacji (np. nieustawienie master_key w konfiguracji proxy)” i stwierdza, że są one wyraźnie poza zakresem i nie są uznawane za podatności. Wiz dochodzi do zgodnego wniosku z drugiej strony, gdy nazywa zachowanie pass-through prawdopodobnie działającym zgodnie z zamierzeniem.

To stanowisko zostało przetestowane publicznie. 15 sierpnia 2026 r. badacz otworzył zgłoszenie #37054 na GitHubie, informując, że proxy z nieustawioną zmienną LITELLM_MASTER_KEY uwierzytelnia dowolną wartość klucza oraz że dostarczany plik docker-compose nie ustawia żadnej. Zgłoszenie zostało zamknięte 30 minut później, a jedyny komentarz pod nim pochodzi z tego samego konta: powołuje się on na instrukcję z polityki bezpieczeństwa, że zgłoszenia należy przekazywać poprzez prywatne raporty o podatnościach, a nie publiczne zgłoszenia, przeprasza za publiczne zgłoszenie i mówi, że pełny raport został zamiast tego przekazany ścieżką porad bezpieczeństwa. W wątku nie pojawia się żadna odpowiedź opiekuna, więc zapis pokazuje, że zgłaszający wycofuje publiczne zgłoszenie, a nie odpowiedź projektu na nie. Nic publicznego nie dokumentuje, co stało się z prywatnym zgłoszeniem.

Na potrzeby tego artykułu nie odnaleziono żadnego publicznego oświadczenia BerriAI, które broniłoby tej pozycji w odniesieniu do wrześniowego raportu lub ją rewidowało. Widoczna reakcja firmy znajduje się w jej notatkach o wydaniu i plikach konfiguracyjnych, a nie w prozie.

Egzekucja nastąpiła 3 października, dwadzieścia cztery dni po zgłoszeniu.

Dwie wady kodu zostały naprawione na długo przed raportem. Oś czasu ujawnienia Wiz odnotowuje wykonanie kodu zabezpieczającego zgłoszone 18 lutego 2026 r. i naprawione 25 lutego w wersji 1.82.0, obejście MCP naprawione 25 kwietnia w wersji 1.84.0, zaobserwowane wykorzystanie 7 lipca, identyfikatory CVE opublikowane 8 lipca oraz wpis w katalogu 2 września. Artefakty wydania mają późniejsze daty niż same poprawki: indeks pakietów pokazuje v1.82.0 na 1 marca 2026 r. i v1.84.0 na 14 maja, co wskazuje, kiedy każda poprawka stała się możliwa do zainstalowania, a nie kiedy została wprowadzona. Dwa rekordy wydań samego dostawcy datują te same poprawki później niż ta oś czasu. Wydanie v1.82.0-stable na GitHubie ma datę 11 marca 2026 r., a pakiet 1.82.0 w PyPI — 1 marca; v1.84.0 ma datę 14 maja 2026 r. w obu. Nic opublikowanego nie wyjaśnia tej luki i nie ma to znaczenia dla argumentu, ponieważ każda z tych dat przypada miesiące przed wrześniowym raportem. Dwa biuletyny GitHub dodają jeszcze trzecią datę: opublikowano je 30 czerwca 2026 r., trzy tygodnie przed identyfikatorami CVE, które według Wiz ukazały się 8 lipca.

To, czego żadne z tych wydań nie naprawiło, dotyczyło wartości domyślnej. Wiz poinformował, że na dzień 9 września klucz główny nadal był ustawiony na sk-1234 podczas instalacji LiteLLM przez Docker Compose lub pip install, a The Hacker News potwierdził, że przewodnik konfiguracji wciąż używał tej wartości tego dnia. Zmiana pojawiła się w v1.104.0, opublikowanej w Python Package Index 3 października 2026 r., której informacje o wydaniu wymieniają ją jako zmianę łamiącą zgodność: proxy odtąd odmawia uruchomienia z nieustawionym, pustym lub publicznie znanym kluczem głównym, wskazując źródło błędnej wartości w komunikacie błędu podczas uruchamiania i wypisując polecenie generujące bezpieczny klucz. Powiązany wpis odnotowuje zmianę polegającą na zaprzestaniu reklamowania publicznie znanej słabej wartości klucza głównego w dostarczanych konfiguracjach i przykładach, a plik docker-compose w głównej gałęzi projektu nie ustawia już żadnego klucza.

To sekwencja, którą warto zachować. Kod został załatany wiosną. Wartość, która sprawiła, że te poprawki były niewystarczające, pozostawała w instrukcjach instalacji aż do października, i dopiero wtedy oprogramowanie zaczęło ją odrzucać. Nic w którejkolwiek z poprawek nie wymagało, aby druga czekała.

Nie zmieniła się natomiast trasa pass-through do usługi metadanych instancji. Nadal nie ma ona przypisanego CVE ani poprawki, ponieważ projekt zakłada, że administratorzy są zaufani. Lista zaleceń naprawczych Wiz obejmuje zatem głównie działania operatora: silny i unikalny klucz główny, przegląd zarejestrowanych mechanizmów ochronnych, po którym następuje restart procesu w celu wyczyszczenia kodu przechowywanego w pamięci, audyt punktów końcowych pass-through z ograniczonym ruchem wychodzącym kontenerów oraz role IAM z najniższymi uprawnieniami. Żadnego z tych czterech elementów nie da się osiągnąć wyłącznie przez aktualizację.

Czego nie stwierdza materiał dowodowy

• Nie odnaleziono niezależnej replikacji skanu obejmującego 3 074 hosty. Wartość 9,6% to pomiar firmy Wiz, a każdy inny opis tego wyniku powtarza tę liczbę z podaniem źródła.

• Nie ma obecnie aktualnej liczby ekspozycji. Sierpniowa kontrola uzupełniająca wykryła ponad 85 000 instancji, które według Wiz to głównie honeypoty lub wdrożenia testowe i nie można ich porównywać z liczbą z lutego.

• Brak ofiary. Nic w dokumentacji nie wskazuje na bramę, operatora ani konto chmurowe przejęte za pomocą domyślnego klucza, a wykorzystanie opisane przez Wiz dotyczy obejścia MCP, a nie sk-1234.

• Brak dowodów na to, że wykorzystano 294 hosty. Skan sprawdził, czy dokonałyby uwierzytelnienia, co jest słabszym twierdzeniem niż wykazanie, że ktokolwiek to zrobił.

• Brak ustalonego poziomu istotności dla wady zabezpieczenia. Wiz i opiekunowie projektu opisują to samo zachowanie i oceniają je bardzo różnie, a różnica dotyczy uprawnień, o których każda ze stron zakłada, że napastnik już je posiada.

Wiz jest również dostawcą rozwiązań z zakresu bezpieczeństwa chmury, który sprzedaje wykrywanie tego rodzaju ekspozycji, a raport zamyka sekcja opisująca, w jaki sposób własne produkty firmy identyfikują wdrożenia LiteLLM, podatne wersje i instancje shadow. To kontekst pomagający czytać sekcję dotyczącą remediacji, a nie powód, by lekceważyć pomiar, którego szczegóły techniczne potwierdzają własne biuletyny opiekunów projektu.

Ta część zapisu, która wykracza poza LiteLLM, to odstęp między dwiema datami. Podatność zamknięto wiosną. Domyślne ustawienie, przez które podatność miała znaczenie dla osoby postronnej, wciąż było drukowane w instrukcji instalacji we wrześniu, a oprogramowanie dopiero w październiku zaczęło je odrzucać. Operatorzy, którzy zmienili ten ciąg, nie musieli czekać na nic z tego.