LiteLLM-hack begon met sleutel die 136 dagen bleef liggen
De besmette LiteLLM-versie die vorige week twee uur lang AI-sleutels stal, is terug te voeren op een fout van eind mei. Dat blijkt uit het incidentrapport dat LiteLLM vrijdag publiceerde. Een gelekte hoofdsleutel werd nooit ingetrokken en lag 136 dagen voor het oprapen.
LiteLLM is een veelgebruikte open-sourcegateway waarmee bedrijven via één koppeling modellen van OpenAI, Anthropic en andere aanbieders aanspreken. Wij schreven eerder al over de besmette versie 1.107.0 die AI-sleutels stal. Nu is duidelijk hoe de aanvaller binnenkwam.
Weggepoetst, maar niet ingetrokken
Op 27 mei 2026 belandde een configuratiebestand in een publieke repository van LiteLLM-Labs. Daarin stond de hoofdsleutel van een LiteLLM Agent Platform-omgeving. Het team overschreef de commit met een force-push en markeerde de sleutels voor intrekking. “Key revocation did not occur for the master key”, schrijven Oliver Jensen en Mateo Wang van LiteLLM, zo citeert The Hacker News.
Op 10 oktober gebruikte een aanvaller die sleutel. Via het Agent Platform haalde hij een GitHub OAuth-token binnen dat aan het account van een organisatie-eigenaar hing en nergens tot beperkt was. Met tijdelijke branches liet hij workflows draaien die tokens van twee beheerders buitmaakten, plus API-sleutels voor onder meer Anthropic, OpenAI, AWS Bedrock en GitGuardian.
Versoepelde releaseregels hielpen de aanvaller
Op 21 oktober sloeg de aanvaller toe. Hij zette de branchbeveiliging uit, liet de releasepipeline bouwen vanuit de nagemaakte repository “Berri-AI/litellm” (met een extra koppelteken) en publiceerde om 11:39 UTC versie 1.107.0 op PyPI. Normaal moet een vrijgave worden goedgekeurd door een speciaal account dat aan een kantoorapparaat vastzit. Juist die week was de regel versoepeld: elke twee engineers mochten een release starten en goedkeuren. De aanvaller gebruikte het ene gestolen token om te starten en het andere om goed te keuren.
Volgens Socket sloeg de eigen scanner van het beveiligingsbedrijf zeven minuten na publicatie alarm. Upwind-onderzoeker Lidor Machluf meldde de aanval om 12:06 UTC, PyPI zette de versie om 13:23 UTC in quarantaine. De Docker-images bleven nog tot 14:20 UTC besmet.
Python starten was al genoeg
De malware draaide zodra Python opstartte, ook als een applicatie LiteLLM nooit importeerde. Het securityteam van Microsoft waarschuwde dat alleen het verwijderen van het pakket niet volstaat, omdat de opstartbestanden buiten de LiteLLM-map staan. De code verzamelde SSH-bestanden, omgevingsvariabelen en tokens voor npm, PyPI en Cargo, en installeerde op Unix-systemen een achterdeur die elk uur nieuwe code ophaalde. Jensen erkent dat “some of our assumptions and beliefs were later proven to be inaccurate or incomplete”. LiteLLM trekt nu elk token in bij alle interne systemen en leveranciers.
Het patroon is bekend. Eerder deze maand moesten gebruikers na het OpenCode-lek hun API-sleutels vervangen, en ook PoeLLM-malware richtte zich op AI-servers.
Wat betekent dit
Een AI-gateway bevat de sleutels van een hele organisatie en is daarmee een aantrekkelijk doelwit. Wie 1.107.0 heeft geïnstalleerd, moet de omgeving als gecompromitteerd beschouwen, opnieuw opbouwen en alle bereikbare sleutels vervangen. De les voor iedereen die code publiceert is simpel: een uitgelekte sleutel uit de geschiedenis poetsen helpt niet, je moet hem intrekken. Beperk automatiseringstokens tot wat ze echt nodig hebben en versoepel releaseregels niet onder tijdsdruk. Diezelfde vraag speelt bij agents die zelf inloggen, zoals 1Password met zijn nieuwe agentfunctie laat zien.
