Een LiteLLM master key lek laat zien hoe snel één fout in een ontwikkelrepo kan uitgroeien tot een volledige supply-chain aanval. In dit incident werd een master key die per ongeluk in een publieke GitHub-omgeving terechtkwam later gebruikt om GitHub-toegang te verkrijgen op organniveau. Vervolgens werd de release van een populaire Python package gemanipuleerd en werden er allerlei tokens en secrets verzameld.
Het verhaal draait niet alleen om gestolen sleutels. Ook de manier waarop de releaseprocessen en workflows zijn misbruikt, maakt dit incident relevant voor iedereen die software bouwt, publiceert en automatiseert — zeker in omgevingen waar AI-agent tooling en cloud-achtige integraties samenkomen.
Wat is er gelekt bij LiteLLM?
LiteLLM meldt dat een configuratiebestand eind mei 2026 per ongeluk een master key bevatte voor de LiteLLM Agent Platform-infrastructuur. Die sleutel stond in een commit in het publieke GitHub-project LiteLLM-Labs/lite-harness.
De fout werd volgens LiteLLM snel opgemerkt: de commit is vervolgens force-pushed en de blootgestelde sleutels moesten worden ingetrokken (revocation). Alleen: de master key zelf is niet ingetrokken.
Toen een aanvaller de sleutel later alsnog kon gebruiken, werd toegang verkregen tot een omgeving die bedoeld was om agents geautoriseerd pull requests te laten doen richting GitHub-repositories.
Hoe kwam de aanvaller aan GitHub-organtokens?
Op 10 oktober 2026 gebruikte de aanvaller de onvervalste master key om toegang te krijgen tot het Agent Platform. Daarbij werd ook een GitHub CLI OAuth-token buitgemaakt dat gekoppeld was aan een service die zelf-hosted cloud agents inzet voor repository-activiteiten.
De token bleek — volgens de ontwikkelaars — niet “scoped down” te zijn en was gekoppeld aan het GitHub-account van de organisatie- owner. Dat is cruciaal: met owner-level toegang kan een aanvaller binnen die organisatie verder bewegen, gegevens exfiltreren en vooral ook de softwareketen beïnvloeden.
De impact werd groter doordat de token toegang gaf tot alle repositories onder die organisatie, waardoor ook aanvullende credentials konden worden verzameld.
Kaping van de release-pijplijn
Op basis van de tijdlijn die LiteLLM beschrijft, volgde een reeks stappen waarmee de releaseketen werd omgebogen. Eerst werden er in korte tijd “throwaway” branches aangemaakt om workflows te laten draaien die tokens kunnen oogsten via een attacker-gestuurd webhook-eindpunt.
Daarna werd op 21 oktober 2026 de branch protection aangepast en werd de release pipeline gewijzigd. In plaats van de vertrouwde bron werd de release ingesteld op een lookalike repository: Berri-AI/litellm in plaats van BerriAI/litellm.
Vervolgens publiceerde LiteLLM op dezelfde dag een nieuwe versie op PyPI en werden ook containerimages gedeeld op Docker Hub en GHCR. Tegelijk werden productie- en staging-runrecords gewist, waardoor sporen lastiger terug te vinden waren.
Uiteindelijk werd de supply-chain aanval gesignaleerd door een onderzoeker, waarna PyPI de versie is gaan isoleren (quarantine) en later de Docker-tags zijn teruggezet of verwijderd voor de aangevallen artefacten.
Waarom de aanvaller niet meteen alles hoefde te “hacken”
Een belangrijk detail in het incidentrapport is dat de releases niet “zomaar” gestart en goedgekeurd konden worden. In normale omstandigheden moest een geautoriseerde engineer de release activeren en moest een aparte account-bescherming (met een fysieke-device lock) de goedkeuring verzorgen.
Maar die beperking was tijdelijk versoepeld om vaker releases en bugfix-backports te kunnen doen. Daardoor konden meerdere engineers releases triggeren en goedkeuren. De aanvaller kon op die manier met behulp van tokens de release doen starten én goed laten keuren.
Dat maakt dit incident extra leerzaam: zelfs goede controles kunnen hun waarde verliezen als ze tijdelijk worden verruimd, zeker wanneer een aanvaller al in het systeem zit via een zeer krachtige toegangsstroom.
Wat deden de malafide workflows?
Later kwamen er meer technische details naar boven over de workflows die voor het verzamelen van secrets werden ingezet. Een andere onderzoeker rapporteerde dat twee malafide commits workflows toevoegden aan een pad als .github/workflows/cache.yml.
Opvallend is de manier waarop de activiteit is “verpakt”: de commits werden niet op een bestaande branch geduwd, maar op korte tijd levende branches met namen zoals ci-tmp-
De workflow werd zo opgezet dat ze telkens bij push-events draait. Daarna konden de runs worden gebruikt om tokens en keys te verzamelen voor allerlei systemen binnen de organisatie.
Welke secrets konden worden geraakt?
De analyses noemen onder andere dat de workflows GitHub-tokens en API-sleutels konden oogsten voor onder meer de Linear workspace en verschillende AI- en platformintegraties. Bovendien werd de verzameling uitgebreid met API keys voor externe diensten (zoals Anthropic, OpenAI en AWS Bedrock), tokens voor secret-scanning tooling en ook test- en databasegerelateerde gegevens.
In de beschreven resultaten zitten ook gegevens zoals een PostgreSQL connection string (inclusief account en password), informatie over Redis endpoints en authenticatiegegevens. Daarnaast werd “Playwright storage state” meegenomen: een soort sessie-informatie waarmee je toegang kunt krijgen zonder opnieuw inlog en zonder MFA-afhandeling.
De exfiltratie vond plaats richting meerdere webhook[.]site-eindpunten, wat past bij een patroon waarbij data tijdelijk “uit het zicht” wordt gelogd bij een aanvaller.
Wat deed de gemanipuleerde LiteLLM-versie?
Naast de pipeline-aanval is ook de payload relevant. Meerdere meldingen geven aan dat in de getroffen versie 1.107.0 onderdelen zijn ingebouwd die zichzelf automatisch kunnen uitvoeren wanneer Python start, ook als de applicatie de LiteLLM-module niet expliciet importeert.
De malware heeft twee sporen:
- Credential harvesting: het verzamelen van authenticatiemateriaal uit ontwikkeltools, AI-toepassingen, cloudomgevingen en zelfs webbrowser-gerelateerde gegevens.
- Unix-achtige backdoor: een achtergrondproces dat elke uur code kan ophalen en uitvoeren die door de aanvaller wordt aangeleverd.
De stealer verzamelt daarbij ook informatie zoals systeemdetails, SSH-gerelateerde bestanden, Git-gerelateerde tokens, environment variables en een breed scala aan ecosystem-tokens (voor onder meer npm, PyPI/pip, Yarn, Maven, Gradle, Composer, RubyGems en Cargo). Daarna wordt de data gecomprimeerd en verstuurd via een HTTP POST naar een endpoint op litellm[.]dev/healthcheck (waarvoor volgens de meldingen een domein recent is geregistreerd).
Een extra risico zit in de structuur van de startup-componenten: omdat sommige “startup files” zich buiten de directe LiteLLM-applicatiemap bevonden, kan alleen het verwijderen van LiteLLM-bestanden onvoldoende zijn. Daarmee blijft er een kans dat kwaadaardige startup-onderdelen achterblijven.
Wat betekent dit voor jouw security aanpak?
De les uit de LiteLLM master key lek is dat supply-chain aanvallen vaak beginnen met ogenschijnlijk “kleine” ontwikkelartefacten: een key in een configbestand, een vergeten revocation, of een tijdelijke controle die te ruim staat.
Concreet helpt het om je aandacht te richten op drie punten:
- Key management en intrekken zonder uitzonderingen: als een sleutel eenmaal is blootgesteld, moet de revocation ook echt afgerond zijn.
- Scopes beperken: tokens met brede bevoegdheden (zoals org owner-level) maken incidenten veel gevaarlijker.
- Release automation hard maken: beperk wie releases kan triggeren en goedkeuren, en bewaak changes aan branch protection en pipeline-config.
Wil je meer context over hoe AI-gerelateerde tooling en supply-chain risico’s samenkomen? Lees dan ook ons artikel over LiteLLM supply chain-aanval via PyPI en Docker.
En als je een breder beeld wilt van het soort misbruik dat begint met toegang tot geautomatiseerde omgevingen, dan is AI-agenten als insider threat: wat je nu ziet een nuttige aanvulling.
Tot slot: houd rekening met de praktische gevolgen van gemanipuleerde startcomponenten. Ook daar gaat vaak veel tijd verloren als je vooral kijkt naar de “application folder”, in plaats van naar alle startup-paden en configuratiemechanismen.
Conclusie
De LiteLLM master key lek toont hoe één vergeten sleutel in een publieke repo kan leiden tot gestolen GitHub-tokens, kaping van branch protections en een gemanipuleerde release van een Python package. De aanval combineert toegang tot de ontwikkelketen met payloads die zich niet beperken tot een expliciete import.
Voor teams die werken met CI/CD, package publishing en AI-agent platformen geldt: voer revocation strikt uit, beperk tokenbevoegdheden en bewaak release-pijplijnen continu. Zo verklein je de kans dat eenmalige fouten uitgroeien tot een grootschalige supply-chain verstoring.
Bron: https://thehackernews.com/2026/10/leaked-litellm-master-key-let-attackers.html
