LiteLLM-sårbarhet oppnår kritisk 10.0 CVSS i kjedeangrep – krever umiddelbar nedstenging

• POST /mcp-rest/test/connection

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

Begge mottar en full MCP-serverkonfigurasjon i JSON-forespørselen, inkludert feltene Cmd, args, og env. Disse brukes av stdio-transporten for å starte serverprosesser . Når en autentisert bruker kaller et av endepunktene, tar LiteLLM den oppgitte Cmd-verdien og kjører den som en underprosess på vertsmaskinen. Prosessen får de samme operativsystemrettighetene som LiteLLM-proxyen selv .

Opprinnelig anså BerriAI dette som en autentisert RCE-feil – en angriper måtte ha en gyldig API-nøkkel for å nå endepunktene. Men historien sluttet ikke der.

Starrettes 'BadHost'-forbigåelse fjerner autentiseringskravet

Den andre sårbarheten er CVE-2026-48710, kalt 'BadHost' av forskere. Dette er en feil i valideringen av Host-headeren i Starlette, som er det lette ASGI-rammeverket som understøtter FastAPI, vLLM og tusenvis av andre Python-webbapplikasjoner – inkludert LiteLLM . Alle Starlette-versjoner fra 0.8.3 til 1.0.0 er rammet .

Hovedårsaken er en uoverensstemmelse i hvordan Starlette ruter innkommende forespørsler kontra hvordan den rekonstruerer nettadressen (URL) for applikasjonslogikken . Rutinglaget bruker den rå HTTP-banen, men request.url, som applikasjonens middleware ser, bygges ved å sette sammen den rå Host-headerverdien med forespørselsbanen uten forsvarlig validering .

Ved å sette inn spesialtegn som ? eller # i Host-headeren, kan en angriper få request.url.path til å se ut som en ufarlig bane, for eksempel /, mens ruteren sender forespørselen videre til det egentlige sårbare endepunktet . All autentiseringsmiddleware som baserer seg på request.url.path, kan dermed omgås fullstendig .

Slik lenkes de to feilene: Fra 8.7 til 10.0

LiteLLMs autentiseringsdekoratør sjekker request.url.path for å avgjøre om en forespørsel krever en gyldig API-nøkkel. Ved hjelp av BadHost-forbigåelsen kan en angriper manipulere denne nettadressen slik at autentiseringsmiddlewaren ser en ufarlig bane, mens ASGI-ruteren samtidig sender forespørselen til et av de sårbare MCP-endepunktene .

Dermed fjernes den eneste adgangskontrollen som sto mellom internett og vilkårlig kodekjøring. En angriper uten noen form for påloggingsinformasjon kan sende en enkelt, ondsinnet HTTP-forespørsel, omgå all autentisering og kjøre operativsystemkommandoer på LiteLLM-vertsmaskinen . Kombinasjonen har fått en CVSS-score på 10.0 – maksimal alvorlighetsgrad .

Hva en angriper kan gjøre

Vellykket utnyttelse gir angripere kommandokjøring med de samme rettighetene som LiteLLM-proxyprosessen. Trusselbildet utvides deretter raskt:

• Vilkårlig kodekjøring: Angripere kan installere bakdører, skadevare eller kryptominere .
• Omfattende legitimasjonstyveri: LiteLLM-proxyen lagrer API-nøkler for OpenAI, Anthropic, Azure, AWS Bedrock og andre tilkoblede tjenester i sin database . En vellykket utnyttelse kan trekke ut alle lagrede nøkler i én enkelt operasjon.
• Bevegelse sideveis i AI-infrastrukturen: Med stjålne skynøkler og skalltilgang kan en angriper bevege seg videre til interne MCP-servere, vektordatabaser, og tilknyttede agent-rammeverk .
• Større økosystemkonsekvenser: Starrettes BadHost-feil påvirker over 400 000 avhengige prosjekter, inkludert FastAPI, vLLM og MCP-servere, og eksponerer dem for samme type autentiseringsforbigåelse .

Derfor øker CISA hastverket

CISAs avgjørelse om å inkludere CVE-2026-42271 i KEV-katalogen 8. juni 2026 bekrefter at dette ikke er en teoretisk trussel. Angripere aktivt utnytter sårbarheten akkurat nå . Alle amerikanske føderale etater er pålagt å utbedre KEV-listede feil umiddelbart, og CISA anbefaler på det sterkeste at alle organisasjoner, offentlige som private, behandler slike tillegg som en nødprioritet .

Tiltak som må iverksettes umiddelbart

Å fikse det lenkede angrepet krever oppdateringer på to fronter, samt noen defensive dybdetiltak:

1. Oppgrader LiteLLM til versjon 1.83.7 eller nyere. Denne versjonen fjerner MCP-testendepunktenes evne til å kjøre brukerstyrte kommandoer direkte .
2. Oppgrader Starlette til versjon 1.0.1 eller nyere. Rettelsen validerer innkommende Host-headere mot URL-spesifikasjonen .
3. Roter absolutt alle lagrede hemmeligheter umiddelbart. Gå ut fra at alle API-nøkler, tilgangstokener og databasenøkler som proxyen noensinne har lagret, er kompromittert. Roter nøkler for alle tjenester, og sjekk faktureringsdashbord for uautorisert bruk .
4. Blokker endepunktene i omvendt proxy eller WAF. Som et defensivt lag mens oppgraderingene rulles ut, konfigurer din omvendte proxy eller brannmur til å avvise alle forespørsler til

   POST /mcp-rest/test/connection

   og

   POST /mcp-rest/test/tools/list

   .
5. Sjekk logger for tegn på inntrengning. Gå gjennom LiteLLMs logger for uvanlig aktivitet mot MCP-testendepunktene, spesielt forespørsler fra ukjente IP-adresser eller med manipulerte Host-headere .

Kombinasjonen av en CVSS-score på 10.0, aktiv utnyttelse og en plass på CISAs KEV-liste betyr at dette er et nødstilfelle. Du må behandle dette som en umiddelbar "lapp og roter"-hendelse. Vinduet for angripere er allerede åpent.