LiteLLM-kwetsbaarheid CVE-2026-42271 en de Starlette BadHost-bypass: een kettingreactie met maximale impact

• POST /mcp-rest/test/connection

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

Beide eindpunten accepteren een volledige MCP-serverconfiguratie in de request body, inclusief de velden Cmd, args en env. Deze worden door het stdio-transport gebruikt om processen te starten . Wanneer een ingelogde gebruiker een van deze eindpunten aanroept met zo'n configuratie, voert LiteLLM het opgegeven commando als een subproces uit op de hostmachine. Dit gebeurt met dezelfde rechten als het LiteLLM-proxyproces .

Oorspronkelijk werd dit door BerriAI, de maker van LiteLLM, gemeld als een kwetsbaarheid die authenticatie vereist. Een aanvaller had een geldige API-sleutel nodig om de eindpunten te bereiken. De controle op gebruikersrollen ontbrak, waardoor zelfs een interne gebruiker met minimale rechten kwaadaardige commando's kon uitvoeren . Maar daar bleef het niet bij.

De Starlette 'BadHost'-bypass die de inlogcontrole omzeilt

De tweede kwetsbaarheid is CVE-2026-48710, door onderzoekers 'BadHost' genoemd. Dit is een fout in de validatie van de Host-header in Starlette, het lichte ASGI-framework dat de basis vormt voor FastAPI, vLLM en duizenden andere Python-webapplicaties – inclusief LiteLLM . Alle Starlette-versies van 0.8.3 tot en met 1.0.0 zijn kwetsbaar .

De kern van het probleem is een verschil in interpretatie tussen de routering van inkomende verzoeken en de manier waarop Starlette de URL reconstrueert . De ASGI-routeringslaag gebruikt het ruwe HTTP-pad uit het verzoek om te bepalen welk eindpunt wordt aangesproken. Echter, request.url – de URL zoals de applicatie die ziet – wordt opnieuw opgebouwd door de ruwe Host-headerwaarde aan het verzoekpad te plakken, zonder deze goed te valideren .

Door speciale scheidingstekens zoals ? of # in de Host-header te injecteren, kan een aanvaller request.url.path compleet anders laten lijken dan het daadwerkelijk geroute pad . De middleware voor authenticatie ziet een onschuldig pad zoals /, terwijl de router het verzoek op de achtergrond alsnog naar het échte, mogelijk gevoelige eindpunt stuurt. Elke authenticatiecode die blindelings vertrouwt op request.url.path kan zo simpel worden omzeild .

De combinatie: van 8.7 naar de maximale score van 10.0

De authenticatie-decorator van LiteLLM controleert request.url.path om te bepalen of een verzoek een geldige API-sleutel nodig heeft. De BadHost-bypass stelt een aanvaller in staat die URL zo te manipuleren dat de middleware denkt dat het om een onbeveiligd pad gaat, terwijl de ASGI-router het verzoek tegelijkertijd naar een van de kwetsbare MCP-eindpunten stuurt .

Dit verwijdert de enige toegangsbarrière die tussen het internet en het uitvoeren van commando's op de server stond. Een aanvaller zonder geldige inloggegevens en zonder eerdere toegang tot het netwerk kan met één speciaal geprepareerd HTTP-verzoek authenticatie omzeilen en besturingssysteemcommando's uitvoeren op de LiteLLM-host . Horizon3.ai bevestigde dat deze aanvalsketen werkt en kende er de gecombineerde CVSS-score van 10.0 aan toe – de maximale ernst .

Wat aanvallers kunnen doen met deze toegang

Succesvolle exploitatie geeft aanvallers de macht om commando's uit te voeren met de rechten van het LiteLLM-proxyproces. De impact reikt daarmee direct veel verder:

• Willekeurige commando's uitvoeren: Aanvallers kunnen backdoors, malware, cryptominers of andere software installeren, afhankelijk van de rechten van het hostproces .
• Grootschalige diefstal van inloggegevens: De LiteLLM-proxy fungeert als centrale toegangspoort tot tientallen AI-diensten. Het slaat API-sleutels op voor onder andere OpenAI, Anthropic, Azure, AWS Bedrock en Google in zijn database of omgevingsvariabelen . Via dit lek kunnen aanvallers in één klap alle opgeslagen sleutels buitmaken.
• Laterale beweging binnen de AI-infrastructuur: Met gestolen cloud-API-sleutels en shell-toegang tot de proxyserver kunnen aanvallers zich verplaatsen naar gekoppelde diensten, interne MCP-servers, vectordatabases en onderliggende agent-frameworks .
• Gevolgen voor het bredere ecosysteem: De BadHost-fout in Starlette treft meer dan 400.000 afhankelijke projecten, waaronder FastAPI-applicaties, vLLM-servers en MCP-implementaties. Overal waar authenticatie op basis van het pad wordt gebruikt met een kwetsbare Starlette-versie, is dezelfde bypass mogelijk .

Waarom de actie van CISA de urgentie verhoogt

Dat CISA CVE-2026-42271 op 8 juni 2026 aan de KEV-catalogus heeft toegevoegd, bevestigt dat de kwetsbaarheid niet theoretisch is: aanvallers maken er nu actief misbruik van . Onder de Amerikaanse Binding Operational Directive (BOD 22-01) moeten alle federale agentschappen kwetsbaarheden op de KEV-lijst binnen een strikte termijn patchen. CISA beveelt alle organisaties, publiek én privaat, met klem aan om toevoegingen aan de KEV-catalogus als een noodgeval te behandelen .

Directe stappen om het lek te dichten

De oplossing voor de gecombineerde aanval vereist updates op twee fronten, plus extra verdedigingsmaatregelen om blootgestelde inloggegevens aan te pakken:

1. Update LiteLLM naar versie 1.83.7 of nieuwer. Deze release verwijdert de mogelijkheid voor de MCP-test-eindpunten om door gebruikers opgegeven commando's uit te voeren .
2. Update Starlette naar versie 1.0.1 of nieuwer. De patch valideert inkomende Host-headers volgens de officiële URL-specificatie en negeert headers met ongeldige tekens .
3. Vervang onmiddellijk alle opgeslagen inloggegevens. Ga ervan uit dat elke API-sleutel of toegangstoken die de LiteLLM-proxy ooit heeft opgeslagen, gecompromitteerd is. Roteer alle sleutels voor OpenAI, Anthropic, Azure, AWS en andere diensten en controleer factureringsoverzichten op ongeautoriseerd gebruik .
4. Blokkeer de kwetsbare eindpunten op de reverse proxy of WAF. Als extra beveiligingslaag tijdens het uitrollen van patches, configureer je de reverse proxy of Web Application Firewall (WAF) zo dat verzoeken naar

   POST /mcp-rest/test/connection

   en

   POST /mcp-rest/test/tools/list

   worden geblokkeerd voordat ze de applicatie bereiken .
5. Voer een audit uit op verdachte activiteiten uit het verleden. Controleer de logs van de LiteLLM-proxy op ongebruikelijke activiteit op de MCP-test-eindpunten, met name verzoeken van onverwachte IP-adressen of met gemanipuleerde Host-headers .

De maximale CVSS-score van 10.0, actieve exploitatie in de praktijk en de toevoeging aan de CISA KEV-lijst maken dit een spoedgeval voor elke organisatie die LiteLLM of Starlette-gebaseerde diensten gebruikt. Het tijdsvenster tussen actieve exploitatie en diefstal van inloggegevens is reeds geopend; patchen en sleutels roteren is nu de hoogste prioriteit.