Attacco alla catena di approvvigionamento di LiteLLM ruba credenziali tramite file .pth malintenzionato

Un grave attacco alla catena di approvvigionamento colpisce il popolare pacchetto Python LiteLLM

L'ecosistema Python è stato scosso da un sofisticato attacco alla catena di approvvigionamento che ha preso di mira LiteLLM, una popolare libreria open-source per standardizzare le chiamate a vari modelli linguistici di grandi dimensioni. Il 24 marzo 2026, i ricercatori di sicurezza hanno scoperto che le versioni 1.82.8 e 1.82.7 pubblicate sul Python Package Index (PyPI) contenevano un file malintenzionato progettato per rubare automaticamente credenziali sensibili all'avvio di qualsiasi interprete Python.

Questo incidente sottolinea la crescente minaccia per l'infrastruttura del software open-source, dove un singolo pacchetto compromesso può portare a un furto di credenziali diffuso in ambienti di sviluppo, CI/CD e produzione. La furtività e il meccanismo di esecuzione automatica dell'attacco lo rendono particolarmente pericoloso.

Il vettore di attacco: un file .pth malintenzionato

Il cuore dell'attacco era un file denominato litellm_init.pth, incluso nella wheel litellm-1.82.8-py3-none-any.whl su PyPI. I file .pth di Python, posizionati in una directory site-packages, vengono eseguiti automaticamente dall'interprete Python all'avvio. Ciò significa che il codice malintenzionato è stato eseguito senza richiedere una dichiarazione esplicita import litellm.

Il file conteneva un payload codificato in base64 doppio. Quando decodificato, ha lanciato un subprocess che ha eseguito uno script completo per rubare credenziali. I ricercatori hanno confermato che anche la versione 1.82.7 era stata compromessa, con il codice malintenzionato nascosto all'interno di proxy/proxy_server.py anziché in un file .pth.

Ambito e portata del furto di dati

Il malware era stato progettato per gettare una rete ampia, raccogliendo sistematicamente un'impressionante gamma di informazioni sensibili dal sistema infetto. Lo script operava in due fasi principali.

La prima fase prevedeva una raccolta aggressiva di informazioni. Ha raccolto dati di sistema come hostname, identità utente, configurazione di rete e tutte le variabili d'ambiente - un obiettivo primario per chiavi API e segreti. Quindi ha preso di mira archivi di credenziali in tutto lo stack di sviluppo e infrastruttura.

• Cloud e infrastruttura: file di configurazione e token di servizio per AWS, Google Cloud, Azure, Docker e Kubernetes.
• Strumenti per sviluppatori: chiavi SSH, credenziali Git e file di cronologia della shell (bash, zsh).
• Database e servizi: file di configurazione per PostgreSQL, MySQL, Redis e LDAP.
• Dati finanziari: chiavi private per portafogli di criptovalute come Bitcoin, Ethereum e Solana.
• Segreti vari: chiavi private SSL/TLS, file di configurazione CI/CD (come .gitlab-ci.yml) e URL di webhook.

Esfiltrazione sofisticata e attribuzione

Successivamente alla raccolta, il malware è passato alla seconda fase: crittografia ed esfiltrazione. I dati rubati sono stati scritti in un file temporaneo, crittografati utilizzando una chiave di sessione AES-256 generata casualmente, e quindi quella chiave è stata a sua volta crittografata utilizzando una chiave pubblica RSA a 4096 bit hardcoded.

L'archivio crittografato finale, tpcp.tar.gz, è stato inviato tramite una richiesta HTTP POST a https://models.litellm.cloud/. Gli analisti di sicurezza hanno notato che il dominio litellm.cloud è un sosia, non il dominio ufficiale litellm.ai. L'attacco è stato attribuito a un'operazione cybercriminale incentrata sul cloud nota come TeamPCP.

Questo gruppo è sospettato di una campagna parallela su larga scala denominata "GlassWorm", che ha compromesso oltre 400 repository di codice su GitHub, npm e estensioni VSCode. La loro modalità operativa prevede l'utilizzo di credenziali rubate per pubblicare malware che poi compromette altri account in una modalità simile a un worm auto-diffondente.

Contesto più ampio della catena di approvvigionamento e TTP

L'incidente di LiteLLM non è isolato. Segue un modello simile osservato in attacchi contro altri strumenti come lo scanner di vulnerabilità Trivy, dove account npm compromessi sono stati utilizzati per pubblicare versioni backdoorate. In quei casi, gli aggressori hanno impiegato una tecnica furtiva di "manipolazione dei tag", forzando i tag di versione esistenti a puntare a commit malintenzionati anziché creare nuove release, bypassando così i sistemi di notifica.

Come ha dichiarato un ricercatore di sicurezza citato nelle fonti, "Questo è il punto in cui l'attacco passa da 'account compromesso pubblica malware' a 'malware compromette più account e si pubblica da solo'.". Ciò crea un pericoloso ciclo di propagazione automatica in cui ogni sviluppatore infetto o pipeline CI/CD con token di pubblicazione accessibili diventa un vettore di attacco involontario.

Risposta immediata e mitigazione

La scoperta ha innescato una risposta urgente della comunità. Grandi progetti downstream come MLflow si sono rapidamente mossi per fissare la loro dipendenza da LiteLLM alla versione 1.82.6 o precedente per mitigare la minaccia. Le raccomandazioni principali per gli utenti interessati sono severe, riflettendo l'ampiezza del potenziale danno.

In primo luogo, tutti i sistemi che hanno installato le versioni compromesse devono essere scansionati per la presenza del file litellm_init.pth e del codice malintenzionato in proxy_server.py. In secondo luogo, e cosa più critica, le organizzazioni devono presumere che tutte le credenziali presenti su quei sistemi siano compromesse.

Ciò richiede una rotazione completa delle chiavi API, dei token di accesso cloud, delle chiavi SSH, delle password dei database e di qualsiasi altro segreto che era stato memorizzato come variabili d'ambiente o in file di configurazione elencati dal malware. I manutentori di LiteLLM devono anche urgentemente controllare le loro credenziali di pubblicazione su PyPI e la pipeline CI/CD per segni di compromissione.

Implicazioni a lungo termine per la sicurezza open source

Questo attacco evidenzia sfide fondamentali nella sicurezza open-source che non possono essere facilmente risolte. Come discusso nelle analisi della sicurezza del Model Context Protocol (MCP), i modelli linguistici di grandi dimensioni (LLM) e i sistemi automatizzati faticano a distinguere tra istruzioni attendibili e contenuto malevolo iniettato nei metadati degli strumenti. Ciò crea rischi persistenti in ambienti di sviluppo sempre più automatizzati.

L'incidente serve come un brusco promemoria della fiducia riposta nei repository di pacchetti e dell'impatto catastrofico di una violazione. Rinforza la necessità di solide pratiche di sicurezza della catena di approvvigionamento del software, tra cui un'attenta gestione delle dipendenze, la scansione automatizzata per comportamenti sospetti dei pacchetti e un approccio zero-trust alla gestione delle credenziali sulle workstation degli sviluppatori e sui server di build.