La pipeline di rilascio di LiteLLM è stata compromessa il 21 ottobre 2026, consentendo a un attaccante di pubblicare una versione malevola del software gateway per l'AI attraverso PyPI, Docker Hub e GitHub Container Registry.
La release interessata, LiteLLM v1.107.0, raccoglieva credenziali e altri segreti dai sistemi in cui veniva eseguita, secondo i risultati di Aikido e Wiz riportati da The Hacker News. Successivamente Wiz ha osservato tentativi di validare credenziali AWS rubate provenienti da runner CI e nodi Kubernetes compromessi.
LiteLLM ha divulgato l'incidente in un comunicato pubblicato di mercoledì. L'azienda ha collocato l'intrusione intorno alle 4:00 PST del 21 ottobre 2026.
Quali pacchetti e tag dei container sono stati interessati
Gli artefatti compromessi includevano:
- Pacchetto PyPI LiteLLM v1.107.0
- Tag Docker/GHCR v1.107.0
- Tag Docker/GHCR latest
- Tag Docker/GHCR main-latest
- Tag Docker/GHCR main-stable
Per PyPI, la finestra di esposizione riportata riguarda gli utenti che hanno installato con pip un pacchetto LiteLLM non fissato a una versione specifica tra le 11:39 e le 13:23 UTC.
La finestra di esposizione dei container va dalle 11:46 alle 14:20 UTC per gli utenti che hanno scaricato o comunque utilizzato le immagini con i tag elencati. Poiché erano coinvolti diversi tag mutabili, controllare solo il tag configurato in un deployment potrebbe non bastare a stabilire quale immagine sia stata effettivamente eseguita; i team di difesa dovrebbero verificare l'artefatto o l'immagine esatta utilizzata.
Token GitHub rubati hanno reso possibile una release compromessa
Secondo quanto riferito da LiteLLM, l'attaccante aveva accesso a tre set di credenziali GitHub CLI di sviluppatori. Uno di questi poteva avviare i workflow di GitHub, mentre un token appartenente a un proprietario dell'organizzazione è stato usato per disattivare le protezioni dei branch e forzare il push di modifiche malevole.
Il workflow compromesso è stato reindirizzato dal repository legittimo BerriAI/litellm a un repository dal nome simile, Berri-AI/litellm. Questa sostituzione ha fatto sì che i pacchetti e le immagini malevoli risultanti attraversassero il processo di firma e pubblicazione del progetto.
Due giorni prima, il 19 ottobre 2026, LiteLLM aveva temporaneamente ampliato i permessi di rilascio per due ingegneri interni incaricati di emettere ogni giorno backport di correzioni di bug per i clienti.
L'azienda sospetta che i token GitHub possano essere stati esposti attraverso i log di un deployment interno raggiungibile da internet, in cui ha trovato un account inatteso dal nome innocuo. LiteLLM ha dichiarato che Claude Code può inserire il token OAuth della GitHub CLI di un utente nel corpo di una risposta; se questi corpi vengono registrati, di conseguenza il token può comparire nei log di LiteLLM. L'azienda presenta questa come una pista sospetta, non come un punto d'ingresso iniziale accertato.
LiteLLM ha affermato di aver introdotto ulteriori protezioni per i rilasci dopo un incidente separato avvenuto a marzo 2026, tra cui lo spostamento dei rilasci in un repository privato, l'immutabilità dei tag di release Docker e la firma delle immagini dei container. Nella compromissione di ottobre, tuttavia, l'attaccante è riuscito a manipolare il workflow responsabile della produzione e della pubblicazione degli artefatti firmati.
Il malware ha raccolto segreti e mantenuto una backdoor ogni ora
Aikido e Wiz hanno descritto due meccanismi di esecuzione Python incorporati nella release compromessa.
Il primo usava cook.pth, che importava un modulo Python chiamato cook. Il relativo script cook.py si deoffuscava da solo e avviava una routine di furto di credenziali chiamata privcollect.
Il malware prendeva di mira i segreti associati a:
- Sistemi operativi
- Browser web
- Strumenti di sviluppo
- Ambienti cloud
- Strumenti di AI
Le informazioni raccolte venivano inviate tramite una richiesta HTTP POST a:
litellm[.]dev/healthcheck
Su Linux e macOS, un secondo componente chiamato sitecustomize.py tentava di recuperare domain.txt da un dead drop su GitHub associato a github[.]com/letters9813. Una risposta valida forniva l'indirizzo da cui il malware poteva scaricare ed eseguire uno script Python di secondo stadio, situato in <domain>/codepy.
Il componente ha inoltre generato un processo in background, creato il file di lock /tmp/remote_code_loader.lock ed entrava in un ciclo che controllava il dead drop ogni ora, prima di tentare di nuovo di eseguire il payload remoto. Aikido ha descritto questo meccanismo come un remote access trojan.
Wiz ha riferito che GitHub ha rimosso il file di testo del dead drop intorno alle 13:30 UTC. Prima della rimozione, secondo quanto riportato, il file conteneva solo valori di test iniziali.
Le credenziali AWS sono state testate ore dopo l'esfiltrazione
Wiz ha riferito che l'abuso è iniziato circa 4,5 ore dopo l'esfiltrazione delle credenziali. Tra le 16:20 e le 17:01 UTC del 21 ottobre 2026, l'attaccante ha testato le credenziali di instance role AWS ottenute da runner CI e nodi Kubernetes.
Ogni credenziale è stata verificata con:
sts:GetCallerIdentitybedrock:ListFoundationModels- Una chiamata
ListModels
Wiz ha ritenuto che questa attività fosse coerente con LLMjacking, in cui le credenziali cloud rubate vengono testate per verificarne l'accesso a servizi AI ospitati. In un numero ristretto di ambienti, l'attaccante ha inoltre eseguito attività di discovery su IAM e infrastruttura, usando operazioni come ListRoles, ListUsers, ListAccessKeys, ListAccounts e DescribeTrails.
Il traffico di validazione delle credenziali è associato a:
168.100.8[.]57
165.227.201[.]8
Sebbene l'uso di un file .pth ricordi l'attacco di marzo 2026 attribuito da alcune fonti a TeamPCP, Socket non ha trovato prove pubbliche che stabiliscano che i due incidenti fossero riconducibili allo stesso operatore. Socket ha rilevato differenze nelle chiavi pubbliche RSA incorporate, nel codice di esfiltrazione e nel comportamento della backdoor. Ha inoltre affermato che le prove disponibili non stabiliscono se le credenziali rubate a marzo abbiano contribuito alla compromissione di ottobre.
Cosa devono fare ora gli utenti di LiteLLM
Le organizzazioni che hanno installato o eseguito LiteLLM 1.107.0, anche tramite i tag dei container interessati, dovrebbero considerare potenzialmente compromessi l'host e le credenziali accessibili a quel processo.
Le azioni consigliate includono:
- Rimuovere LiteLLM 1.107.0 dalle macchine e dagli ambienti di deployment.
- Isolare gli host interessati mentre si indaga su ciò a cui il pacchetto ha avuto accesso.
- Cercare:
cook.pthcook.pysitecustomize.py/tmp/remote_code_loader.lock
- Bloccare e analizzare le connessioni verso:
litellm[.]dev/healthcheckgithub[.]com/letters9813raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt
- Indagare su qualsiasi tentativo o esecuzione riuscita di
/codepy. - Verificare nei log AWS l'attività che coinvolge gli indirizzi IP segnalati e le chiamate API.
- Ruotare tutte le credenziali raggiungibili da un ambiente interessato, inclusi i segreti relativi a cloud, sviluppo, browser e servizi di AI.
- Ricostruire i sistemi interessati a partire da artefatti attendibili, anziché affidarsi solo alla rimozione dei file malevoli.
Il ricercatore di JFrog Guy Korolevski ha inoltre consigliato alle organizzazioni di verificare quale wheel esatto sia stato installato e di controllare le versioni dei pacchetti prima che entrino nei sistemi di build. Dove 1.107.0 è stato eseguito, la raccomandazione di JFrog è di ruotare tutte le credenziali che il pacchetto poteva raggiungere e ricostruire l'ambiente interessato.
