Bijna één op de tien publiek toegankelijke LiteLLM-servers gebruikte nog altijd sk-1234, de voorbeeld-adminsleutel uit de eigen installatiehandleiding van de software. Dat blijkt uit onderzoek van Wiz Research, dat in februari 3.074 internetgeëxposeerde LiteLLM-gateways via Shodan scande.
LiteLLM is een open-source AI-gateway die bedrijven tussen hun applicaties en AI-modelproviders plaatsen om verzoeken te routeren en te beheren. De masterkey van zo’n gateway werkt als sleutel tot het hele systeem. Van de gescande servers accepteerden 294, zo’n 9,6 procent, de sleutel sk-1234. Bij 191 daarvan was helemaal geen eigen sleutel ingesteld, de rest had de voorbeeldwaarde uit de setup guide gewoon laten staan. Een vervolgscan in augustus telde zelfs meer dan 85.000 exemplaren, al gaat het daarbij vermoedelijk grotendeels om honeypots en testopstellingen.
Met de masterkey in handen kan een aanvaller alle opgeslagen API-sleutels van modelproviders uitlezen, meekijken met prompts en antwoorden die door de gateway lopen, en via pass-through endpoints bij cloud-metadata terechtkomen om IAM-credentials van de onderliggende machine te bemachtigen. Wiz demonstreerde dat dit laatste kan via IMDSv2-headers. Ook is zogeheten LLMjacking mogelijk, waarbij aanvallers modeldraaiuren op kosten van het slachtoffer verstoken.
Wiz meldt daarnaast vier kwetsbaarheden in LiteLLM, waaronder een authenticatie-bypass in de MCP-integratie (CVE-2026-59822, CVSS 8,8) en een sandbox-escape die root-toegang oplevert (CVE-2026-40217). Over de ernst van een derde bug, een guardrail-bypass, verschillen Wiz en LiteLLM van mening. Tot 9 september bevatte de officiële documentatie van LiteLLM nog altijd sk-1234 als voorbeeld.
Nederlandse bedrijven die LiteLLM of een vergelijkbare AI-gateway inzetten, doen er verstandig aan meteen te controleren welke masterkey er draait en die te vervangen door een lange, willekeurige waarde, ook zonder meteen te upgraden. Update daarnaast naar versie 1.84.0 of hoger, blokkeer waar mogelijk de /mcp/-endpoints en testroutes voor guardrails, en beperk uitgaand netwerkverkeer vanaf de gateway zodat toegang tot cloud-metadata niet vanzelfsprekend is. Bij twijfel over eerder misbruik: roteer alle onderliggende API-sleutels en controleer logs op ongebruikelijke guardrail-wijzigingen.
Bron: The Hacker News
Zelfde kwetsbaarheid
Blijf op de hoogte
Volg CybersecurityNieuws.nl via RSS en mis geen enkel beveiligingsnieuws. Zelf iets gezien dat wij moeten weten? Tip de redactie.