Wiz Research ontdekte dat bijna 1 op de 10 publiek bereikbare LiteLLM-gateways in één scan de voorbeeldwaarde sk-1234 uit de installatiehandleiding accepteerden. Die sleutel is geen decoratie: het is de beheerdersreferentie van de gateway. Daardoor kan iemand die de key bezit (of systemen die niets instellen) niet alleen beheren, maar ook waardevolle geheimen uitlezen die door LiteLLM worden afgewogen tussen applicaties en modelproviders.
In dit artikel zetten we op een rij wat er precies misgaat, waarom één default-waarde zo’n groot verschil maakt, welke kwetsbaarheden in dezelfde onderzoeksset spelen en vooral: wat je nu kunt doen om je exposure te verkleinen.
Waarom de LiteLLM standaard admin key zo riskant is
LiteLLM is open-source AI gateway software. In de praktijk staat het tussen je applicaties en de modelproviders die je betaalt. De gateway bewaart daarbij provider API keys en verwerkt prompts en antwoorden. De master key (admin key) fungeert als sleutel tot het beheer van de gateway.
Als een gateway opstart met de default-waarde, wordt die in de onderzoeksresultaten een toegangspunt. Niet alleen om configuratie aan te passen, maar ook om informatie te bekijken die de gateway verwerkt of nodig heeft. Het onderzoek beschrijft daarnaast situaties waarin de master key niet eens was ingesteld: dan accepteert de gateway zelfs elke waarde.
Wat Wiz vond bij publieke gateways
Wiz deed een scan in februari en identificeerde 3.074 LiteLLM-gateways die op dat moment via Shodan te benaderen waren. Daarvan accepteerden 294 de default admin key. In 191 van die 294 gevallen was er bovendien helemaal geen key gezet, waardoor de systemen in feite geen echte controle deden op beheerstoegang.
Een latere scan in augustus telde vervolgens meer dan 85.000 instanties. Wiz waarschuwt echter dat het grootste deel vermoedelijk honeypots of testomgevingen zijn, waardoor de aantallen niet goed te vergelijken zijn. Het onderzoek geeft dus vooral een duidelijke aanwijzing voor februari: de defaultwaarde was aantoonbaar in het wild aanwezig.
De sleutel opent meer dan alleen beheer
Het onderzoek legt uit dat de master key meerdere rollen tegelijk vervult. Enerzijds is het de beheerderscredential; anderzijds bepaalt de aanwezigheid/waarde ervan mede hoe authenticatie werkt. Daardoor kan een aanvaller met toegang tot de admin-rol bijvoorbeeld:
- provider API keys uitlezen die op de gateway staan
- prompt- en responsstromen observeren die via de gateway lopen
- verbindingen leggen met interne mogelijkheden via Model Context Protocol (MCP)
Daarnaast wijst het onderzoek op een veel breder financieel risico: als provider-keys worden misbruikt, kan een aanvaller modelverzoeken draaien op jouw rekening. Dit fenomeen wordt in de rapportage ook wel aangeduid als LLMjacking.
Hoe de toegang zelfs cloud IAM kan raken
Een belangrijk deel van de impact komt voort uit een feature waarmee een beheerder zogenoemde pass-through endpoints kan aanmaken: routes die verzoeken doorsturen naar een URL die de beheerder kiest. In de onderzoekscontext werd die URL niet afgetoetst op private adresbereiken, localhost of cloud metadata-adressen.
Op papier betekent dat: iemand met beheertoegang kan een route richten op een endpoint dat cloud IAM-metadata teruggeeft. Het resultaat kan zijn dat de aanvaller cloud IAM-credentials ziet die horen bij de machine of workload waar de gateway draait.
Belangrijk: het onderzoek stelt dat het hierbij om demonstratie gaat die administratieve toegang vereist. Er zijn in de aangehaalde bron geen meldingen van iemand die dit tegen een echte productieomgeving heeft uitgevoerd. Toch is de aanvalsbeschrijving vooral bedoeld om de ernst van een default admin key te onderstrepen: als beheer veilig gesteld moet worden, dan is de standaardwaarde precies het punt waar je bescherming faalt.
Guardrails, code-uitvoering en de discussie over ernst
Wiz noemt in het rapport één code execution-flaw: CVE-2026-59821. Zowel onderzoekers als maintainer behandelen de ernst verschillend. De essentie van wat er misgaat, is in de bron als volgt beschreven:
- voor een bepaalde versie schakelden endpoints voor aangepaste code guardrails safeguards en patroonchecks over
- daardoor kon iemand met toegang tot die endpoints Python-code laten uitvoeren in een containercontext
De advisory van het project waardeert dit als Low (2.1 op de CVSS-schaal) en koppelt de impact aan het vereiste hoge privilege. Wiz typeert het als post-authentication code execution op root-niveau en laat in tests zien dat de containercontext root-rechten kan hebben.
Verder beschrijft de bron dat eerder gepubliceerde adviezen ook gaan over sandbox-escape technieken via bytecode. Ook daar geldt: de route naar exploitatie hangt samen met toegang via beheerders-/proxy-admin credentials, waarbij de master key de kernrol speelt.
Concreet: zelfs als de exacte interpretatie van “hoe erg” wordt betwist, is de praktische boodschap dezelfde. De standaard admin key verhoogt het risico dat je überhaupt in het bereik komt van functionaliteit die tot code-uitvoering kan leiden.
Andere LiteLLM-kwetsbaarheden die makkelijk worden verward
Naast de besproken code execution-route noemt de bron nog meerdere LiteLLM-issues die in dezelfde omgeving spelen, maar die niet allemaal hetzelfde einddoel hebben. Omdat het product verwarring kan oproepen, is het nuttig om onderscheid te maken tussen de paden:
- CVE-2026-59822: volgens de bron toegevoegd aan het Known Exploited Vulnerabilities-catalogus. Wiz stelt dat een aanvaller zonder authenticatie een MCP-sessie kan openen met een (zeer) korte Bearer token. Dit richt zich op MCP servertoegang; wat dat oplevert hangt af van welke toolservers je hebt aangesloten.
- CVE-2026-42271 (en een ketting met CVE-2026-48710): in de bron genoemd als route die command execution in de host mogelijk kan maken, inclusief gevallen die door onderzoekers zijn gekoppeld aan het neerzetten van malware zoals een cryptocurrency miner.
De bron noemt daarnaast een Microsoft-casus waarin aanvallers via een geëxposeerde gateway konden command execution uitvoeren, omgevingsvariabelen konden lezen (waaronder master key, provider keys en database connection string) en daarna konden inloggen op een onderliggende PostgreSQL-database. Microsoft adviseert daarbij om AI gateways als Tier-0 secrets stores te behandelen.
Wat je nu kunt doen: stappen om de LiteLLM blootstelling te beperken
De bron geeft duidelijke maatregelen. We zetten ze hieronder praktisch op volgorde van effectiviteit.
1) Vervang de LiteLLM standaard admin key
De meest directe actie is het vervangen van sk-1234 door een lang willekeurig alternatief. Volgens de bron is dat ook mogelijk zonder software-upgrade. Let daarbij wél op of je een aparte salt key gebruikt: de rotatieprocedure kan verschillen. Gebruik je de verkeerde sleutel, dan kunnen opgeslagen credentials onleesbaar worden.
2) Upgrade naar een versie die alle besproken fixes dekt
Wiz stelt dat upgrade naar 1.84.0 of later alle kwetsbaarheden uit de bijbehorende tabel behandelt (binnen de versiegrenzen die in de adviezen staan). Als je het in één keer goed wilt doen, is dit de meest robuuste weg.
3) Blokkeer specifieke endpoints als je niet meteen kunt upgraden
Als upgrade nog niet mogelijk is, adviseert de bron mitigaties op het niveau van je reverse proxy of API gateway. Concreet gaat het om het blokkeren van:
- /mcp/ en de MCP test endpoints: POST /mcp-rest/test/connection en POST /mcp-rest/test/tools/list
- POST /guardrails/test_custom_code
- beperk verder POST /guardrails en PUT /guardrails/{guardrail_id} tot administratieve gebruikers
4) Controleer pass-through routes en beperk uitgaand netwerk
Omdat de pass-through-route naar cloud metadata niet als “fixbare fout” wordt behandeld in de bron, is het belangrijkste besturingselement hier: beperk outbound netwerktoegang en geef de workload de smalst mogelijke cloud IAM-rol. Zo wordt het effect kleiner als er tóch misbruik plaatsvindt.
Daarnaast raadt de bron aan om de pass-through endpoints die je eventueel hebt ingericht te herzien en alleen wat nodig is open te zetten.
5) Neem aan dat een aanvaller mogelijk al binnen was
Als je vermoedt dat iemand toegang heeft gehad (bijvoorbeeld door openbare exposure met de default key), dan is “resetten” cruciaal. De bron noemt onder andere:
- controleer guardrails op entries die je niet zelf hebt aangemaakt
- start het proces opnieuw om code die in geheugen is geladen te wissen
- roteer provider keys, de master key en database-credentials
Let op: upgraden alleen verwijdert niet automatisch guardrails of extra toegangsgegevens die een aanvaller heeft toegevoegd.
Waarom dit past in de bredere beveiligingslijn: AI gateways zijn “high-value”
Deze incidentbeschrijving sluit aan bij een algemene trend: AI-systemen worden aantrekkelijker doelwit naarmate ze meer rechten krijgen, meer secrets opslaan en breder worden ingezet. De bron benadrukt dat je AI gateways niet moet zien als een “gewone” middleware, maar als een kerncomponent met toegang tot API keys en mogelijk zelfs cloud permissions.
Als je wilt doorredeneren naar andere dreigingen rondom AI-interfaces, dan kan ook een overzicht van AI-gerelateerde aanvalstechnieken waardevol zijn. Bijvoorbeeld het onderwerp AI distillation-aanvallen uitgelegd geeft context over hoe aanvallen zich richten op modelstromen en afgeleide kennis. Hoewel het om een ander aanvalstype gaat, onderstreept het vooral waarom het beschermen van de “gateway”-laag zo belangrijk is.
Extra aandachtspunten: bouw niet alleen op patchen
De bron maakt duidelijk dat er geen patch is voor de pass-through route richting instance metadata, omdat die route niet als een “typische vulnerability” wordt gezien. Dat betekent dat je maatregelen niet uitsluitend in updates moet zoeken.
In plaats daarvan is een combinatie nodig van: het correct instellen van secret keys, het reduceren van netwerk- en IAM-ruimte, het beperken van test- en beheerendpoints, en het periodiek hercontroleren van configuraties die in de loop van de tijd aangepast kunnen worden.
Conclusie
De ontdekking dat de LiteLLM standaard admin key sk-1234 door een aanzienlijk deel van publieke gateways werd geaccepteerd, is een klassiek voorbeeld van waarom defaultwaarden gevaarlijk zijn. Wie beheer kan bereiken, kan mogelijk provider-API keys uitlezen, modelstromen beïnvloeden en in worstcases zelfs cloud IAM-gegevens aanraken via pass-through mechanismen.
De kernactie is helder: vervang sk-1234, upgrade naar 1.84.0 of later en blokkeer waar nodig de risicovolle MCP- en guardrails-testendpoints. Combineer dat met strengere netwerk- en IAM-restricties en voer een zorgvuldige reset uit als er vermoedens zijn van compromis. Zo voorkom je dat een gateway die bedoeld is om AI slimmer te verbinden, zelf een toegangspoort wordt.
Bron: https://thehackernews.com/2026/09/nearly-1-in-10-exposed-litellm-gateways.html
