Bijna een op de tien van de internetgerichte LiteLLM-servers die Wiz Research in februari heeft gescand, accepteerde dit sk-1234de voorbeeldbeheerderssleutel in de eigen installatiehandleiding van LiteLLM.
LiteLLM is een open-source AI-gateway, de software die een bedrijf tussen zijn applicaties en de modelaanbieders plaatst waarvoor het betaalt. Die sleutel is de beheerdersreferentie van de gateway.
Iedereen die deze in zijn bezit heeft, kan de API-sleutel van elke modelaanbieder lezen die op de server is opgeslagen. In de tests van Wiz bereikte het ook de cloud-IAM-inloggegevens van de machine waarop de gateway draait.
Voor het veranderen van de sleutel is geen upgrade nodig, en het sluit elk pad in het rapport van Wiz dat afhankelijk is van het vasthouden ervan.
Waar het nummer vandaan komt
Wiz heeft één scan uitgevoerd. In februari werden 3.074 LiteLLM-gateways gevonden op Shodan, waarvan 294 de sleutel accepteerden.
Bij 191 van die 294 was er helemaal geen sleutel ingesteld, dus ze zouden alles hebben geaccepteerd. Bij de rest bleef de waarde van de installatiegids behouden.
Een tweede scan in augustus vond meer dan 85.000 gevallen, maar Wiz zegt dat de meeste ervan honeypots of testsystemen lijken te zijn, dus de twee tellingen kunnen niet worden vergeleken. Er is geen actueel cijfer.
Vanaf 9 september gebruikt de installatiehandleiding van LiteLLM nog steeds sk-1234, boven een opmerking waarin operators worden gevraagd deze te vervangen door een lange willekeurige waarde voordat deze daadwerkelijk wordt gebruikt.
Waarom één sleutel zo belangrijk is
De hoofdsleutel doet twee taken tegelijk, en dat maakt een standaardwaarde serieus. Het zijn de beheerdersreferenties en de schakelaar die authenticatie mogelijk maken.
Vóór versie 1.82.0-stable verleende een gateway die startte zonder een hoofdsleutel elk binnenkomend verzoek volledige beheerdersrechten.
Een beheerder op een van deze servers heeft veel bereik. De gateway kan een API-sleutel bevatten voor elke provider waarnaar hij routert, elke prompt en elk antwoord zien passeren, en verbinding maken met interne tools via het Model Context Protocol (MCP).
Het werkt meestal ook met de cloudrechten van de werklast waarin het wordt ingezet. Alleen al met gestolen providersleutels kan een aanvaller modelwerklasten uitvoeren op de rekening van het slachtoffer, een misbruik dat bekend staat als LLMjacking.
Hoe de sleutel het cloudaccount bereikt
Met LiteLLM kan een beheerder een pass-through-eindpunt maken, een route die verzoeken doorstuurt naar elke URL die de beheerder kiest.
De doel-URL wordt niet gecontroleerd aan de hand van privé-adresbereiken, localhost- of cloud-metagegevensadressen. Een beheerder kan daarom een route naar de instance-metadataservice wijzen en de IAM-referenties teruglezen die deze retourneert.
Overstappen naar IMDSv2 stopt dit niet. LiteLLM documenteert dat elke header die met een x-pass-prefix wordt verzonden, wordt doorgegeven aan het doel zonder het voorvoegsel, en Wiz heeft dat gebruikt om de headers te verzenden die IMDSv2 vereist.
Geen enkele bron meldt dat iemand dit doet tegen een echte inzet. Het is een demonstratie en er is eerst beheerderstoegang voor nodig.
Wiz zegt dat de functie aantoonbaar werkt zoals bedoeld, omdat het dreigingsmodel van LiteLLM beheerders als vertrouwd behandelt. Het heeft geen CVE en geen oplossing.
Het project zegt vrijwel hetzelfde over de manier waarop het binnenkomt. Het gepubliceerde beveiligingsbeleid vermeldt aanvallen waarbij een installatiefout nodig is, zoals het niet instellen van een hoofdsleutel, als “expliciet niet binnen bereik” en niet behandeld als kwetsbaarheden.
De vangrailfout en een betwiste ernst
De enige fout in de uitvoering van de code in het rapport van Wiz is CVE-2026-59821en de onderzoekers en de beheerders beschrijven het heel anders.
Wiz noemt dit de uitvoering van post-authenticatiecode op rootniveau en toont een test die uid=0(root) retourneert in de gatewaycontainer. Het advies van LiteLLM voor dezelfde CVE beoordeelt het als Laag (2,1 op de CVSS-schaal) en beschrijft het als een fout waarvoor een account met hoge bevoegdheden vereist is.
Beide beschrijven hetzelfde gedrag. Vóór 1.82.0-stable sloegen de eindpunten die aangepaste codevangrails maakten en bijwerkten de sandbox- en patrooncontroles van het toegepaste testeindpunt over, zodat iedereen die ze kon bereiken Python kon indienen die in de container draaide.
Het advies voegt eraan toe dat een implementatie zonder hoofdsleutel bellers behandelde als proxybeheerders, waardoor deze eindpunten binnen bereik kwamen.
In het rapport van Wiz staat dat een aanvaller met de standaardsleutel na versie 1.82.0 alleen code binnen een sandbox kon uitvoeren. De eigen plaat van LiteLLM ondersteunt dat niet voor elke release.
Een afzonderlijk advies gepubliceerd in mei, CVE-2026-40217zegt dat de sandbox kan worden ontsnapt met behulp van bytecode-technieken door code uit te voeren in het proxyproces, dat volgens de adviezen als root wordt uitgevoerd in de standaard Docker-image.
Het omvat versies van 1.81.8 tot, maar niet inclusief, 1.83.10, en om het eindpunt te bereiken is een proxy-admin-referentie nodig. De hoofdsleutel is die identificatie.
Beide tekortkomingen die Wiz rapporteerde, waren maanden vóór het rapport van 9 september, in februari en april, verholpen en hun CVE’s werden in juli gepubliceerd.
Afzonderlijk: de tekortkomingen van LiteLLM worden al uitgebuit
Dit zijn oudere problemen en geen van deze is de hierboven beschreven route naar cloudreferenties. Ze worden hier vermeld omdat ze betrekking hebben op hetzelfde product en er gemakkelijk mee te verwarren zijn.
CISA heeft op 2 september een LiteLLM-fout toegevoegd aan de Known Exploited Vulnerabilities-catalogus. CVE-2026-59822 (CVSS-score: 8,8), ook gevonden door Wiz, laat een niet-geverifieerde aanvaller een geldige MCP-sessie openen met behulp van elk Bearer-token, inclusief een token van één teken lang. Federale civiele instanties hebben tot 16 september de tijd om dit probleem aan te pakken.
Wiz zag het vanaf 7 juli tegen zijn eigen honeypots worden gebruikt in verzoeken die tokens van één teken bevatten om eindpunten van modellijsten te onderzoeken. Wiz beschreef er geen ander gebruik van.
Deze fout bereikt de bovenstaande code-uitvoering of referentiepaden niet. Wiz stelt dat het “alleen MCP-servertoegang toestaat”. Wat het kan bereiken, hangt af van de toolservers waarmee een organisatie verbinding heeft gemaakt.
De LiteLLM-fout die aanvallers hebben gebruikt om code uit te voeren, is een andere. CVE-2026-42271 (CVSS-score: 8,7) liet elke geverifieerde gebruiker opdrachten uitvoeren op de host via twee MCP-testeindpunten, en Horizon3.ai meldde in juni dat het gekoppeld zou kunnen worden aan een Starlette host-header-fout, CVE-2026-48710, om hetzelfde te doen zonder helemaal geen inloggegevens.
Wiz’s honeypots registreerden dat deze fout werd gebruikt om een cryptocurrency-mijnwerker te installeren.
Microsoft publiceerde in augustus een geval waarin aanvallers opdrachten uitvoerden binnen een LiteLLM-gatewayproces, de containeromgeving lazen voor de hoofdsleutel, de providersleutels en de databaseverbindingsreeks, en die reeks vervolgens gebruikten om toegang te krijgen tot de onderliggende PostgreSQL-database en records te kopiëren van LiteLLM’s model- en virtuele-sleuteltabellen.
Microsoft beoordeelt met groot vertrouwen dat de aanvallers toegang hebben verkregen via de blootgestelde gateway en zegt dat het toegangspunt overeenkomt met de CVE-2026-42271- en CVE-2026-48710-keten. “Behandel AI-gateways als Tier-0-geheimen”, aldus het bedrijf.
Wat nu te doen
Een upgrade naar 1.84.0 of hoger verhelpt elke fout in de tabel. De versiebereiken zijn zoals vermeld in de adviezen.
| Gebrek | Wat het toestaat | Betrokken versies | Vast in |
|---|---|---|---|
|
CVE-2026-59822, MCP-authenticatie omzeilen |
Een geverifieerde MCP-sessie vanaf elk Bearer-token, waarmee de MCP-tools worden bereikt die de instantie heeft geconfigureerd |
Vóór 1.84.0 | 1.84.0 |
|
CVE-2026-42271, Uitvoering van MCP-testeindpuntopdracht |
Elke geverifieerde gebruiker voert opdrachten uit op de host |
1.74.2 tot en met 1.83.7, maar niet inclusief |
1.83.7 |
|
CVE-2026-59821, aangepaste code vangrailcontrole-bypass |
Code-uitvoering in de gatewaycontainer |
Vóór 1.82.0 stabiel | 1.82.0 stabiel |
|
CVE-2026-40217, ontsnapping uit de zandbak van de vangrail |
Code-uitvoering als root in de standaardcontainerimage |
1.81.8 tot en met 1.83.10, maar niet inclusief |
1.83.10, hoewel de adviestekst 1.83.11 zegt |
- Wijzig de hoofdsleutel van
sk-1234naar een lange willekeurige waarde. Dit heeft geen upgrade nodig. Controleer eerst of er een aparte salt-sleutel is ingesteld, omdat de rotatieprocedure anders is en het gebruik van de verkeerde opgeslagen inloggegevens onleesbaar kan maken. - Upgrade naar 1.84.0 of hoger. Die release bevindt zich boven de vaste versie van elke fout in de tabel.
- Als u nog niet kunt upgradenblok
/mcp/en de twee MCP-testeindpunten,POST /mcp-rest/test/connectionEnPOST /mcp-rest/test/tools/listop uw reverse proxy of API-gateway. - Blok ook
POST /guardrails/test_custom_codeen beperkenPOST /guardrailsEnPUT /guardrails/{guardrail_id}aan beheerders. Dit zijn de oplossingen in de eigen adviezen van LiteLLM. - Bekijk de pass-through-eindpunten op de gateway beperkt u de uitgaande netwerktoegang van de container en geeft u de werklast de smalste cloud-IAM-rol waarmee deze kan werken.
- Als u denkt dat een aanvaller mogelijk toegang heeft gehadControleer de vangraillijst op vermeldingen die u niet hebt gemaakt en start het proces opnieuw om de code in het geheugen te wissen. Draai vervolgens de providersleutels, de hoofdsleutel en de databasereferenties. Bij het upgraden wordt noch de vangrail verwijderd die een aanvaller heeft geregistreerd, noch een SSH-sleutel die hij of zij heeft toegevoegd.
Er is geen patch voor de pass-through-route naar instance-metagegevens, omdat LiteLLM dit niet als een fout beschouwt. Uitgaande netwerklimieten en beperkte IAM-rollen zijn de enige beschikbare controles.
Geen enkele bron beschrijft hoe u kunt controleren of MCP- of pass-through-routes zijn ingeschakeld op een gateway die u hebt geërfd. De jachtquery’s van Microsoft vinden exploitatie, geen configuratie.
