Drie LiteLLM-lekken geven gewone gebruikers admin-rechten en code-uitvoering op je AI-gateway

Draait jouw organisatie LiteLLM als centrale AI-gateway? Dan is dit het moment om te updaten en je sleutels te roteren. Beveiligingsonderzoekers van Obsidian Security ontdekten drie aaneengeschakelde kwetsbaarheden waarmee een gewone, laaggeprivilegieerde gebruiker zichzelf tot beheerder kan promoveren en uiteindelijk willekeurige code op de server kan uitvoeren. De keten kreeg een gecombineerde CVSS-score van 9,9 op 10, vrijwel het maximum.

Wat is LiteLLM en waarom dit zwaar weegt

LiteLLM is een populaire open-source AI-gateway: één API waarachter je het verkeer naar tientallen modelaanbieders bundelt, van OpenAI en Anthropic tot Gemini, Bedrock en Azure. Precies dat maakt zo'n gateway een aantrekkelijk doelwit. Wie hem overneemt, zit op het knooppunt waar alle sleutels, prompts en antwoorden langskomen. Voor bedrijven die hun AI bewust zelf draaien is dat normaal een kracht, maar het betekent ook dat de beveiliging volledig in eigen huis ligt.

Drie lekken, één keten

De aanval verloopt in drie stappen, elk een aparte kwetsbaarheid:

• CVE-2026-47101 (autorisatie-omzeiling): een gewone gebruiker maakt een virtuele API-sleutel aan met het veld allowed_routes op ["/*"], en bereikt zo de beheerdersendpoints die normaal afgeschermd zijn.
• CVE-2026-47102 (rechtenescalatie): via het endpoint /user/update kan diezelfde gebruiker zijn eigen record aanpassen zonder controle, en zichzelf de rol proxy_admin toekennen.
• CVE-2026-40217 (sandbox-ontsnapping): de zogeheten custom-code guardrail voert Python uit via exec() zonder de broncode te filteren, wat code-uitvoering op afstand mogelijk maakt, tot een reverse shell aan toe.

Obsidian Security beschreef de volledige keten; beveiligingsbureau X41 D-Sec vond onafhankelijk een aanvullende omzeiling in het playground-endpoint. De combinatie tilt drie op zichzelf hanteerbare fouten op tot een volledige serverovername.

Wat er op het spel staat

Wie de keten afmaakt, heeft toegang tot de gevoeligste gegevens van de gateway: de hoofdsleutel (LITELLM_MASTER_KEY), de salt-sleutel waarmee opgeslagen inloggegevens worden ontcijferd, de database-URL, en alle ingestelde provider-sleutels van OpenAI, Anthropic, Gemini, Bedrock en Azure. Draai je ook MCP- of agent-koppelingen, dan komen daar OAuth-tokens en tool-credentials bij. En omdat al het verkeer langs de proxy loopt, liggen ook alle prompts, antwoorden en logs open. Voor veel organisaties is dat precies het soort bedrijfsgevoelige informatie dat nooit naar buiten mag.

Wat betekent dit voor jouw bedrijf

De goede boodschap: de fouten zijn gedicht in LiteLLM-versie 1.83.14-stable, met een publieke onthulling op 11 juni 2026. Concreet:

1. Update direct naar versie 1.83.14-stable of nieuwer. Draai je een oudere versie, ga er dan vanuit dat je kwetsbaar bent.
2. Roteer alle sleutels die ooit op de gateway stonden: de hoofdsleutel, de salt-sleutel, de database-credentials en elke provider-API-sleutel. Een patch herstelt geen sleutels die mogelijk al gelekt zijn.
3. Controleer je logs op verdachte sleutel-aanmaak, rolwijzigingen of guardrail-uploads.
4. Beperk de toegang tot de gateway tot wie hem echt nodig heeft, en zet hem niet onnodig open op het internet.

Dit illustreert de keerzijde van zelf AI draaien. Self-hosting geeft je controle en houdt je data uit handen van derden, maar het patchen en afschermen is dan jouw verantwoordelijkheid, niet die van een leverancier. Dezelfde afweging speelt bij een open-weight model zoals MiniMax M3 dat je zelf host: de winst zit in eigenaarschap, de prijs is onderhoud. Wie zo'n opzet bouwt of laat bouwen, moet patchbeleid en sleutelbeheer vanaf dag één meenemen. Hoe een gemiste basismaatregel kan uitpakken, toont het Odido-datalek waarbij 6,2 miljoen klantgegevens uitlekten. Wie zo'n opzet bouwt, doet er goed aan patchbeleid en sleutelbeheer vanaf dag één als vast onderdeel mee te nemen, niet als bijzaak achteraf.