CISA voegt LiteLLM's MCP-authenticatiebypass toe aan KEV: elke bearer-token was voldoende

Op 2 september 2026 heeft de U.S. Cybersecurity and Infrastructure Security Agency CVE-2026-59822 toegevoegd aan haar Known Exploited Vulnerabilities-catalogus als de "BerriAI LiteLLM Improper Authentication Vulnerability", een van de zeven kwetsbaarheden in de batch van die dag. De bug zit in LiteLLM's MCP Streamable HTTP-endpoint: wanneer de validatie van een LiteLLM-sleutel mislukte, verving de OAuth2-passthrough-fallback een leeg UserAPIKeyAuth()-object in plaats van het verzoek te weigeren, waardoor elke verzonnen Authorization Bearer-header een geauthenticeerde MCP-sessie opende. Een aanvaller die dat endpoint bereikte, kon alle MCP-tools oplijsten en aanroepen waarmee de gateway was geconfigureerd, en via die tools de diensten erachter bereiken. Alle versies vóór 1.84.0 zijn getroffen, en federale civiele agentschappen kregen tot 16 september de tijd om dit te verhelpen. Dit record — de KEV-vermelding voor LiteLLM's MCP-authenticatiebypass — is één vermelding in het OrcaRouter AI Incident Archive, dat de volledige recordset en de naburige vermeldingen van dit incident bevat.

De reden dat een bug in een proxy meer uitmaakt dan de CVSS-score doet vermoeden, is wat er achter de proxy zit. Het threat-researchteam van Wiz zegt het ronduit: "Een LiteLLM-proxy kan sleutels bevatten voor elke modelprovider waarop hij routeert, waaronder OpenAI, Anthropic, Azure en Gemini. Hij kan ook draaien met cloud-IAM-rechten en via MCP-toolservers verbinding maken met interne services. Een enkele compromittering kan een aanvaller toegang geven tot de inloggegevens en services stroomafwaarts van de proxy, niet alleen tot de proxy zelf." Wiz Research zegt dat het de kwetsbaarheid heeft ontdekt, en de honeypots van Wiz hebben later pogingen vastgelegd om ervan gebruik te maken.

Het mechanisme: een mislukte controle die een geldige sessie opleverde.

Het eigen beveiligingsadvies van BerriAI, GHSA-7488-6r32-c95q, beschrijft het defect in twee zinnen: "De MCP-authhandler ondersteunde OAuth2-passthrough voor upstream MCP-servers, maar het terugvalpad kon een mislukte LiteLLM-sleutelvalidatie vervangen door een leeg UserAPIKeyAuth()-object. Hierdoor konden verzoeken met een vervalste Authorization-header de MCP-tooling bereiken zonder een geldige LiteLLM-sleutel." Het belangrijkste woord is terugval. De code had een vertakking voor implementaties die de OAuth-token van een upstream MCP-server rechtstreeks doorgeven, en wanneer een LiteLLM-sleutel niet kon worden gevalideerd, gaf die vertakking een leeg authenticatieobject terug in plaats van een fout.

Een leeg authenticatieobject is niet hetzelfde als geen authenticatieobject. Stroomafwaartse code zag een succesvol geconstrueerde UserAPIKeyAuth en ging verder, zonder dat er een tenant, een gebruiker of een scope aan verbonden was. Wiz' verslag is botter over de praktische consequentie: "wanneer tokenvalidatie mislukt, retourneert de server in plaats van het verzoek te weigeren een leeg UserAPIKeyAuth()-object zonder beperkingen. Elk Bearer-token (zelfs maar één teken, bijv. x) verleent volledige MCP-toegang."

Wat dat een aanvaller oplevert, is een menu. Het MCP-protocol biedt een lijst van tools, dus een sessie die zich authenticeert, retourneert de namen en schema's van elke tool die de gateway is geconfigureerd om te bereiken — databases, coderepositories, interne API's, in de voorbeelden van Wiz. De leveranciersmededeling zegt het effect onomwonden: "Een aanvaller zou dit kunnen gebruiken om geconfigureerde MCP-tools op te lijsten en aan te roepen en om verbonden services te benaderen die via MCP worden blootgesteld." De toolaanroepen worden vervolgens uitgevoerd met de bevoegdheden die de proxy zelf ten opzichte van die backends heeft, wat het credential-concentratieprobleem is dat Wiz beschrijft.

Een oplossing in mei, een CVE in juli, een federale deadline in september

De datums vallen niet op de manier samen die een lezer zou verwachten, en juist de hiaten zijn interessant. LiteLLM 1.84.0 — de eerste versie die het beveiligingsadvies als gepatcht noemt — werd volgens de release-metadata van de package-index zelf op 14 mei 2026 naar PyPI geüpload. De CVE-identifier werd op 7 juli 2026 bij het CVE Program gereserveerd en het record werd de volgende dag, 8 juli, gepubliceerd; de OSV-vermelding PYSEC-2026-3479 volgde op 23 juli. De KEV-vermelding kwam op 2 september, met een hersteltermijn van 16 september.

Hieruit volgen twee dingen. Ten eerste was de gepatchte build meer dan drie maanden openbaar voordat CISA het lek als misbruikt aanmerkte — dus de organisaties waarvoor de deadline gold, hadden al die tijd een werkende upgrade beschikbaar, en de KEV-toevoeging was niet het moment waarop een fix verscheen. Ten tweede is de versiekloof sindsdien groter geworden: de huidige LiteLLM-release op PyPI is 1.106.5, geüpload op 27 oktober 2026. Een implementatie die nog op iets onder 1.84.0 draait, loopt nu meer dan twintig minor-releases achter, niet slechts één patch achter.

Wat de notering vaststelt, en wat niet

De waarschuwing van CISA voor de batch stelt dat de toevoegingen worden gedaan "op basis van bewijs van actieve exploitatie", en de machinaal leesbare vermelding van de catalogus voor CVE-2026-59822 bevat een datum van toevoeging van 2 september 2026, een uiterste datum van 16 september 2026, een waarde voor bekend gebruik in ransomwarecampagnes van "Onbekend", en twee zwakheden: CWE-287 (onjuiste authenticatie) en CWE-306 (ontbrekende authenticatie voor een kritieke functie).

• Vastgesteld: CISA beoordeelde het lek als actief misbruikt en plaatste het op de federale remediatielijst. Het SSVC-record van NVD, toegeschreven aan een CISA-coördinator en voorzien van een tijdstempel van 2 september 2026, vermeldt exploitatie als "actief", automatiseerbaar als "ja" en technische impact als "gedeeltelijk".

• Vastgesteld:Er werd exploitatie waargenomen in een gecontroleerde omgeving. Wiz publiceerde honeypotverkeer waaruit blijkt dat verzoeken met tokens van één teken een endpoint voor modelenumeratie probeerden: een GET naar /v1/models met "Authorization: Bearer x". The Hacker News, dat op 3 september over de KEV-batch berichtte, beschreef dezelfde activiteit als Wiz die "exploitatiepogingen met CVE-2026-59822 tegen zijn honeypots om endpoints voor modelenumeratie te sonderen" waarnam.

• Vastgesteld: de ernstscores bestaan beide en verschillen per framework. Het advies van BerriAI beoordeelt het lek met CVSS 4.0 op 8,8, hoog, met vertrouwelijkheid hoog, integriteit laag en beschikbaarheid geen; de eigen CVSS 3.1-beoordeling van NIST, die primair is in NVD, stelt het op 8,2. De twee getallen beschrijven hetzelfde defect onder verschillende scoresystemen en moeten niet worden vergeleken alsof het ene het andere heeft vervangen.

• Niet vastgesteld: geen enkele met naam genoemde gedupeerde. Noch de waarschuwing van CISA, noch het advies van BerriAI, noch het verslag van Wiz, noch de berichtgeving van The Hacker News noemt een organisatie waarvan de MCP-tools via deze kwetsbaarheid bereikt werden, of meldt inloggegevens of gegevens die bij een daarvan zijn weggenomen. Het openbare verslag van misbruik bestaat uit honeypot-telemetrie en een federale vaststelling, niet uit een bekendgemaakte inbreuk.

• Niet vastgesteld: dat geen enkele ransomwaregroep het gebruikt. Het KEV-veld vermeldt "Unknown", wat een waarde is die CISA toekent, geen bevinding van afwezigheid in welke richting dan ook.

Het juni-precedent, en de remote-code-executionketen die dit niet is

Dit is de tweede LiteLLM-kwetsbaarheid die in 2026 de KEV-catalogus bereikt, en de eerdere is gemakkelijk met deze te verwarren. CVE-2026-42271, toegevoegd op 8 juni 2026 met een deadline van 22 juni, is een command-injectie in de testendpoints van LiteLLM's MCP-server: Wiz beschrijft endpoints waarmee een gebruiker een MCP-serverconfiguratie kan testen voordat deze wordt opgeslagen, waarbij het command-veld zonder validatie wordt doorgegeven aan subprocessuitvoering. Aanvallers dienden een nep-stdio-serverconfiguratie in waarvan het commando een cryptominer downloadde en uitvoerde, en retourneerden een geldig ogende MCP-handshake zodat de test leek te slagen. CISA's vermelding ervoor noemt CWE-78 en CWE-77 — command- en argumentinjectie, niet authenticatie.

Die kwetsbaarheid is degene die kan worden geketend. Wiz zegt dat CVE-2026-42271 "kan worden geketend met een Starlette-bypass voor hostheadervalidatie (CVE-2026-48710) om volledig ongeauthenticeerde RCE te bereiken", en dat externe onderzoekers de Qilin-ransomwaregroep hebben gekoppeld aan actieve exploitatie van die keten. CVE-2026-48710 werd in dezelfde batch van 2 september als de LiteLLM-bypass aan de KEV-catalogus toegevoegd, met dezelfde deadline van 16 september, en de catalogusnotitie van CISA zelf over de Starlette-kwetsbaarheid zegt dat deze kan worden geketend met CVE-2026-42271. De Qilin-koppeling hoort bij die combinatie. Het is geen bevinding over CVE-2026-59822, en niets in de geraadpleegde bronnen verbindt de ransomwaregroep met de authenticatiebypass.

Eén administratief detail onderscheidt de twee LiteLLM-vermeldingen: de vereiste actie in de juni-vermelding verwijst naar BOD 22-01, de oudere bindende operationele richtlijn, terwijl de september-vermelding verwijst naar BOD 26-04, "Prioriteren van beveiligingsupdates op basis van risico". De waarschuwing van CISA legt de wijziging niet uit, en de catalogus voorziet deze niet van een annotatie.

Wat is er veranderd na

Het remediatietraject is kort. Het advies van BerriAI beveelt een upgrade naar 1.84.0 of later aan, en biedt een workaround voor teams die niet onmiddellijk kunnen overstappen: "schakel MCP-routes uit of blokkeer de toegang tot /mcp/ en gerelateerde MCP-endpoints bij je reverse proxy of API-gateway." Die workaround is een grof middel — het verwijdert de mogelijkheid in plaats van deze te beperken — maar het is de enige mitigatie die de leverancier noemt voor niet-gepatchte implementaties.

CISA's tekst over vereiste acties voor de toegangspunten plaatst federale agentschappen voor dezelfde afweging: pas mitigaties toe volgens de instructies van de leverancier en in overeenstemming met BOD 26-04, "of staak het gebruik van het product als mitigaties niet beschikbaar zijn", waarbij elke instantie verantwoordelijk is voor het beoordelen van de internetblootstelling van een asset. De richtlijn is alleen bindend voor federale civiele agentschappen van de uitvoerende macht; CISA moedigt andere organisaties aan dezelfde risicogebaseerde prioritering over te nemen zonder dit verplicht te stellen.

Of iemand buiten een honeypot iets met de deadline heeft gedaan, is niet openbaar. Noch CISA noch BerriAI heeft cijfers gepubliceerd over hoeveel LiteLLM-implementaties er zijn blootgesteld, hoeveel er vóór 16 september zijn gepatcht, of hoeveel er via de bypass zijn bereikt.

Wat blijft er open

Drie hiaten zijn het vermelden waard in plaats van ze te verdoezelen. Er is geen openbaar incidentrapport dat CVE-2026-59822 aan een specifieke inbraak koppelt, dus de KEV-vermelding berust op het exploitatiebewijs van CISA en de honeypotwaarnemingen van Wiz in plaats van op een gedocumenteerd slachtoffer. Er is geen leveranciersverklaring over hoe het fallbackpad op die manier is geschreven, of hoe lang het al bestond vóór 1.84.0 — de advisory beschrijft het defect en de oplossing ervan, niet de geschiedenis. En de deadlines van de batch waren niet uniform: vijf van de zeven vermeldingen die op 2 september zijn toegevoegd, hadden een deadline van 5 september, terwijl de vermeldingen voor LiteLLM en Starlette 16 september hadden. CISA zegt niet waarom.

Wat vaststaat, is beperkter en nuttiger dan de score. Eén enkel teken in een Authorization-header was op getroffen versies niet te onderscheiden van een geldige sleutel voor het MCP-endpoint — en de versies die zich zo gedroegen, waren in mei 2026 niet meer actueel.