LiteLLM CVE-2026-42271: AI-gatewayn där en tvåstegsattack öppnar för fullständig fjärrkörning

Den öppna källkods-proxyn LiteLLM, som är avgörande för företag som kopplar ihop sina applikationer med stora språkmodeller, har drabbats av en katastrofal säkerhetsbrist. Den 8 juni 2026 lade USA:s cybersäkerhetsmyndighet CISA till CVE-2026-42271 – ett kommandoinjiceringsfel i BerriAI:s AI-gateway LiteLLM – i sin katalog över kända exploaterade sårbarheter (KEV), vilket bekräftar att angripare redan utnyttjar felet aktivt . Det som gör situationen särskilt akut är att säkerhetsforskare på Horizon3.ai har visat hur sårbarheten kan kedjas perfekt med en separat svaghet i det populära Python ASGI-ramverket Starlette för att uppnå det värsta tänkbara scenariot: oautentiserad fjärrkodskörning med den maximala CVSS-klassningen 10.0 .

Hur LiteLLM-felet fungerar i grunden

I sig själv är CVE-2026-42271 en allvarlig bugg med ett CVSS-poäng på 8.7 som påverkar alla LiteLLM-versioner från 1.74.2 till och med 1.83.6 . Problemet finns i två förhandsgranskningsändpunkter för MCP (Model Context Protocol), som var avsedda att låta användare testa en MCP-serverkonfiguration innan den sparas permanent:

• POST /mcp-rest/test/connection

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

Båda ändpunkterna tar emot en fullständig MCP-serverkonfiguration i JSON-förfrågningskroppen, inklusive fälten Cmd, args och env som används för att starta serverprocesser via stdio-transport . När en autentiserad användare anropar någon av ändpunkterna med denna konfiguration, tar LiteLLM det angivna kommandot och kör det som en delprocess på värddatorn, med samma operativsystemprivilegier som själva LiteLLM-proxyprocessen .

Ursprungligen rapporterade BerriAI detta som ett autentiserat fel för fjärrkodskörning – en angripare behövde en giltig API-nyckel för att nå ändpunkterna, och det fanns ingen rollbaserad kontroll för att begränsa vem som kunde anropa dem. Även en intern användare med låg behörighet kunde alltså köra godtyckliga kommandon på värddatorn . Men historien slutar inte där.

Starlette "BadHost"-felet som tar bort autentiseringskravet

Den andra sårbarheten är CVE-2026-48710, som fått smeknamnet "BadHost" av forskare. Detta är ett valideringsfel för HTTP-värdhuvudet i Starlette, det lättviktiga ASGI-ramverk som ligger till grund för FastAPI, vLLM och tusentals andra Python-webbapplikationer – inklusive LiteLLM . Alla Starlette-versioner från 0.8.3 till 1.0.0 påverkas .

Grundorsaken är en tolkningsskillnad mellan hur Starlette dirigerar (routar) inkommande förfrågningar och hur det återskapar webbadressen (URL:en) för applikationslogiken . Dirigeringslagret i ASGI använder den råa HTTP-sökvägen för att avgöra vilken ändpunkt som ska hantera förfrågan. Däremot byggs request.url – den URL som applikationens middleware och dekoratörer ser – upp genom att den råa värdhuvudet (Host headern) sammanfogas med förfrågningssökvägen, utan korrekt validering .

Genom att injicera tecken som ? eller # – vilka fungerar som avgränsare mellan auktoritetsdel och sökvägsdel i en URI – i värdhuvudet, kan en angripare få request.url.path att se helt annorlunda ut än den faktiska, dirigerade sökvägen . Middlewaren tror att den ser en ofarlig sökväg som /, medan routern i bakgrunden skickar förfrågan till den verkliga målsökvägen. All väg-baserad autentiseringsmiddleware som litar på request.url.path kan därmed trivialt kringgås .

När kedjan sluts: Från 8.7 till 10.0

LiteLLM:s autentiseringsdekoratör kontrollerar request.url.path för att avgöra om en förfrågan kräver en giltig API-nyckel. "BadHost"-felet låter en angripare manipulera denna URL så att autentiseringsmiddlewaren ser en sökväg som inte kräver autentisering, samtidigt som ASGI-routern skickar förfrågan till en av de sårbara MCP-kommandoinjektionsändpunkterna .

Detta tar bort den enda åtkomstgrind som stod mellan internet och godtycklig kommandokörning. En angripare utan några inloggningsuppgifter och utan tidigare nätverksåtkomst kan skicka en enda specialtillverkad HTTP-förfrågan som helt kringgår autentiseringen och kör operativsystemkommandon på LiteLLM-proxyvärden . Horizon3.ai bekräftade att den fullständiga kedjan fungerar och tilldelade den ett kombinerat CVSS-poäng på 10.0 – maximal allvarlighetsgrad – eftersom den uppnår oautentiserad fjärrkodskörning .

Vad angripare kan göra med denna åtkomst

Ett framgångsrikt utnyttjande ger angripare möjlighet att köra kommandon med samma privilegier som LiteLLM-proxyprocessen. Därifrån växer hotbilden snabbt:

• Godtycklig kommandokörning: Angripare kan installera bakdörrar, skadlig kod, kryptominers eller annan programvara som processens behörigheter tillåter .
• Storskalig stöld av inloggningsuppgifter: LiteLLM-proxyn sitter mellan applikationer och dussintals LLM-leverantörer som OpenAI, Anthropic, Azure, AWS Bedrock och Google. Den lagrar API-nycklar för dessa tjänster i sin databas eller miljövariabler . Att utnyttja denna sårbarhet låter angripare stjäla alla lagrade inloggningsuppgifter i en enda operation.
• Sidoförflyttning genom AI-infrastruktur: Med stulna moln-API-nycklar och skalsession på proxyvärden kan angripare ta sig vidare till anslutna molntjänster, interna MCP-servrar, vektordatabaser och nedströms agentramverk .
• Konsekvenser för hela ekosystemet: Starlettes "BadHost"-fel påverkar över 400 000 beroende projekt, inklusive FastAPI-applikationer, vLLM-servrar, MCP-serverdistributioner och AI-agentramverk. Alla dessa som använder väg-baserad autentiseringsmiddleware på Starlette-versioner före 1.0.1 är lika sårbara för autentiseringsförbikoppling .

Varför CISA:s agerande höjer insatserna

CISA:s tillägg av CVE-2026-42271 till KEV-katalogen den 8 juni 2026 bekräftar att sårbarheten inte är teoretisk – angripare använder den aktivt just nu . Enligt det bindande operativa direktivet BOD 22-01 måste alla federala civila myndigheter i USA patchas för KEV-listade sårbarheter inom en angiven tidsram. CISA rekommenderar också starkt att alla organisationer, offentliga som privata, behandlar tillägg till KEV-katalogen som akuta patchprioriteringar .

Omedelbara åtgärdssteg

För att täppa till den kedjade attacken krävs uppdateringar på två fronter, plus flera fördjupade försvarsåtgärder för att hantera exponering av inloggningsuppgifter:

1. Uppgradera LiteLLM till version 1.83.7 eller senare. Denna version tar bort MCP-teständpunkternas förmåga att direkt köra användarlevererade kommandon, vilket helt stänger injektionsvektorn .
2. Uppgradera Starlette till version 1.0.1 eller senare. Patchen validerar inkommande värdhuvuden mot URL-specifikationen och ignorerar huvuden som innehåller ogiltiga tecken, vilket förhindrar det vägförvirringstrick som möjliggör autentiseringsförbikopplingen .
3. Rotera alla lagrade inloggningsuppgifter omedelbart. Utgå från att varje API-nyckel, åtkomsttoken eller databasinloggning som LiteLLM-proxyn någonsin har lagrat är komprometterad. Rotera alla nycklar för OpenAI, Anthropic, Azure, AWS och andra leverantörer, och kontrollera faktureringsöversikter för obehörig användning .
4. Blockera ändpunkterna i en omvänd proxy eller brandvägg. Som en fördjupad försvarsåtgärd medan patchningen rullas ut, konfigurera din omvända proxy eller webbapplikationsbrandvägg (WAF) att blockera alla förfrågningar till

   POST /mcp-rest/test/connection

   och

   POST /mcp-rest/test/tools/list

   innan de når applikationen .
5. Granska efter obehörig åtkomst i efterhand. Kontrollera LiteLLM-proxyns loggar för ovanlig aktivitet på MCP-teständpunkterna, särskilt förfrågningar från oväntade IP-adresser eller sådana med manipulerade värdhuvuden .

Den kombinerade CVSS 10.0-allvarlighetsgraden, aktiv exploatering ute i det vilda och CISA:s KEV-klassificering innebär att organisationer som kör tjänster via LiteLLM eller Starlette måste betrakta detta som en akut patch- och roteringshändelse. Fönstret mellan aktiv exploatering och stöld av inloggningsuppgifter är redan öppet.