LiteLLM CVE-2026-42271: Atak łańcuchowy na bramę AI osiąga CVSS 10.0

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Oba punkty końcowe przyjmują pełną konfigurację serwera MCP w ciele żądania JSON, w tym pola Cmd, args i env, których transport stdio używa do uruchamiania procesów serwera . Gdy uwierzytelniony użytkownik wywoła jeden z tych punktów z tą konfiguracją, LiteLLM bierze podaną wartość Cmd i uruchamia ją jako podproces na maszynie hosta, z takimi samymi uprawnieniami systemu operacyjnego, jakie ma sam proces proxy LiteLLM .

Pierwotnie BerriAI ujawniło to jako błąd uwierzytelnionego zdalnego wykonania kodu – atakujący potrzebował ważnego klucza API, aby dotrzeć do tych punktów końcowych, i nie było żadnej kontroli opartej na rolach, aby ograniczyć, kto może je wywołać. Nawet wewnętrzny użytkownik z niskimi uprawnieniami i dowolnym ważnym kluczem API proxy mógł wykonać dowolne polecenia na hoście . Ale na tym historia się nie skończyła.

Obejście BadHost w Starlette, które usuwa wymóg uwierzytelnienia

Drugą luką jest CVE-2026-48710, nazwana "BadHost" przez badaczy. Jest to błąd w walidacji nagłówka Host w Starlette, lekkim frameworku ASGI, który stanowi podstawę dla FastAPI, vLLM i tysięcy innych aplikacji webowych w Pythonie – w tym LiteLLM . Dotyczy to wszystkich wersji Starlette od 0.8.3 do 1.0.0 .

Główną przyczyną jest niezgodność analizy między tym, jak Starlette kieruje przychodzące żądania, a tym, jak rekonstruuje URL dla logiki aplikacji . Warstwa trasowania ASGI używa surowej ścieżki HTTP z żądania, aby zdecydować, który punkt końcowy ma je obsłużyć. Jednakże request.url – URL, który widzą middleware i dekoratory aplikacji – jest odbudowywany przez połączenie surowej wartości nagłówka Host ze ścieżką żądania, bez odpowiedniej walidacji .

Poprzez wstrzyknięcie znaków rozdzielających autorytet URI od ścieżki, takich jak ? lub #, do nagłówka Host, atakujący może sprawić, że request.url.path będzie wydawał się zupełnie inny niż rzeczywista trasowana ścieżka . Middleware widzi nieszkodliwą ścieżkę, taką jak /, podczas gdy router przekazuje żądanie do prawdziwego docelowego punktu końcowego za kulisami. Każde middleware uwierzytelniające oparte na ścieżce, które ufa request.url.path, może zostać łatwo ominięte .

Łączenie w łańcuch: z 8.7 do 10.0

Dekorator uwierzytelniania LiteLLM sprawdza request.url.path, aby określić, czy żądanie wymaga ważnego klucza API. Obejście BadHost pozwala atakującemu manipulować tym adresem URL tak, aby middleware uwierzytelniania widziało ścieżkę, która nie wymaga uwierzytelniania, podczas gdy router ASGI jednocześnie wysyła żądanie do jednego z podatnych punktów końcowych wstrzyknięcia poleceń MCP .

To usuwa jedyną bramę kontroli dostępu, która stała między internetem a dowolnym wykonaniem poleceń systemowych. Atakujący bez żadnych poświadczeń i bez wcześniejszego dostępu do sieci może wysłać pojedyncze spreparowane żądanie HTTP, które całkowicie omija uwierzytelnianie i uruchamia polecenia systemu operacyjnego na hoście proxy LiteLLM . Horizon3.ai potwierdziło, że pełny łańcuch działa i nadało mu łączną ocenę CVSS 10.0 – maksymalną dotkliwość – ponieważ umożliwia nieuwierzytelnione zdalne wykonanie kodu .

Co atakujący mogą zrobić z tym dostępem

Udane wykorzystanie daje atakującym wykonanie poleceń z uprawnieniami procesu proxy LiteLLM. Stąd pole do zagrożeń szybko się rozszerza:

• Dowolne wykonanie poleceń: Atakujący mogą instalować backdoory, złośliwe oprogramowanie, koparki kryptowalut lub dowolne inne programy, na które pozwalają uprawnienia procesu hosta .
• Kradzież poświadczeń na masową skalę: Proxy LiteLLM znajduje się między aplikacjami a dziesiątkami dostawców LLM. Przechowuje klucze API dla OpenAI, Anthropic, Azure, AWS Bedrock, Google i innych połączonych usług w swojej bazie danych lub zmiennych środowiskowych . Wykorzystanie tej luki pozwala atakującym wykraść wszystkie zapisane poświadczenia w jednej operacji.
• Ruch boczny przez infrastrukturę AI: Dzięki skradzionym kluczom API do chmury i dostępowi do powłoki na hoście proxy, atakujący mogą przechodzić do połączonych usług, wewnętrznych serwerów MCP, baz danych wektorowych i niższych struktur agentowych .
• Szersze implikacje ekosystemowe: Błąd BadHost w Starlette dotyczy ponad 400 000 zależnych projektów, w tym aplikacji FastAPI, serwerów vLLM, wdrożeń serwerów MCP i struktur agentów AI. Każdy z nich, który używa middleware uwierzytelniającego opartego na ścieżce w wersjach Starlette przed 1.0.1, jest podobnie narażony na ominięcie uwierzytelniania .

Dlaczego ruch CISA podnosi pilność sprawy

Dodanie przez CISA luki CVE-2026-42271 do katalogu KEV 8 czerwca 2026 roku potwierdza, że luka nie jest teoretyczna – atakujący aktywnie ją wykorzystują w tej chwili . Zgodnie z dyrektywą operacyjną BOD 22-01, wszystkie amerykańskie federalne agencje wykonawcze cywilne muszą załatać luki wymienione w KEV w wyznaczonym terminie. CISA zdecydowanie zaleca również wszystkim organizacjom, publicznym i prywatnym, aby traktowały wpisy do KEV jako priorytet awaryjnego łatania .

Kroki natychmiastowej naprawy

Poprawka dla połączonego exploita wymaga aktualizacji na dwóch frontach, plus kilku dodatkowych środków obrony w głąb, aby zaradzić narażeniu poświadczeń:

1. Zaktualizuj LiteLLM do wersji 1.83.7 lub nowszej. Ta wersja usuwa możliwość bezpośredniego wykonywania poleceń dostarczonych przez użytkownika przez punkty końcowe testowe MCP, całkowicie zamykając wektor wstrzyknięcia poleceń .
2. Zaktualizuj Starlette do wersji 1.0.1 lub nowszej. Poprawka waliduje przychodzące nagłówki Host zgodnie ze specyfikacją URL i ignoruje nagłówki zawierające nieprawidłowe znaki, zapobiegając sztuczce z pomyleniem ścieżki, która napędza obejście uwierzytelnienia .
3. Natychmiast zrotuj wszystkie zapisane poświadczenia. Załóż, że każdy klucz API, token dostępu lub poświadczenie bazy danych, które proxy LiteLLM kiedykolwiek przechowywało, zostało naruszone. Zrotuj wszystkie klucze OpenAI, Anthropic, Azure, AWS i innych dostawców oraz sprawdź panele rozliczeniowe pod kątem nieautoryzowanego użycia .
4. Zablokuj punkty końcowe na poziomie reverse proxy lub WAF. Jako środek obrony w głąb podczas wdrażania poprawek, skonfiguruj reverse proxy lub zaporę aplikacji internetowej, aby odrzucała każde żądanie do

   POST /mcp-rest/test/connection

   i

   POST /mcp-rest/test/tools/list

   , zanim dotrą one do aplikacji .
5. Przeprowadź audyt retrospektywny pod kątem nieuprawnionego dostępu. Sprawdź logi proxy LiteLLM pod kątem nietypowej aktywności na punktach końcowych testowych MCP, szczególnie żądań z nieoczekiwanych adresów IP lub z manipulowanymi nagłówkami Host .

Połączona ocena CVSS 10.0, aktywne wykorzystanie w środowisku naturalnym i oznaczenie CISA w katalogu KEV oznaczają, że organizacje korzystające z LiteLLM lub usług opartych na Starlette powinny traktować to jako zdarzenie awaryjne wymagające łatania i rotacji kluczy. Czas między aktywnym wykorzystaniem a kradzieżą poświadczeń jest już otwarty.