Wiz: bijna 1 op de 10 blootgestelde LiteLLM-gateways accepteert de voorbeeldbeheerderssleutel sk-1234

Op 9 september 2026 publiceerde Wiz Research een onderzoek naar LiteLLM, de opensource-AI-gateway die tussen applicaties en de modelproviders waarvoor zij betalen staat, en meldde: van de 3.074 LiteLLM-implementaties die het op het openbare internet kon bereiken, accepteerden er 294 — 9,6%, bijna een op de tien — sk-1234, de voorbeeldhoofdsleutel die in de eigen installatiedocumentatie van het project wordt afgedrukt, of vereisten ze helemaal geen inloggegevens. Die tekenreeks is geen gewone API-sleutel: in LiteLLM is het zowel de beheerdersreferentie als de schakelaar die authenticatie aanzet, dus wie hem presenteert, kan elke op de gateway opgeslagen modelsleutel van een provider lezen, elke prompt en completion die erdoorheen gaat bekijken en elke toolserver bereiken die via het Model Context Protocol is verbonden. Wiz' medeauteurs, Amitai Cohen en Yaara Shriki, koppelden die toegang aan code-uitvoering op rootniveau en aan de diefstal van de cloud-IAM-referenties van de host. Dit verslag berust op het rapport van Wiz, de eigen beveiligingsadviezen van LiteLLM en de daaropvolgende vermelding in de CISA Known Exploited Vulnerabilities-lijst, en het AI-incidentarchief bevat dit record naast zijn buurrecords, elk met eigen bronnen, ernst en betrouwbaarheidsgraad.

De publicatiedatum is de enige datum die het record bevat, en het is een publicatiedatum. De scan achter de kop werd in februari 2026 uitgevoerd; de twee codefouten die Wiz beschrijft, hadden uiterlijk medio mei al oplossingen gekregen in releases die volgens de eigen administratie van het project uit maart en mei dateren; de CVE-identificaties werden in juli uitgegeven; en de vermelding in de catalogus kwam in september. Bijna alles in het rapport was al verouderd tegen de tijd dat het werd gedrukt, en dat vormt een groot deel van de strekking van het rapport.

De 9,6% is één scan, en Wiz zegt dat zijn eigen follow-up van augustus niet daarmee vergeleken kan worden.

De meting is eenvoudig en Wiz beschrijft zijn methode ronduit: 3.074 vanaf het internet bereikbare LiteLLM-proxy's die in februari 2026 via Shodan zijn gevonden, elk getest op of ze zouden authenticeren met de gedocumenteerde voorbeeldsleutel. Daarvan deden 294 dat. Binnen die groep hadden 191 helemaal geen hoofdsleutel geconfigureerd en zouden ze elke aangeboden tekenreeks hebben geaccepteerd; de rest had de placeholder uit de installatiehandleiding laten staan. Geen van beide faalwijzen vereist een softwarebug. Beide hebben alleen het adres van de gateway nodig en de waarde die in de README van het project zelf staat.

Het is ook een scan van één enkele leverancier. {{1}}Wiz' cijfer is herhaald{{/1}} door het {{2}}Cloud Security Alliance's AI Safety Initiative{{/2}} op 10 september en door {{3}}The Hacker News{{/3}} dezelfde dag, maar beide herhalen het met bronvermelding, en voor dit artikel werd geen onafhankelijke replicatie van het cijfer {{4}}3,074{{/4}} gevonden. {{5}}Wiz voerde in augustus 2026 een tweede scan uit en vond meer dan 85,000 instanties{{/5}}, ongeveer zevenentwintig keer de februaritelling. Het bedrijf zegt dat de meeste daarvan honeypots of testimplementaties lijken te zijn, en dat de twee tellingen niet met elkaar kunnen worden vergeleken. Er is geen actueel blootstellingscijfer, en elk artikel dat er een noemt, citeert februari.

Nog een cijfer in het rapport komt uit Wiz' eigen telemetrie in plaats van uit een scan: het bedrijf zegt dat LiteLLM aanwezig is in ongeveer een derde van de cloudomgevingen die het observeert. Dat is de blik van een leverancier op zijn eigen klantenbestand, en dat moet je met de nodige scepsis bekijken, maar het verklaart wel waarom de onderzoekers een verkeerde configuratie van een gateway als een cloudprobleem behandelden in plaats van als een applicatieprobleem.

De hoofdsleutel is zowel de beheerdersreferentie als de schakelaar die authenticatie inschakelt.

Het ontwerp van LiteLLM geeft één geheim twee taken. De master key authenticeert administratieve verzoeken, en de aanwezigheid ervan is juist wat authenticatie überhaupt mogelijk maakt: zonder master key en zonder JWT- of OAuth2-configuratie draait de proxy open en accepteert elk verzoek. Wiz benaderde de codebase met Claude Code van Anthropic, op zoek naar functies die door de gebruiker beheerde invoer aannemen en doorgeven aan een uitvoeringscontext, en de authenticatiehandler was een van de drie oppervlakken die Wiz signaleerde.

Vóór v1.82.0-stable was het gevolg van die tweede taak erger dan een open proxy. Wiz ontdekte dat wanneer er geen hoofdsleutel was ingesteld, de auth-handler aan elk binnenkomend verzoek de rol PROXY_ADMIN toekende, zodat een niet-geauthenticeerde aanroeper niet alleen werd toegelaten, maar als beheerder werd toegelaten. Pull request #22095, aangehaald in het rapport, wijzigde de standaardrol naar INTERNAL_USER en voegde een beheerderscontrole toe aan de guardrail-endpoints.

Administratieve toegang tot een gateway is geen beperkt voorrecht. De instantie bevat een API-sleutel voor elke provider waarheen zij routeert, en dat maakt haar tot een doelwit voor LLMjacking — het draaien van modelworkloads op de rekening van het slachtoffer. Zij ziet de prompts en completions. Zij maakt uitgaande verbindingen naar MCP-toolservers, die bij een interne implementatie waarschijnlijk issuetrackers, chat, databases en deployment-pipelines omvatten.

Wiz toonde ook een pad aan van die beheerderspositie naar de cloudidentiteit van de host. LiteLLM laat een beheerder een pass-throughroute naar elke doel-URL registreren, en het doel wordt niet gecontroleerd tegen privéadresbereiken, localhost of het cloudmetadataadres. Een route naar de instance-metadataservice richten levert de IAM-referenties op waaronder de workload draait. De metadataservice overschakelen naar IMDSv2, dat normaliter deze klasse van request forgery verslaat door een afzonderlijk verkregen sessietoken te eisen, helpt niet: LiteLLM stuurt elke header met het voorvoegsel x-pass- naar het doel, waarbij het voorvoegsel wordt verwijderd, zodat de tokenheader kan worden doorgesluisd. Wiz zegt dat de functie redelijkerwijs werkt zoals bedoeld binnen een dreigingsmodel dat beheerders vertrouwt, en dat er daarom geen CVE en geen oplossing is.

Die laatste alinea is een demonstratie, geen waargenomen aanval. The Hacker News, dat op 10 september over het onderzoek berichtte, stelt dat geen enkele bron meldt dat iemand dit tegen een echte deployment heeft gedaan, en dat er eerst admin-toegang nodig is. De framing van Wiz is dezelfde: de pass-through is een ontwerpeigenschap die pas een kwetsbaarheid wordt wanneer de beheerdersreferentie een tekenreeks uit de documentatie is.

8.8 en 2.1 beoordelen dezelfde keten vanuit een verschillend startpunt

Twee CVE's bevatten de technische bevindingen, en hun gepubliceerde scores kunnen nauwelijks verder uiteenliggen.

CVE-2026-59822 is de MCP-authenticatiebypass, en het beveiligingsadvies van LiteLLM beoordeelt deze als Hoog, 8.8 onder CVSS 4.0, zonder vereiste privileges, zonder gebruikersinteractie en zonder aanvalsvereisten. Het MCP-eindpunt heeft zijn eigen authenticatiehandler, gebouwd om zowel een LiteLLM-sleutel als een OAuth2-token bestemd voor een upstream-toolserver te accepteren. Wanneer een token niet door de validatie van LiteLLM kwam, ving de handler de 401 op en verving deze door een leeg authenticatieobject in plaats van het verzoek af te wijzen. Elk Bearer-token leverde daardoor een geldige MCP-sessie op, inclusief één enkel teken: Wiz' proof of concept stuurt een bearer-token van één letter en krijgt een sessie-identifier terug. De fout is verholpen in 1.84.0.

CVE-2026-59821 is de guardrail-fout, en de advisory van hetzelfde project beoordeelt deze als Low, 2.1, waarbij hoge privileges vereist zijn en aanvalsvereisten aanwezig zijn. De functie voor guardrails met aangepaste code laat een beheerder Python indienen dat de server compileert en uitvoert. Het test-endpoint van de web-ui valideerde de code tegen een lijst met verboden patronen en verwijderde de builtins voordat deze werd uitgevoerd; de productie-create- en update-endpoints deden geen van beide. Python vult builtins opnieuw aan wanneer ze ontbreken, waardoor ingediende code de standaardbibliotheek bereikte. Wiz' proof of concept registreert een guardrail die tijdens de registratie een shellcommando uitvoert — vóór enig modelverzoek — en de uitvoer van het commando retourneert als de blokkeerreden, die in hun test als root terugkwam. De fout is verholpen in v1.82.0-stable.

De twee beschrijvingen zijn verenigbaar, en de verzoenende zin staat in het advies zelf: LiteLLM merkt op dat in implementaties zonder geconfigureerde master key aanroepers als proxybeheerders konden worden behandeld, waardoor de guardrail-endpoints binnen bereik kwamen. Een 2.1 gaat uit van een bevoorrechte gebruiker. De keten van Wiz is wat er gebeurt wanneer de standaardsleutel elke aanroeper bevoorrecht maakt. Geen van beide scores heeft ongelijk over zijn eigen uitgangspositie; ze zijn het oneens over hoe vaak die positie gratis is.

Eén voorbehoud kleeft aan de bewering van Wiz dat een aanvaller die na 1.82.0 over de standaardsleutel beschikt, alleen code binnen een sandbox kon uitvoeren. The Hacker News wijst op een afzonderlijk advies uit mei 2026, CVE-2026-40217, dat beschrijft hoe die sandbox kan worden ontsnapt met bytecode-technieken in versies vanaf 1.81.8 tot maar niet inclusief 1.83.10, binnen een proxyproces dat volgens het advies als root draait in de standaard container-image. Om dat endpoint te bereiken is een beheerdersreferentie voor de proxy nodig, en dat is precies wat de mastersleutel is.

De 8,8 is evenmin universeel. De onderzoeksnotitie van de Cloud Security Alliance merkt op dat het beveiligingsadvies van GitLab voor dezelfde kwetsbaarheid een basisscore van 8,2 vermeldt en weigert een uitspraak te doen tussen de twee methodologieën; er wordt alleen opgemerkt dat beide in het hoge bereik liggen. De ernstclassificatie 'hoog' van het record hangt niet af van welk getal wordt gebruikt.

Eén CVE werd in het wild misbruikt; bij de blootstelling van de standaardsleutel is geen slachtoffer bij naam bekend.

CISA heeft CVE-2026-59822 op 2 september 2026 toegevoegd aan de Known Exploited Vulnerabilities-catalogus en heeft voor federale civiele overheidsinstanties een hersteltermijn van 16 september 2026 vastgesteld; de catalogusvermelding bevat CWE-287 en CWE-306, onjuiste authenticatie en ontbrekende authenticatie. Een notitie van de Cloud Security Alliance meldt dat branchevolgers het hebben beschreven als de eerste MCP-specifieke kwetsbaarheid op die lijst. Wiz heeft het misbruik gepubliceerd dat het heeft waargenomen: vanaf 7 juli 2026 registreerden haar honeypots verzoeken met bearer-tokens van één teken die endpoints voor het opvragen van modellen aftastten, en Wiz beschrijft geen ander gebruik van de kwetsbaarheid.

Voor de standaardsleutel bestaat niets vergelijkbaars. Er wordt geen slachtoffer genoemd, geen gateway aangewezen als overgenomen via sk-1234, en geen telemetrie toont dat de 294 hosts worden gebruikt. Het archiefitem registreert geen werkelijke schade, wat iets zegt over bewijs en niet over het mechanisme: de blootstelling werd gemeten, niet waargenomen dat er gebruik van werd gemaakt.

Twee andere zaken worden vaak samen met deze vermeld en zijn niet hetzelfde. CVE-2026-42271, uitvoering van opdrachten via twee MCP-testendpoints, is de LiteLLM-kwetsbaarheid die aanvallers daadwerkelijk hebben gebruikt om code uit te voeren; de honeypots van Wiz registreerden dat er een cryptominer werd geïnstalleerd. De zaak van augustus 2026 die Microsoft publiceerde, waarbij een indringer de omgevingsvariabelen van een gateway-container las, de hoofdsleutel, de providersleutels en een databaseverbindingsreeks achterhaalde en vervolgens records kopieerde uit LiteLLM's model- en virtuele-sleuteltabellen, illustreert wat een gecompromitteerde gateway waard is, niet een nieuwe manier om binnen te komen; The Hacker News meldt dat Microsoft het toegangspunt beoordeelt als de CVE-2026-42271-keten.

Het standpunt van de beheerders is dat een ontbrekende hoofdsleutel een installatiefout is, geen kwetsbaarheid.

Het beveiligingsbeleid van LiteLLM is expliciet. Het noemt onder de buiten scope vallende kwesties "aanvallen die een verkeerde configuratie bij de installatie vereisen (bijv. het niet instellen van een master_key in de proxyconfiguratie)", en stelt dat deze expliciet buiten scope vallen en niet als kwetsbaar worden beschouwd. Wiz komt vanuit de andere richting tot een verenigbare conclusie wanneer het het pass-throughgedrag "mogelijk werkend zoals bedoeld" noemt.

Dat standpunt is in het openbaar op de proef gesteld. Op 15 augustus 2026 diende een onderzoeker GitHub-issue #37054 in, met de melding dat een proxy waarbij LITELLM_MASTER_KEY niet is ingesteld, elke willekeurige sleutelwaarde authenticeert en dat het meegeleverde docker-compose-bestand er geen instelt. Het issue werd 30 minuten later gesloten, en de enige reactie erop is afkomstig van hetzelfde account: die verwijst naar de instructie in het beveiligingsbeleid dat meldingen via privékwetsbaarheidsmeldingen lopen in plaats van via openbare issues, biedt excuses aan voor het openbaar indienen, en zegt dat het volledige rapport in plaats daarvan via het advisorytraject werd ingediend. Er verschijnt geen reactie van een maintainer in de thread, dus de registratie toont dat de melder de openbare melding introk, niet dat het project erop reageerde. Niets openbaars legt vast wat er met de privé-inzending is gebeurd.

Er is voor dit artikel geen publieke verklaring van BerriAI gevonden waarin dat standpunt over het septemberrapport wordt verdedigd of herzien. De zichtbare reactie van het bedrijf staat in de release notes en de configuratiebestanden ervan, niet in proza.

De handhaving kwam op 3 oktober, vierentwintig dagen na het rapport.

De twee codefouten waren al lang vóór het rapport verholpen. De openbaarmakingstijdlijn van Wiz vermeldt de uitvoering van guardrail-code die op 18 februari 2026 werd gemeld en op 25 februari in v1.82.0 werd verholpen, de MCP-bypass die op 25 april in v1.84.0 werd verholpen, exploitatie die op 7 juli werd waargenomen, de CVE-identificatoren die op 8 juli werden gepubliceerd en de vermelding in de catalogus op 2 september. De release-artefacten dragen latere datums dan de fixes: de pakketindex toont v1.82.0 op 1 maart 2026 en v1.84.0 op 14 mei, wat aangeeft wanneer elke fix installeerbaar werd in plaats van wanneer die landde. Twee first-party releasegegevens dateren dezelfde fixes later dan die tijdlijn doet. De v1.82.0-stable release op GitHub draagt 11 maart 2026 en het 1.82.0-pakket op PyPI 1 maart; v1.84.0 is op beide gedateerd op 14 mei 2026. Niets dat gepubliceerd is verklaart de kloof, en dat doet er niet toe voor het betoog, aangezien elk van die datums maanden vóór het septemberrapport valt. De twee GitHub-advisories voegen nog een derde datum toe: ze werden gepubliceerd op 30 juni 2026, drie weken vóór de CVE-identificatoren waarvan Wiz zegt dat ze op 8 juli zijn uitgegeven.

Wat geen van die releases verholpen had, was de standaardwaarde. Wiz meldde dat de hoofdsleutel op 9 september nog steeds op sk-1234 stond bij het installeren van LiteLLM via Docker Compose of pip install, en The Hacker News bevestigde dat de installatiehandleiding die dag nog steeds die waarde gebruikte. De wijziging kwam met v1.104.0, op 3 oktober 2026 geüpload naar de Python Package Index, waarvan de releaseopmerkingen het als een breaking change vermelden: de proxy weigert nu te starten met een niet-ingestelde, lege of publiek bekende hoofdsleutel, noemt de bron van de ongeldige waarde in de opstartfout en print een opdracht die een veilige sleutel genereert. Een bijbehorende vermelding registreert een wijziging om niet langer een publiek bekende zwakke waarde voor de hoofdsleutel te adverteren in meegeleverde configuraties en voorbeelden, en het docker-compose-bestand op de hoofdtak van het project stelt helemaal geen sleutel meer in.

Dat is de volgorde die het waard is om te behouden. De code is in het voorjaar gepatcht. De waarde waardoor die patches ontoereikend waren, bleef tot in oktober in de installatie-instructies staan, en pas toen begon de software die te weigeren. Niets aan een van beide oplossingen vereiste dat de andere wachtte.

Wat niet is veranderd, is de doorgifte-route naar de instance-metadataservice. Die heeft nog steeds geen CVE en geen oplossing, omdat het project beheerders als vertrouwd beschouwt. Wiz' remediatielijst is daarom grotendeels werk voor de operator: een sterke en unieke mastersleutel, een controle van geregistreerde guardrails gevolgd door een herstart van het proces om code in het geheugen te wissen, een audit van doorgifte-endpoints met beperkte container-egress, en IAM-rollen met minimale rechten. Geen van die vier krijg je alleen door te upgraden.

Wat het dossier niet vaststelt

• Er is geen onafhankelijke replicatie van de scan van 3.074 hosts gevonden. De 9,6% is de meting van Wiz, en elke andere vermelding ervan herhaalt het cijfer attributief.

• Er is geen actueel blootstellingscijfer. Het vervolgonderzoek van augustus vond meer dan 85.000 instanties; volgens Wiz zijn dit grotendeels honeypots of testimplementaties, en ze zijn niet te vergelijken met de telling van februari.

• Geen slachtoffer. Niets in het verslag noemt een gateway, een operator of een cloudaccount die via de standaardsleutel is gecompromitteerd, en de exploitatie die Wiz documenteert betreft de MCP-bypass en niet sk-1234.

• Geen bewijs dat de 294 hosts werden gebruikt. De scan testte of ze zouden authenticeren, wat een zwakkere bewering is dan aantonen dat iemand dat daadwerkelijk deed.

• Geen eenduidig vastgestelde ernst voor de tekortkoming in de guardrail. Wiz en de beheerders beschrijven hetzelfde gedrag en beoordelen het heel verschillend, en dat verschil draait om de privileges waarvan elk van hen aanneemt dat de aanvaller die al bezit.

Wiz is ook een leverancier van cloudbeveiliging die detectie verkoopt voor deze categorie blootstelling, en het rapport sluit af met een sectie over hoe zijn eigen producten LiteLLM-implementaties, kwetsbare versies en schaduwinstanties identificeren. Dat is context voor het lezen van de sectie over herstelmaatregelen, niet een reden om een meting af te doen waarvan de technische details door de eigen adviezen van de maintainers worden bevestigd.

Het deel van het record dat verder reikt dan LiteLLM is de ruimte tussen twee datums. De kwetsbaarheid werd in het voorjaar gedicht. De standaardwaarde waardoor de kwetsbaarheid voor een buitenstaander van belang was, stond in september nog steeds in de installatie-instructies, en de software begon die pas in oktober te weigeren. De operators die de string hebben gewijzigd, hoefden op niets daarvan te wachten.