LiteLLM traceerde de aanval op release 1.107.0 in een rapport van 23 oktober terug naar een mastersleutel die op 27 mei openbaar was gemaakt en niet was ingetrokken. De aanvaller gebruikte die sleutel om toegang te krijgen tot LiteLLM Agent Platform, bemachtigde vervolgens GitHub-tokens en liet op 21 oktober een besmette release publiceren.
De eerste GitHub-token kwam via Agent Platform
Volgens LiteLLM gebruikte de aanvaller de blootgestelde sleutel op 10 oktober om toegang te krijgen tot Agent Platform. Via die dienst verkreeg de aanvaller het GitHub CLI OAuth-token van een eigenaar van de GitHub-organisatie. Daarna werden workflows gebruikt om tokens van twee maintainers buit te maken.
LiteLLM had aanvankelijk vermoed dat het eerste token uit deploymentlogs kwam. Het bedrijf corrigeerde die verklaring in zijn rapport van 23 oktober: het token kwam via Agent Platform, dat met de niet ingetrokken mastersleutel toegankelijk was.
Van de sleutelblootstelling naar release 1.107.0
De tijdlijn van LiteLLM loopt van de openbare sleutelblootstelling tot de besmette release en het latere verslag van de aanvalsketen.
| Datum | Gebeurtenis |
| 27 mei 2026 | Een configuratiebestand met de mastersleutel voor LiteLLM Agent Platform werd openbaar gemaakt in de repository LiteLLM-Labs/lite-harness. De sleutel werd niet ingetrokken. |
| 10 oktober 2026 | De aanvaller gebruikte de sleutel voor toegang tot Agent Platform en verkreeg het GitHub-token van een organisatie-eigenaar. Workflows werden daarna gebruikt om tokens van twee maintainers buit te maken. |
| 21 oktober 2026 | De releaseworkflow werd aangepast en gebruikte de lookalike-repository Berri-AI/litellm als bron voor de besmette release 1.107.0. |
| 23 oktober 2026 | LiteLLM publiceerde zijn gecorrigeerde verslag van de aanvalsketen. |
De twee GitHub-repositorynamen zijn gemakkelijk te verwarren: Berri-AI/litellm was de door de aanvaller beheerde bronrepository, terwijl BerriAI/litellm de legitieme repository is. LiteLLM meldde dat de officiële GitHub-brontag voor versie 1.107.0 de schadelijke bestanden niet bevatte. De besmette pakketten en containerimages waren gebouwd vanuit de lookalike-bron.
Welke PyPI-pakketten en containertags waren getroffen?
LiteLLM meldde dat alle zeven PyPI-wheels van litellm==1.107.0 waren besmet. De wheels verschenen op 21 oktober tussen 11:39:51 en 11:40:13 UTC; PyPI had de release uiterlijk om 13:23 UTC verwijderd.
Op Docker Hub en GHCR waren de tags v1.107.0, latest, main-latest en main-stable getroffen. De images verschenen om 11:46:56 UTC. De betrokken GHCR-tags waren uiterlijk om 13:51 UTC niet beschikbaar; de Docker Hub-tags waren uiterlijk om 14:20 UTC verwijderd of omgeleid naar schone images. Op GHCR betrof het onder meer ghcr.io/berriai/litellm, ghcr.io/berriai/litellm-database en ghcr.io/berriai/litellm-non_root.
Voor een Docker-installatie is dus van belang of een getroffen tag of image binnen dat tijdvenster is opgehaald of gestart. De bronrepository Berri-AI/litellm was niet hetzelfde als de getroffen images in de registries.
Wat de payload deed en wat Wiz waarnam
Wiz meldde dat de pakketten de bestanden cook.pth, cook.py en sitecustomize.py in Python’s site-packages plaatsten. De bestanden waren bedoeld om tijdens het starten van Python code uit te voeren. De stealer richtte zich volgens Wiz op onder meer browsergegevens, cloud- en AI-sleutels, SSH- en GPG-sleutels, shellgeschiedenis en providergegevens in de LiteLLM-proxydatabase. Wiz beschreef de externe loader voor Linux en macOS.
Wiz schatte op basis van ClickPy-gegevens dat versie 1.107.0 ongeveer 49.000 downloads had. Dat is een downloadschatting, geen telling van bevestigde infecties. Tussen 16:20 en 17:01 UTC op 21 oktober zag Wiz AWS-identiteitscontroles en aanroepen om beschikbare modellen in Amazon Bedrock op te vragen. Die waarnemingen beschrijven controle van gestolen inloggegevens en het opvragen van een modellenlijst.
LiteLLM’s advies voor getroffen omgevingen
LiteLLM adviseerde open-sourcegebruikers versie 1.106.2 vast te zetten, of een andere expliciete versie van vóór de aanval te gebruiken. Voor omgevingen waarin een getroffen pakket of image was gestart, adviseerde het bedrijf de schadelijke bestanden te verwijderen, de omgeving opnieuw op te bouwen en geheimen te vervangen waartoe die machine toegang had. LiteLLM meldde dat klanten die de private enterprise-registry gebruikten niet door dit incident waren getroffen.
