CISA lägger till LiteLLM:s MCP-autentiseringsbypass i KEV: Vilken Bearer-token som helst räckte

Den 2 september 2026 lade USA:s Cybersecurity and Infrastructure Security Agency till CVE-2026-59822 i sin katalog Known Exploited Vulnerabilities som "BerriAI LiteLLM Improper Authentication Vulnerability", ett av sju fel i den dagens omgång. Bristen finns i LiteLLM:s MCP Streamable HTTP-slutpunkt: när valideringen av en LiteLLM-nyckel misslyckades använde OAuth2-passthrough-fallbacken ett tomt UserAPIKeyAuth()-objekt i stället för att avvisa begäran, så att vilken påhittad Authorization Bearer-header som helst öppnade en autentiserad MCP-session. En angripare som nådde den slutpunkten kunde lista och anropa alla MCP-verktyg som gatewayen var konfigurerad med, och genom dessa verktyg nå tjänsterna bakom dem. Alla versioner före 1.84.0 är påverkade, och federala civila myndigheter fick till den 16 september på sig att åtgärda problemet. Den här posten – KEV-listningen för LiteLLM:s MCP-autentiseringsbypass – är en post i OrcaRouter AI Incident Archive, som innehåller hela postuppsättningen och intilliggande poster för denna incident.

Anledningen till att en bugg i en proxy spelar större roll än dess CVSS-poäng antyder är vad som finns bakom proxyn. Wiz hotforskningsteam säger det rakt ut: "En LiteLLM-proxy kan hålla nycklar för varje modellleverantör som den dirigerar till, inklusive OpenAI, Anthropic, Azure och Gemini. Den kan också köras med moln-IAM-behörigheter och ansluta till interna tjänster via MCP-verktygsservrar. En enda kompromiss kan ge en angripare åtkomst till autentiseringsuppgifterna och tjänsterna nedströms proxyn, inte bara till proxyn själv." Wiz Research säger att de upptäckte sårbarheten, och Wiz honungsfällor registrerade senare försök att utnyttja den.

Mekanismen: en misslyckad kontroll som returnerade en giltig session

BerriAI:s egen säkerhetsbulletin, GHSA-7488-6r32-c95q, beskriver defekten i två meningar: "MCP-autentiseringshanteraren stödde OAuth2-passthrough för uppströms MCP-servrar, men reservvägen kunde ersätta misslyckad validering av LiteLLM-nycklar med ett tomt UserAPIKeyAuth()-objekt. Detta gjorde att förfrågningar med en fabricerad Authorization-header kunde nå MCP-verktyg utan en giltig LiteLLM-nyckel." Det viktiga ordet är reservväg. Koden hade en gren för distributioner som skickar en uppströms MCP-servers OAuth-token rakt igenom, och när en LiteLLM-nyckel inte kunde valideras returnerade den grenen ett tomt autentiseringsobjekt i stället för ett fel.

Ett tomt autentiseringsobjekt är inte samma sak som inget autentiseringsobjekt. Kod nedströms såg en framgångsrikt konstruerad UserAPIKeyAuth och fortsatte, utan någon tenant, någon användare och något scope kopplat till den. Wizs redogörelse är mer rakt på sak om den praktiska konsekvensen: "när tokenvalideringen misslyckas returnerar servern, i stället för att avvisa begäran, ett tomt UserAPIKeyAuth()-objekt utan begränsningar. Vilken Bearer-token som helst (även bara ett enda tecken, t.ex. x) ger fullständig MCP-åtkomst."

Det en angripare får ut av detta är en meny. MCP-protokollet exponerar en lista över verktyg, så en session som autentiserar sig returnerar namnen och scheman för varje verktyg som gatewayen har konfigurerats att nå – databaser, kodarkiv och interna API:er, enligt Wiz exempel. Leverantörens säkerhetsmeddelande beskriver effekten rakt ut: "En angripare skulle kunna använda detta för att lista och anropa konfigurerade MCP-verktyg och komma åt anslutna tjänster som exponeras via MCP." Verktygsanropen körs sedan med vilken behörighet proxyn själv har gentemot dessa backend-system, vilket är problemet med koncentration av autentiseringsuppgifter som Wiz beskriver.

En rättelse i maj, en CVE i juli, en federal tidsfrist i september

Datumen går inte ihop på det sätt som en läsare kan förvänta sig, och det intressanta är luckorna. LiteLLM 1.84.0 – den första version som rådgivningen anger som åtgärdad – laddades upp till PyPI den 14 maj 2026, enligt paketindexets egen metadata för utgivningen. CVE-identifieraren reserverades hos CVE Program den 7 juli 2026 och posten publicerades dagen därpå, den 8 juli; OSV-posten PYSEC-2026-3479 följde den 23 juli. KEV-listningen kom den 2 september, med en åtgärdsfrist till den 16 september.

Två saker följer av detta. För det första: den patchade byggversionen var offentlig i mer än tre månader innan CISA listade sårbarheten som utnyttjad – så de organisationer som tidsfristen omfattade hade en fungerande uppgradering tillgänglig hela tiden, och tillägget i KEV var inte det ögonblick då en rättning blev tillgänglig. För det andra har versionsgapet vidgats sedan dess: den aktuella LiteLLM-utgåvan på PyPI är 1.106.5, uppladdad den 27 oktober 2026. En driftsättning som fortfarande ligger kvar på något under 1.84.0 är nu mer än tjugo minor-versioner efter, inte bara en patch efter.

Vad listningen fastställer, och vad den inte gör

CISA:s varning för batchen säger att tilläggen görs "baserat på bevis på aktiv exploatering", och katalogens maskinläsbara post för CVE-2026-59822 har ett tillagt datum den 2 september 2026, ett förfallodatum den 16 september 2026, ett värde för känd användning i ransomware-kampanj på "Okänd" och två svagheter: CWE-287 (otillräcklig autentisering) och CWE-306 (saknad autentisering för en kritisk funktion).

• Fastställt: CISA bedömde sårbarheten som aktivt utnyttjad och placerade den på den federala åtgärdslistan. NVD:s SSVC-post, tillskriven en CISA-samordnare och tidsstämplad 2 september 2026, registrerar utnyttjande som "aktivt", automatiserbart som "ja" och teknisk påverkan som "delvis".

• Fastställt: exploatering observerades i en kontrollerad miljö. Wiz publicerade honeypot-trafik som visade förfrågningar med enkelteckenstoken som sondrade en slutpunkt för modelluppräkning: en GET till /v1/models med "Authorization: Bearer x". The Hacker News, som rapporterade om KEV-batchen den 3 september, beskrev samma aktivitet som att Wiz observerade "exploateringsförsök som involverade CVE-2026-59822 mot dess honeypots för att sondera slutpunkter för modelluppräkning."

• Fastställt: båda allvarlighetsbetygen finns och skiljer sig mellan ramverk. BerriAI:s rådgivning bedömer sårbarheten enligt CVSS 4.0 till 8,8, hög, med hög konfidentialitet, låg integritet och ingen tillgänglighet; NIST:s egen CVSS 3.1-bedömning, som är den primära i NVD, anger 8,2. De två siffrorna beskriver samma defekt enligt olika poängsystem och bör inte jämföras som om den ena ersatte den andra.

• Inte fastställt:något namngivet offer. Varken CISA:s varning, BerriAI:s rådgivning, Wiz:s rapport eller The Hacker News bevakning identifierar en organisation vars MCP-verktyg nåddes genom denna brist, eller rapporterar autentiseringsuppgifter eller data som tagits från en sådan. Den offentliga dokumentationen av utnyttjandet är honeypot-telemetri och ett federalt fastställande, inte ett avslöjat intrång.

• Ej fastställt: att ingen ransomware-grupp använder det. KEV-fältet anger "Unknown", vilket är ett värde som CISA tilldelar, inte ett konstaterande av frånvaro åt endera hållet.

Juniprejudikatet, och den kedja för fjärrkodkörning som detta inte är

Detta är den andra LiteLLM-sårbarheten som når KEV-katalogen 2026, och den tidigare är lätt att förväxla med den. CVE-2026-42271, som lades till den 8 juni 2026 med deadline den 22 juni, är en kommandoinjektion i LiteLLMs teständpunkter för MCP-servern: Wiz beskriver ändpunkter som låter en användare testa en MCP-serverkonfiguration innan den sparas, där fältet command skickas till subprocesskörning utan validering. Angripare skickade in en falsk stdio-serverkonfiguration vars kommando laddade ner och körde en kryptominerare, och returnerade en MCP-handskakning som såg giltig ut så att testet verkade lyckas. CISA:s post för sårbarheten listar CWE-78 och CWE-77 – kommando- och argumentinjektion, inte autentisering.

Det är det felet som kedjas. Wiz säger att CVE-2026-42271 "kan kedjas med en Starlette-bypass för host header-validering (CVE-2026-48710) för att uppnå fullt oautentiserad RCE", och att externa forskare har kopplat ransomwaregruppen Qilin till aktiv exploatering av den kedjan. CVE-2026-48710 lades till i KEV-katalogen i samma batch den 2 september som LiteLLM-bypassen, med samma tidsfrist den 16 september, och CISA:s egen katalognottis för Starlette-felet säger att det skulle kunna kedjas med CVE-2026-42271. Qilin-kopplingen hör till det paret. Det är inte en upptäckt om CVE-2026-59822, och inget i de granskade källorna kopplar ransomwaregruppen till autentiseringsbypassen.

En administrativ detalj skiljer de två LiteLLM-posterna åt: junilistningens obligatoriska åtgärd hänvisar till BOD 22-01, det äldre bindande operativa direktivet, medan septemberlistningen hänvisar till BOD 26-04, "Prioritizing Security Updates Based on Risk". CISA:s varning förklarar inte ändringen, och katalogen kommenterar den inte.

Vad förändrades efter

Åtgärdsvägen är kort. BerriAI:s rådgivning rekommenderar att uppgradera till 1.84.0 eller senare och erbjuder en tillfällig lösning för team som inte kan migrera omedelbart: "inaktivera MCP-rutter eller blockera åtkomst till /mcp/ och relaterade MCP-slutpunkter i din omvända proxy eller API-gateway." Den tillfälliga lösningen är ett trubbigt instrument – den tar bort funktionen i stället för att styra åtkomsten till den – men det är den enda mildrande åtgärd som leverantören anger för distributioner som inte har patchats.

CISA:s text om obligatoriska åtgärder för ingångspunkterna ställer federala myndigheter inför samma avvägning: tillämpa mildrande åtgärder enligt leverantörens anvisningar och i linje med BOD 26-04, "eller sluta använda produkten om mildrande åtgärder inte är tillgängliga", med ansvar för varje myndighet att utvärdera en tillgångs internettexponering. Direktivet är bindande endast för civila federala myndigheter inom den verkställande grenen; CISA uppmuntrar andra organisationer att anta samma riskbaserade prioritering utan att kräva det.

Det är inte offentligt känt om någon utanför en {{1}}honeypot{{/1}} agerade utifrån tidsfristen. Varken CISA eller BerriAI har publicerat siffror på hur många LiteLLM-distributioner som var exponerade, hur många som patchades före 16 september, eller hur många som nåddes via kringgåendet.

Vad som fortfarande är öppet

Tre luckor är värda att påtala i stället för att sopa under mattan. Det finns ingen offentlig incidentrapport som kopplar CVE-2026-59822 till ett specifikt intrång, så KEV-listningen vilar på CISA:s exploateringsbevis och Wiz:s honeypot-observationer snarare än på ett dokumenterat offer. Det finns inget uttalande från leverantören om hur reservvägen kom att skrivas på det sättet, eller hur länge den fanns före 1.84.0 – säkerhetsmeddelandet beskriver defekten och dess åtgärd, inte dess historik. Och tidsfristerna för batchen var inte enhetliga: fem av de sju poster som lades till den 2 september hade en tidsfrist den 5 september, medan posterna för LiteLLM och Starlette hade den 16 september. CISA säger inte varför.

Det som är fastställt är snävare och mer användbart än poängen. Ett enda tecken i ett Authorization-huvud gick på de drabbade versionerna inte att skilja från en giltig nyckel till MCP-slutpunkten – och de versioner som betedde sig så slutade vara aktuella i maj 2026.