Il 24 marzo 2026, due versioni del pacchetto Python litellm — strumento open source ampiamente utilizzato come gateway universale per API di modelli linguistici — sono state pubblicate su PyPI da un account maintainer compromesso. Le versioni 1.82.7 e 1.82.8 contengono malware che si attiva automaticamente all'avvio dell'interprete Python, raccoglie credenziali da ambienti locali e cloud, e le esfiltra verso un dominio controllato dall'attaccante. La vicenda rivela un paradosso della supply chain moderna: uno strumento di security scanning è diventato il vettore di compromissione della catena di pubblicazione.
- Le versioni PyPI 1.82.7 e 1.82.8 di litellm contengono malware: la prima inietta payload in
proxy/proxy_server.py, la seconda sfrutta il filelitellm_init.pthda 34.628 byte per esecuzione automatica senza necessità di import - Il payload raccoglie variabili d'ambiente, chiavi SSH, credenziali AWS/GCP/Azure/Kubernetes, wallet crypto, chiavi SSL, cronologie shell e webhook Slack/Discord, cifrando i dati con AES-256-CBC e chiave sessione protetta da RSA-4096 pubblico hardcoded
- L'esfiltrazione avviene verso il dominio
litellm.cloud, registrato il 23 marzo 2026 via Spaceship, Inc.: un nome deliberatamente confondibile con il dominio ufficiale litellm.ai - PyPI ha messo l'intero pacchetto in quarantena, causando failure di installazione anche per versioni legittime; la root cause probabile è la compromissione di Trivy, tool di security scanning, che ha esposto credenziali CI/CD della pipeline di pubblicazione
Come funziona il meccanismo d'attacco: l'abuso dei file .pth
Il malware nella versione 1.82.8 sfrutta un meccanismo poco conosciuto ma documentato di Python: i file .pth (path configuration files). Questi file, collocati nelle directory dei pacchetti installati, vengono eseguiti automaticamente all'avvio dell'interprete Python, senza che l'utente debba effettuare alcun import esplicito.
Il file litellm_init.pth, di 34.628 byte, contiene codice che avvia un subprocess Python con payload doppiamente codificato in base64. La doppia codifica serve a occultare il contenuto agli strumenti di analisi statica e agli audit superficiali del filesystem. Una volta decodificato, lo script raccoglie dati sensibili dall'ambiente host e li trasmette via HTTP a litellm.cloud con header Content-Type: application/octet-stream.
La versione 1.82.7, pubblicata poche ore prima, utilizza un vettore diverso: il payload è iniettato direttamente in proxy/proxy_server.py e si attiva al momento dell'import del modulo, richiedendo quindi un'interazione esplicita diversa dall'esecuzione silenziosa del .pth.
"The litellm==1.82.8 wheel package on PyPI contains a malicious .pth file (litellm_init.pth, 34,628 bytes) that automatically executes a credential-stealing script every time the Python interpreter starts — no import litellm required." — Analisi tecnica, issue #24512
L'hijack dell'account e la catena di pubblicazione manomessa
L'account PyPI del maintainer krrishdholakia è risultato dirottato da un attore identificato come teampcp, secondo quanto documentato dal team LiteLLM. Le versioni malevole non corrispondono a nessun tag nel repository GitHub ufficiale: il rilascio più recente documentato è v1.82.6.dev1, mentre 1.82.7 e 1.82.8 sono state caricate direttamente su PyPI dall'attaccante.
Questa discrepanza tra repository sorgente e artefatti pubblicati è un indicatore classico di compromissione dell'account di pubblicazione, non del codice sorgente in sé. Il dominio di esfiltrazione litellm.cloud è stato registrato il 23 marzo 2026, il giorno precedente alla pubblicazione delle versioni malevole, con timing che suggerisce pianificazione deliberata piuttosto opportunismo.
Il team LiteLLM ha coinvolto il gruppo Mandiant di Google per l'investigazione forense, come dichiarato pubblicamente: "We've engaged Google's mandiant.security team, and are actively working on this with them".
Il paradosso Trivy: quando lo scanner di sicurezza diventa vulnerabilità
L'elemento più rilevante della lettura tecnica è la root cause identificata: la compromissione di Trivy, tool open source di Aqua Security per la scansione di vulnerabilità in container e dipendenze. Trivy viene eseguito tipicamente nelle pipeline CI/CD prima della pubblicazione; se compromesso, può esporre le credenziali di accesso al repository di distribuzione.
Questo configura un paradosso della supply chain moderna: lo strumento incaricato di garantire la sicurezza del software diventa il punto di fallimento che ne compromette l'integrità. Non è la prima volta che strumenti di security scanning vengono menzionati in incidenti di supply chain, ma la documentazione esplicita di questo vettore nel caso LiteLLM ne conferma la rilevanza operativa.
Il dossier non specifica se Trivy sia stato l'unico vettore di compromissione o se siano coinvolti altri punti di ingresso nella pipeline. L'audit è in corso e il team ha indicato che anche le versioni precedenti a 1.82.7 dovrebbero essere verificate.
Cosa fare adesso
Le azioni prioritarie per chi ha utilizzato il pacchetto nei giorni dell'incidente:
- Verificare l'installazione: controllare se nei propri ambienti è presente
litellm==1.82.7olitellm==1.82.8in lockfile, cache pip, container o immagini Docker; il filelitellm_init.pthcon hash SHA256ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjgè indicatore di compromissione confermato - Rotazione di tutti i secret esposti: variabili d'ambiente, chiavi AWS/GCP/Azure, credenziali Kubernetes, chiavi SSH, token di servizio, webhook e chiavi SSL presenti sui sistemi dove il pacchetto è stato installato o dove l'interprete Python è stato avviato
- Ispezione delle pipeline CI/CD: verificare che Trivy o altri strumenti di scanning nella catena di build non abbiano esposto credenziali di pubblicazione o accesso a repository privati
- Monitoraggio dell'esfiltrazione: controllare i log di rete per connessioni verso
litellm.cloudnegli ultimi mesi, con attenzione particolare ai periodi successivi al 24 marzo 2026
L'impatto della quarantena PyPI e i limiti del recupero
PyPI ha risposto mettendo l'intero pacchetto litellm in quarantena: attualmente tutte le versioni restituiscono errore No matching distribution found. Questa misura protegge dall'installazione accidentale delle versioni compromesse, ma interrompe anche le installazioni legittime di versioni precedenti, creando un impatto a valle sui progetti dipendenti.
Il numero esatto di download delle versioni malevole prima della quarantena non è disponibile nelle fonti. Non emerge conferma che le credenziali esfiltrate siano state già utilizzate per accessi non autorizzati, né che l'identità reale dell'attaccante teampcp sia stata attribuita. L'esito completo dell'investigazione Mandiant è ancora pendente.
Perché questo caso riordina i presupposti della supply chain Python
La vicenda LiteLLM non è un incidente isolato di account compromesso, ma un caso studio su come la sovrapposizione di strumenti di sicurezza possa generare vulnerabilità inaspettate. Il meccanismo .pth è noto da anni nella comunità Python, ma la sua potenziale abusabilità in scenari di supply chain resta sottovalutata nella maggior parte delle pipeline di build.
Il confine tra dominio ufficiale e dominio malevolo — litellm.ai contro litellm.cloud — è progettato per ingannare gli operatori umani e bypassare controlli automatici basati su pattern matching. La cifratura AES-256 con chiave sessione protetta da RSA-4096 indica una progettazione orientata alla resistenza all'analisi forense, non a un'operazione improvvisata.
Per le organizzazioni che usano LiteLLM come gateway LLM in produzione, l'incidente impone una verifica non solo del proprio perimetro, ma della catena completa di pubblicazione e dei tool di terze parti inseriti nella CI/CD.
Fonti
- https://github.com/BerriAI/litellm/issues/24512
- https://github.com/BerriAI/litellm/issues
- https://github.com/BerriAI/litellm/pulls
- https://github.com/BerriAI/litellm/security
- https://github.com/BerriAI/litellm/issues/24518
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.