Wat er is gebeurd
Op 24 maart 2026 om 10:52 UTC werd versie 1.82.8 van LiteLLM gepubliceerd op PyPI. LiteLLM is een populaire open-source Python-bibliotheek die fungeert als een uniforme API-gateway voor AI-providers, waarmee ontwikkelaars met een enkele interface kunnen wisselen tussen OpenAI, Anthropic, Google en tientallen andere modellen. De bibliotheek is standaardinfrastructuur geworden voor veel AI-teams.
De gecompromitteerde versie bevatte een kwaadaardig .pth-bestand, litellm_init.pth, dat automatisch uitvoerde bij elke Python-processtart. De payload werkte in drie fasen: eerst verzamelde het gevoelige bestanden van de hostmachine (SSH-sleutels, .env-bestanden, AWS- en GCP-inloggegevens, Kubernetes-configs, databasewachtwoorden, shellgeschiedenis en cryptowalletbestanden). Daarna versleutelde het alles met een hardgecodeerde RSA-sleutel en stuurde het naar een domein van de aanvaller. Ten slotte probeerde de malware, als er een Kubernetes-serviceaccounttoken aanwezig was, geprivilegieerde pods aan te maken op elk knooppunt in het cluster en een permanente achterdeur te installeren.
De aanval werd ontdekt door FutureSearch, wiens engineer een processstorm opmerkte op zijn machine en AI-tooling gebruikte om het te herleiden naar het kwaadaardige pakket. Ze maakten dit publiek bekend binnen enkele uren na de ontdekking. De gecompromitteerde versies (1.82.7 en 1.82.8) werden later die dag van PyPI verwijderd. Naar schatting 47.000 machines hebben het getroffen pakket gedownload tijdens het venster dat het beschikbaar was.
Waarom dit belangrijk is voor bedrijven
LiteLLM is geen randbibliotheek. Het wordt breed gebruikt in productie-AI-stacks, ook als afhankelijkheid in tools zoals Cursor en diverse MCP-plugins. Veel organisaties die AI-agents of documentverwerkingspipelines draaien hebben het geinstalleerd zonder het te weten, vaak als een transitieve afhankelijkheid die door iets anders meegebracht wordt. Precies zo kwam het op de FutureSearch-machine terecht: automatisch meegetrokken door een MCP-plugin.
Het aanvalspatroon richt zich precies op de assets die het meest van belang zijn in een AI-implementatie: cloudcredentials, API-sleutels, databasewachtwoorden en infrastructuurconfiguraties. Een aanvaller die deze in handen krijgt, kan van een gecompromitteerde ontwikkelaarslaptop doorpivotten naar je productieomgeving, je CRM, je ERP en je klantgegevens. De straal van een gecompromitteerde AI-afhankelijkheid beperkt zich niet tot het AI-systeem zelf.
Dit incident illustreert ook een diepere trend. Naarmate AI-tooling volwassener wordt, groeit het aanvalsoppervlak. Meer afhankelijkheden, meer integraties, meer API-sleutels in .env-bestanden. Securityteams die nog niet in kaart hebben gebracht wat hun AI-stack daadwerkelijk installeert, opereren blind. En met AI-agents die nu routinematig toegang hebben tot documentopslag, e-mail en interne systemen zijn de gevolgen van een credential-lek groter dan ooit.
Laava's perspectief
Als we AI-integraties bouwen voor klanten, maakt dependency management deel uit van het architectuurgesprek vanaf dag een. Niet als afvinklijstje, maar omdat de AI-laag gevoelige systemen raakt. Een agent voor factuurverwerking heeft toegang tot je ERP. Een klantenserviceagent kan je CRM lezen. Een documentautomatiseringsworkflow verwerkt contracten met echte financiele termen. Elk van die verbindingen is een potentieel risicopunt als de softwarestack eronder niet gecontroleerd is.
Het LiteLLM-incident is een argument voor het slank en geaudit houden van je AI-stack. Minder transitieve afhankelijkheden. Gepinde versies met hashverificatie. Private pakketspiegels voor productieomgevingen. Dit zijn geen exotische maatregelen: het is standaard software supply chain-hygiëne toegepast op een nieuwe context. Het AI-ecosysteem heeft zich snel bewogen en veel teams hebben de operationele beveiligingskant nog niet bijgehouden.
Dit is ook een van de redenen waarom we voorzichtig zijn met het aanbevelen van cloud-hosted AI-infrastructuur voor klanten die gevoelige gegevens verwerken. Wanneer je AI-workload draait in je eigen omgeving op infrastructuur die je zelf beheert, is het afhankelijkheidsoppervlak auditeerbaar en is de impact van een eventueel compromis beperkt. Sovereign AI gaat niet alleen over dataresidentieregels: het gaat over precies weten welke software draait bij je meest gevoelige systemen.
Wat je nu kunt doen
Als je team LiteLLM gebruikt, controleer dan direct je geinstalleerde versie met pip show litellm en verifieer dat je niet op 1.82.7 of 1.82.8 zit. Controleer je pakketcache op litellm_init.pth. Als je getroffen bent, roteer dan alle credentials die aanwezig waren op de machine: cloudprovidersleutels, API-sleutels, databasewachtwoorden en SSH-sleutels. Controleer op het persistentiebestand ~/.config/sysmon/sysmon.py.
Meer in het algemeen is dit een goed moment om een dependency-audit van je AI-stack uit te voeren. Welke pakketten installeert je AI-pipeline? Welke hebben toegang tot credential-bestanden of cloudmetadata? Kun je je afhankelijkheden pinnen en hashverificeren in productie? Als je bouwt op AI en deze vragen nog geen duidelijk antwoord hebben, is dat een lacune die de moeite waard is om te dichten. Laava helpt je de architectuur van je AI-integraties te beoordelen en te versterken, zodat de tooling die je meest gevoelige systemen raakt de tooling is die je bewust hebt gekozen te vertrouwen.