Krytyczna luka w LiteLLM umożliwia RCE. Aktywna eksploatacja obejmuje także łańcuch bez uwierzytelnienia

Wprowadzenie do problemu / definicja

LiteLLM, popularna brama AI i zestaw SDK dla modeli językowych, znalazł się w centrum poważnego incydentu bezpieczeństwa. Problem dotyczy podatności oznaczonej jako CVE-2026-42271, sklasyfikowanej jako command injection, która może prowadzić do uruchamiania dowolnych poleceń systemowych na hoście pośredniczącym, na którym działa proxy LiteLLM.

W praktyce oznacza to, że komponent często pełniący rolę centralnej warstwy integracyjnej dla usług AI może stać się punktem wejścia do dalszej kompromitacji środowiska. W określonych konfiguracjach luka może zostać dodatkowo połączona z odrębną podatnością w frameworku Starlette, co otwiera drogę do zdalnego wykonania kodu bez uwierzytelnienia.

W skrócie

• CVE-2026-42271 dotyczy testowych endpointów MCP w LiteLLM.
• Podatne są wersje od 1.74.2 do 1.83.6.
• Poprawka została udostępniona w wersji 1.83.7.
• Łańcuch z CVE-2026-48710 w Starlette może prowadzić do nieuwierzytelnionego RCE.
• Odnotowano aktywną eksploatację luki.

Kontekst / historia

LiteLLM jest szeroko wykorzystywany jako warstwa pośrednia między aplikacjami a zewnętrznymi dostawcami modeli AI. Ujednolica interfejsy API, wspiera routing żądań, kontrolę kosztów, logowanie oraz zarządzanie kluczami dostępowymi. Z punktu widzenia architektury bezpieczeństwa oznacza to, że rozwiązanie bardzo często funkcjonuje w newralgicznym miejscu infrastruktury.

W czerwcu 2026 roku pojawiły się informacje o aktywnej eksploatacji CVE-2026-42271. Badacze pokazali również, że podatność uznawana początkowo za wymagającą uwierzytelnienia może zostać przekształcona w pełne, nieuwierzytelnione zdalne wykonanie kodu poprzez połączenie z błędem walidacji nagłówka Host w Starlette. To kolejny przykład sytuacji, w której pozornie ograniczona luka aplikacyjna zyskuje krytyczny charakter po zestawieniu z podatnością w zależności frameworkowej.

Analiza techniczna

Źródłem problemu są dwa endpointy używane do testowania konfiguracji MCP przed jej zapisaniem: /mcp-rest/test/connection oraz /mcp-rest/test/tools/list. Endpointy te przyjmowały pełną konfigurację serwera, w tym parametry związane z uruchamianiem procesu dla transportu typu stdio.

W podatnych wersjach aplikacja mogła na podstawie dostarczonej konfiguracji utworzyć podproces na serwerze proxy LiteLLM. Jeżeli atakujący był w stanie wywołać te endpointy, mógł doprowadzić do wykonania arbitralnych komend z uprawnieniami procesu LiteLLM. Mamy więc do czynienia z klasycznym przypadkiem command injection osadzonym nie w podstawowej logice biznesowej, lecz w funkcjach testowych i pomocniczych.

Początkowo ograniczeniem miał być wymóg posiadania prawidłowego klucza API proxy. Jednak w środowiskach korzystających z podatnych wersji Starlette możliwe staje się obejście kontroli dostępu dzięki luce CVE-2026-48710 związanej z walidacją nagłówka Host. W takim scenariuszu podatność przechodzi z poziomu uwierzytelnionego nadużycia do pełnego, nieuwierzytelnionego RCE.

Po stronie producenta poprawka objęła między innymi ograniczenie dostępu do testowych endpointów do roli administracyjnej PROXY_ADMIN, co ujednolica politykę autoryzacji z mechanizmami wykorzystywanymi przy zapisie konfiguracji. Rekomendowana jest także aktualizacja zależności Starlette do wersji eliminującej problem z walidacją nagłówka Host.

Konsekwencje / ryzyko

Skala ryzyka jest wysoka, ponieważ LiteLLM często pośredniczy w obsłudze wrażliwych danych, takich jak klucze API do dostawców modeli, ustawienia routingu, logi żądań czy parametry integracyjne z innymi systemami. Kompromitacja hosta proxy może więc prowadzić nie tylko do przejęcia samej usługi, ale również do wtórnej kompromitacji całego ekosystemu AI w organizacji.

Możliwość wykonywania poleceń na serwerze otwiera drogę do typowych działań post-exploitation. Atakujący może pobierać dodatkowe narzędzia, eksfiltrować sekrety, prowadzić rekonesans sieciowy, wykonywać ruch boczny oraz utrwalać swoją obecność w środowisku. W zależności od sposobu wdrożenia skutki mogą objąć również systemy CI/CD, kontenery, klastry orkiestracyjne oraz aplikacje korzystające z LiteLLM jako centralnej bramy AI.

Dodatkowym czynnikiem podnoszącym wagę problemu jest aktywna eksploatacja. Oznacza to, że organizacje korzystające z podatnych wersji powinny traktować tę lukę jak incydent bezpieczeństwa wymagający pilnych działań weryfikacyjnych, a nie wyłącznie jako standardową aktualizację oprogramowania.

Rekomendacje

Najważniejszym krokiem jest aktualizacja LiteLLM do wersji 1.83.7 lub nowszej. Równolegle należy sprawdzić, czy środowisko nie wykorzystuje podatnych wersji Starlette, i wdrożyć wydanie usuwające problem z walidacją Host header.

• Zaktualizować LiteLLM do bezpiecznej wersji.
• Zweryfikować i zaktualizować zależność Starlette.
• Zablokować dostęp do endpointów testowych na poziomie reverse proxy, WAF lub API Gateway.
• Ograniczyć dostęp sieciowy do instancji LiteLLM wyłącznie do zaufanych segmentów.
• Przeanalizować logi pod kątem żądań do endpointów testowych, anomalii w nagłówku Host i nietypowych podprocesów.
• Przeprowadzić rotację kluczy API, tokenów i innych sekretów, jeśli istniało ryzyko kompromitacji.

Z perspektywy operacyjnej warto potraktować ten przypadek jako ostrzeżenie przed pozostawianiem funkcji testowych i administracyjnych dostępnych w środowisku produkcyjnym. Mechanizmy diagnostyczne powinny być domyślnie wyłączone lub ściśle ograniczone, segmentowane i chronione dodatkowymi warstwami autoryzacji.

Podsumowanie

CVE-2026-42271 w LiteLLM to poważna podatność typu command injection, która może prowadzić do wykonania dowolnych poleceń na hoście proxy. Jej znaczenie rośnie jeszcze bardziej w połączeniu z CVE-2026-48710 w Starlette, ponieważ taki łańcuch może umożliwić nieuwierzytelnione zdalne wykonanie kodu.

Dla organizacji wykorzystujących LiteLLM jako centralny punkt integracji z modelami AI oznacza to realne ryzyko dla sekretów, integralności środowiska i bezpieczeństwa systemów zależnych. Priorytetem powinny być szybkie aktualizacje, blokada podatnych endpointów, analiza śladów ewentualnej eksploatacji oraz rotacja poświadczeń.

Źródła

1. LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE — https://thehackernews.com/2026/06/litellm-flaw-cve-2026-42271-exploited.html
2. CVE-2026-42271 Chained with CVE-2026-48710 — https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/
3. BerriAI/litellm repository — https://github.com/BerriAI/litellm
4. Security Overview · BerriAI/litellm — https://github.com/BerriAI/litellm/security
5. CVE-2026-48710: Starlette BadHost HTTP Host-Header Path-Poisoning and Authentication Bypass — https://gist.github.com/alon710/cb3b1174ebf48e827d68142e3b30cd37