
Een gelekte LiteLLM master key maakte het mogelijk voor aanvallers om GitHub-tokens te stelen en de release pipeline te kapen, met verspreiding van een kwaadaardige Python-package tot gevolg.
LiteLLM heeft bekendgemaakt dat een master key van hun Agent Platform per ongeluk in mei 2026 openbaar is gemaakt via een publieke GitHub-repository. Deze sleutel werd niet ingetrokken, waardoor een onbekende aanvaller in oktober 2026 toegang kreeg tot het platform en een kwaadaardige versie van de populaire Python-package kon publiceren.
Op 27 mei 2026 werd een configuratiebestand gecommit naar de publieke LiteLLM-Labs/lite-harness repository, waarin per ongeluk de master key stond voor een deployment van het LiteLLM Agent Platform. Hoewel de fout snel werd ontdekt en de commit werd overschreven, werd de master key niet ingetrokken. Op 10 oktober 2026 gebruikte een aanvaller vanaf het IP-adres 69.48.229[.]143 deze sleutel om toegang te krijgen tot het platform en een GitHub CLI OAuth-token te stelen. Dit token was niet beperkt in rechten en gekoppeld aan het account van de organisatie-eigenaar, waardoor de aanvaller eigenaarstoegang kreeg tot alle repositories binnen de organisatie en verdere credential-exfiltratie kon uitvoeren.
De aanvaller voerde verschillende acties uit, waaronder het maken van commits in tijdelijke branches om workflows te activeren die gericht waren op het verkrijgen van tokens van engineers met beheerdersrechten. Vervolgens werd de branchbescherming opgeheven en de release pipeline aangepast om te verwijzen naar een lookalike repository. Hierdoor kon op 21 oktober 2026 LiteLLM versie 1.107.0 worden gepubliceerd op PyPI, gevolgd door publicatie van Docker Hub- en GHCR-images. Kort daarna werden productie- en staging-runrecords verwijderd.
LiteLLM gaf aan dat normaal gesproken releases alleen kunnen worden gestart en goedgekeurd door geautoriseerde engineers met fysieke apparaatverificatie. Deze restrictie was echter tijdelijk versoepeld om frequente releases mogelijk te maken, waardoor elke twee engineers een release konden starten en goedkeuren. De aanvaller maakte hier misbruik van door met gestolen tokens de release te triggeren en goed te keuren. Ook is het mogelijk dat de aanvaller deze restrictie zelf heeft aangepast, aangezien hij al toegang had tot een token van een organisatie-eigenaar.
De workflows die door de aanvaller werden geactiveerd, waren ontworpen om extra sleutels en tokens te identificeren en te exfiltreren, met speciale focus op upstream inference API-tokens. Als reactie op het incident werkt LiteLLM aan het intrekken van alle tokens die gekoppeld zijn aan interne systemen en externe platforms.












