CISA dodaje do KEV obejście uwierzytelniania MCP w LiteLLM: wystarczył dowolny token Bearer

2 września 2026 r. amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (Cybersecurity and Infrastructure Security Agency) dodała CVE-2026-59822 do swojego katalogu Known Exploited Vulnerabilities jako „BerriAI LiteLLM Improper Authentication Vulnerability”, jedną z siedmiu luk w partii z tego dnia. Błąd znajduje się w punkcie końcowym MCP Streamable HTTP LiteLLM: gdy walidacja klucza LiteLLM kończyła się niepowodzeniem, mechanizm awaryjny przekazywania OAuth2 podstawiał pusty obiekt UserAPIKeyAuth() zamiast odrzucić żądanie, więc dowolny sfałszowany nagłówek Authorization Bearer otwierał uwierzytelnioną sesję MCP. Atakujący, który dotarł do tego punktu końcowego, mógł wylistować i wywołać każde narzędzie MCP skonfigurowane w bramie, a za pośrednictwem tych narzędzi dotrzeć do usług stojących za nimi. Dotknięte są wszystkie wersje przed 1.84.0, a federalnym agencjom cywilnym wyznaczono termin do 16 września na usunięcie podatności. Ten wpis — pozycja KEV dotycząca obejścia uwierzytelniania MCP w LiteLLM — jest jednym z wpisów w Archiwum Incydentów AI OrcaRouter, które zawiera pełny zestaw rekordów oraz sąsiednie wpisy dotyczące tego incydentu.

Powód, dla którego błąd w proxy ma większe znaczenie, niż sugeruje jego wynik CVSS, tkwi w tym, co znajduje się za proxy. Zespół Wiz ds. badań nad zagrożeniami mówi wprost: „Proxy LiteLLM może przechowywać klucze do każdego dostawcy modeli, do którego kieruje ruch, w tym OpenAI, Anthropic, Azure i Gemini. Może również działać z uprawnieniami IAM w chmurze i łączyć się z usługami wewnętrznymi poprzez serwery narzędzi MCP. Pojedyncze przejęcie może dać atakującemu dostęp do poświadczeń i usług znajdujących się poniżej proxy, nie tylko do samego proxy”. Wiz Research twierdzi, że odkryło tę lukę, a honeypoty Wiz później zarejestrowały próby jej wykorzystania.

Mechanizm: nieudana weryfikacja, która zwróciła prawidłową sesję

Własny komunikat doradczy BerriAI, GHSA-7488-6r32-c95q, opisuje usterkę w dwóch zdaniach: „Handler uwierzytelniania MCP obsługiwał przekazywanie OAuth2 dla źródłowych serwerów MCP, ale ścieżka awaryjna mogła zastąpić nieudaną walidację klucza LiteLLM pustym obiektem UserAPIKeyAuth(). Pozwalało to żądaniom ze sfabrykowanym nagłówkiem Authorization docierać do narzędzi MCP bez ważnego klucza LiteLLM”. Ważnym słowem jest fallback. Kod miał gałąź dla wdrożeń, które przekazują token OAuth źródłowego serwera MCP bezpośrednio dalej, a gdy walidacja klucza LiteLLM kończyła się niepowodzeniem, ta gałąź zwracała pusty obiekt uwierzytelniania zamiast błędu.

Pusty obiekt uwierzytelniania to nie to samo co brak obiektu uwierzytelniania. Kod downstream zobaczył pomyślnie skonstruowany obiekt UserAPIKeyAuth i kontynuował działanie, mimo że nie miał dołączonego dzierżawcy, użytkownika ani zakresu. Artykuł Wiz jest bardziej dosadny, jeśli chodzi o praktyczną konsekwencję: „gdy walidacja tokenu nie powiedzie się, zamiast odrzucić żądanie, serwer zwraca pusty obiekt UserAPIKeyAuth() bez żadnych ograniczeń. Dowolny token Bearer (nawet pojedynczy znak, np. x) zapewnia pełny dostęp do MCP.”.

To, co zyskuje atakujący, to menu. Protokół MCP udostępnia listę narzędzi, więc sesja, która się uwierzytelni, zwraca nazwy i schematy każdego narzędzia, do którego brama została skonfigurowana, aby dotrzeć — bazy danych, repozytoria kodu, wewnętrzne API, w przykładach Wiz. Komunikat doradczy dostawcy jasno opisuje skutek: „Atakujący mógłby użyć tego do wylistowania i wywołania skonfigurowanych narzędzi MCP oraz uzyskania dostępu do połączonych usług udostępnianych przez MCP”. Wywołania narzędzi są następnie wykonywane z uprawnieniami, jakie sam serwer proxy posiada wobec tych systemów zaplecza, co stanowi opisany przez Wiz problem koncentracji poświadczeń.

Poprawka w maju, CVE w lipcu, federalny termin we wrześniu

Daty nie układają się tak, jak czytelnik mógłby przypuszczać, a właśnie te luki są interesujące. LiteLLM 1.84.0 — pierwsza wersja, którą biuletyn wskazuje jako poprawioną — została przesłana do PyPI 14 maja 2026 r., zgodnie z metadanymi wydania samego indeksu pakietów. Identyfikator CVE zarezerwowano w programie CVE 7 lipca 2026 r., a rekord opublikowano następnego dnia, 8 lipca; wpis OSV PYSEC-2026-3479 pojawił się 23 lipca. Wpis KEV ukazał się 2 września, z terminem usunięcia zagrożenia do 16 września.

Z tego wynikają dwie rzeczy. Po pierwsze, poprawiona kompilacja była publicznie dostępna przez ponad trzy miesiące, zanim CISA umieściła tę lukę na liście jako wykorzystywaną — organizacje objęte terminem miały więc przez cały ten czas dostępną działającą aktualizację, a dodanie do KEV nie było momentem pojawienia się poprawki. Po drugie, od tego czasu różnica wersji jeszcze się powiększyła: obecne wydanie LiteLLM w PyPI to 1.106.5, opublikowane 27 października 2026. Wdrożenie pozostające na jakiejkolwiek wersji poniżej 1.84.0 jest teraz ponad dwadzieścia wydań minor do tyłu, a nie tylko o jedną poprawkę.

Co wynika z oferty, a co nie

Alert CISA dotyczący tej partii stwierdza, że wpisy są dodawane „na podstawie dowodów aktywnego wykorzystania”, a maszynowo czytelny wpis katalogu dla CVE-2026-59822 zawiera datę dodania 2 września 2026 r., termin 16 września 2026 r., wartość „Unknown” dla pola known-ransomware-campaign-use oraz dwie słabości: CWE-287 (niewłaściwe uwierzytelnianie) i CWE-306 (brak uwierzytelniania dla funkcji krytycznej).

• Ustalono: CISA oceniła tę lukę jako aktywnie wykorzystywaną i umieściła ją na federalnej liście działań naprawczych. Rekord SSVC NVD, przypisany koordynatorowi CISA i opatrzony datą 2 września 2026 r., określa wykorzystanie jako „aktywne”, automatyzowalność jako „tak”, a wpływ techniczny jako „częściowy”.

• Ustalono:eksploatację zaobserwowano w kontrolowanym środowisku. Wiz opublikował dane o ruchu w honeypotach pokazujące żądania z tokenami składającymi się z jednego znaku, sondujące punkt końcowy enumeracji modeli: żądanie GET do /v1/models z nagłówkiem „Authorization: Bearer x”. The Hacker News, informując o partii KEV 3 września, opisał tę samą aktywność jako zaobserwowane przez Wiz „próby eksploatacji z udziałem CVE-2026-59822 wymierzone w jego honeypoty w celu sondowania punktów końcowych enumeracji modeli”.

• Ustalono: oceny istotności istnieją i różnią się w zależności od frameworka. Biuletyn BerriAI ocenia tę lukę w CVSS 4.0 na 8,8 — wysoko — przy poufności wysokiej, integralności niskiej i dostępności braku; własna ocena NIST w CVSS 3.1, która jest podstawowa w NVD, określa ją na 8,2. Te dwie liczby opisują ten sam defekt w różnych systemach punktacji i nie należy ich porównywać tak, jakby jedna zastępowała drugą.

• Nie ustalono: żadnej wymienionej z nazwy ofiary. Ani alert CISA, ani biuletyn BerriAI, ani opracowanie Wiz, ani relacja The Hacker News nie wskazują organizacji, do której narzędzi MCP uzyskano dostęp za pośrednictwem tej luki, ani nie zgłaszają pozyskanych od niej danych uwierzytelniających lub danych. Publiczny zapis wykorzystania to telemetria honeypotów i federalne ustalenie, a nie ujawnione naruszenie bezpieczeństwa.

• Nie ustalono: że żadna grupa ransomware tego nie używa. Pole KEV ma wartość „Unknown”, którą przypisuje CISA — nie jest to ustalenie braku w jedną ani drugą stronę.

Czerwcowy precedens, a nie łańcuch zdalnego wykonania kodu

To druga luka w LiteLLM, która w 2026 r. trafiła do katalogu KEV, a wcześniejszą łatwo pomylić z tą. CVE-2026-42271, dodane 8 czerwca 2026 r. z terminem 22 czerwca, to wstrzyknięcie polecenia w punktach końcowych testowania serwera MCP w LiteLLM: Wiz opisuje punkty końcowe, które pozwalają użytkownikowi przetestować konfigurację serwera MCP przed jej zapisaniem, przy czym pole command jest przekazywane do wykonania w podprocesie bez walidacji. Atakujący przesłali fałszywą konfigurację serwera stdio, której polecenie pobrało i uruchomiło koparkę kryptowalut, oraz zwrócili wyglądające na prawidłowe uzgadnianie MCP, dzięki czemu test wydawał się zakończony sukcesem. Wpis CISA na ten temat wymienia CWE-78 i CWE-77 — wstrzyknięcie polecenia i argumentów, a nie uwierzytelnianie.

To właśnie ta luka tworzy łańcuch. Wiz twierdzi, że CVE-2026-42271 „można połączyć w łańcuch z obejściem walidacji nagłówka hosta w Starlette (CVE-2026-48710), aby uzyskać w pełni nieuwierzytelnione RCE”, oraz że zewnętrzni badacze powiązali grupę ransomware Qilin z aktywnym wykorzystywaniem tego łańcucha. CVE-2026-48710 dodano do katalogu KEV w tej samej partii z 2 września co obejście LiteLLM, z tym samym terminem 16 września, a własna nota katalogowa CISA dotycząca luki Starlette mówi, że można ją połączyć w łańcuch z CVE-2026-42271. Powiązanie z Qilin dotyczy tego zestawienia. Nie jest to ustalenie dotyczące CVE-2026-59822 i nic w przejrzanych źródłach nie wiąże tej grupy ransomware z obejściem uwierzytelniania.

Jedna różnica administracyjna odróżnia dwa wpisy LiteLLM: wymagane działanie w czerwcowym wpisie przywołuje BOD 22-01, starszą wiążącą dyrektywę operacyjną, natomiast wrześniowy wpis przywołuje BOD 26-04 „Priorytetyzowanie aktualizacji zabezpieczeń na podstawie ryzyka”. Alert CISA nie wyjaśnia tej zmiany, a katalog nie opatruje jej adnotacją.

Co się zmieniło po

Ścieżka naprawcza jest krótka. Biuletyn doradczy BerriAI zaleca aktualizację do wersji 1.84.0 lub nowszej i oferuje obejście dla zespołów, które nie mogą przejść od razu: „wyłącz trasy MCP lub zablokuj dostęp do /mcp/ i powiązanych punktów końcowych MCP na swoim odwrotnym serwerze proxy lub bramie API”. To obejście jest tępym narzędziem — usuwa możliwość zamiast ją ograniczać — ale to jedyny środek łagodzący, jaki dostawca wskazuje dla niezałatanych wdrożeń.

Tekst CISA dotyczący wymaganych działań w odniesieniu do punktów wejścia stawia agencje federalne przed tym samym dylematem: wdrożyć środki zaradcze zgodnie z instrukcjami dostawcy i z BOD 26-04 „albo zaprzestać korzystania z produktu, jeśli środki zaradcze są niedostępne”, przy czym odpowiedzialność za ocenę ekspozycji danego zasobu na internet spoczywa na każdej agencji. Dyrektywa wiąże wyłącznie federalne agencje cywilne władzy wykonawczej; CISA zachęca inne organizacje do przyjęcia takiego samego, opartego na ryzyku podejścia priorytetyzującego, choć tego nie wymaga.

To, czy ktokolwiek spoza honeypota podjął działania przed terminem, nie jest publicznie znane. Ani CISA, ani BerriAI nie opublikowały danych na temat tego, ile wdrożeń LiteLLM było narażonych, ile załatano przed 16 września ani do ilu udało się dotrzeć poprzez obejście.

Co pozostaje otwarte

Trzy luki warto omówić, zamiast je zatajać. Nie ma publicznego raportu o incydencie łączącego CVE-2026-59822 z konkretnym włamaniem, więc wpis w KEV opiera się na dowodach eksploatacji CISA i obserwacjach honeypotów Wiz, a nie na udokumentowanej ofierze. Nie ma oświadczenia dostawcy o tym, jak doszło do zapisania ścieżki awaryjnej w ten sposób ani jak długo istniała ona przed 1.84.0 — biuletyn opisuje wadę i jej poprawkę, a nie jej historię. A terminy w tej partii nie były jednolite: pięć z siedmiu wpisów dodanych 2 września miało termin 5 września, podczas gdy wpisy LiteLLM i Starlette miały termin 16 września. CISA nie podaje przyczyny.

To, co zostało ustalone, jest węższe i bardziej użyteczne niż wynik. Pojedynczy znak w nagłówku Authorization był w podatnych wersjach nieodróżnialny od prawidłowego klucza dla punktu końcowego MCP — a wersje, które zachowywały się w ten sposób, przestały być aktualne w maju 2026 r.