L'attacco alla supply chain di LiteLLM è un campanello d'allarme per ogni team che usa strumenti AI

Cosa è successo

Il 24 marzo 2026, qualcuno ha pubblicato versioni malevole di LiteLLM (1.82.7 e 1.82.8) direttamente su PyPI, aggirando il normale processo di rilascio del progetto. I pacchetti compromessi contenevano un malware per il furto di credenziali che raccoglieva chiavi SSH, credenziali dei cloud provider, configurazioni Kubernetes, chiavi API e altro ancora, per poi esfiltrarli verso un dominio che sembrava appartenere a LiteLLM, ma non era così.

I pacchetti malevoli sono rimasti attivi per circa 40 minuti prima che PyPI li mettesse in quarantena. Non sembra molto. Ma LiteLLM viene installato circa 15-20 milioni di volte a settimana, il che corrisponde a circa 1.700 installazioni al minuto. In quella finestra temporale si sono verificati oltre 119.000 download. Si stima che il 40-50% di questi fossero installazioni non fissate che scaricavano automaticamente l'ultima versione disponibile.

L'attacco è partito da una dipendenza Trivy compromessa nel workflow di sicurezza CI/CD di LiteLLM. Si ritiene che un gruppo chiamato TeamPCP sia responsabile, e ci sono indicazioni che abbiano collaborato con il gruppo di estorsione Lapsus$ per monetizzare i dati sottratti. All'RSA Conference della scorsa settimana, i ricercatori di incident response hanno confermato di essere a conoscenza di oltre 1.000 ambienti SaaS colpiti, e i threat hunter stimano che i dati siano stati esfiltrati da 500.000 macchine.

Questa settimana, la prima vittima a valle si è fatta avanti pubblicamente. Una startup di recruiting basata sull'AI ha confermato di essere stata «una delle migliaia di aziende» colpite, e il gruppo Lapsus$ sta ora mettendo all'asta quello che sostiene essere 4 TB di dati rubati, inclusi codice sorgente, credenziali e configurazioni VPN.

Perché questo caso è più importante del solito CVE

Vediamo advisory sulla supply chain abbastanza spesso da cominciare a confonderli tra loro. Questo è diverso per alcune ragioni.

Prima di tutto, il vettore d'attacco. La compromissione non è partita da LiteLLM stesso, ma da Trivy, uno scanner open-source per le vulnerabilità che molti team eseguono all'interno delle proprie pipeline CI/CD. Pensaci un momento: lo strumento che usi per cercare vulnerabilità era il punto d'ingresso. Il tuo stesso tooling di sicurezza ha compromesso la tua sicurezza. Non è solo ironico: è un promemoria che le pipeline CI/CD sono un target ad alto valore e ogni strumento che vi gira dentro richiede lo stesso livello di scrutinio che applicheresti alle dipendenze di produzione.

In secondo luogo, la posizione di LiteLLM nello stack. È un'interfaccia unificata per chiamare LLM di diversi provider, il che significa che di solito ha accesso alle chiavi API di ogni provider AI che utilizzi, oltre alle variabili d'ambiente e alle credenziali cloud presenti nello stesso contesto. Compromettere un pacchetto in quella posizione offre agli attaccanti una scorciatoia verso tutto.

In terzo luogo, il raggio d'azione verso valle. LiteLLM non viene solo installato direttamente: è una dipendenza transitiva inclusa da framework per agenti AI, server MCP e strumenti di orchestrazione LLM. Team che non hanno mai sentito parlare di LiteLLM potrebbero averlo eseguito comunque nei loro job CI.

Quello che continuiamo a vedere nel nostro lavoro

Durante gli engagement di penetration testing per studi di sviluppo di videogiochi, una delle prime cose che analizziamo è la pipeline CI/CD. È costantemente il bersaglio più vulnerabile. I team investono molto in firewall, WAF e monitoraggio a runtime, ma la pipeline di build spesso gira con permessi eccessivamente ampi, scarica dipendenze senza fissarle e registra nei log segreti che farebbero venire i brividi.

Abbiamo riscontrato schemi simili sviluppando applicazioni cloud-native per clienti enterprise con requisiti di compliance stringenti. Gli ambienti regolatori svizzeri, ad esempio, richiedono di dimostrare il controllo sulla propria software supply chain. Non è solo un esercizio di spunta su una checklist: significa sapere esattamente quale versione di ogni dipendenza si sta eseguendo, quando è stata pubblicata e quali checksum corrispondono. I team che avevano già questa disciplina in atto erano quelli meno esposti a questo attacco.

Nei nostri progetti iOS e Android nativi, storicamente siamo stati un po' più isolati da questo tipo di problemi, perché gli ecosistemi Apple e Google dispongono di strumenti di build più centralizzati. Ma il panorama sta cambiando. Sempre più team mobile stanno integrando strumenti di generazione del codice AI e funzionalità basate su LLM nelle loro app, il che significa che il tooling basato su Python si sta insinuando in pipeline di build che non l'avevano mai avuto prima. Se stai eseguendo preprocessing AI/ML come parte della tua build mobile, controlla il tuo albero delle dipendenze.

Cosa dovresti fare concretamente

Ecco i passi concreti da seguire. Alcuni puoi iniziare a farli oggi stesso.

Fissa le tue dipendenze. Non solo in requirements.txt, ma ovunque: Dockerfile, configurazioni CI, GitHub Actions. Usa l'hash-pinning dove il tuo package manager lo supporta. Il fatto che il 40-50% delle installazioni di LiteLLM scaricasse l'ultima versione a ogni esecuzione è la causa principale del motivo per cui una finestra di 40 minuti ha colpito così tanti ambienti.

Verifica se sei stato esposto. Se hai installato o aggiornato LiteLLM tramite pip il 24 marzo tra le 10:39 e le 16:00 UTC, controlla la presenza delle versioni 1.82.7 o 1.82.8. Esegui pip show litellm in ogni ambiente. Cerca ~/.config/sysmon/sysmon.py e pod sospetti in Kubernetes con nomi corrispondenti a node-setup-*. LiteLLM e diverse aziende di sicurezza hanno pubblicato script di scansione. Usali.

Ruota le credenziali in modo aggressivo. Se trovi qualsiasi segnale di compromissione, considera bruciate tutte le credenziali su quella macchina: chiavi SSH, token cloud, password di database, chiavi API nei file .env. Rimuovere semplicemente il pacchetto non è sufficiente, perché il malware è stato progettato per stabilire persistenza e potrebbe aver già distribuito payload aggiuntivi.

Usa i cooldown sulle dipendenze. PyPI sta introducendo i «relative dependency cooldown» in pip v26.1 (attesi questo mese), che consentono di configurare pip per installare solo i pacchetti pubblicati da un periodo minimo di tempo. Non ti protegge da tutto, ma avrebbe impedito l'installazione automatica di un pacchetto attivo da soli 40 minuti. Puoi già impostare cooldown assoluti in pip v26.0 con il flag --uploaded-prior-to.

Verifica i permessi dei tuoi strumenti CI/CD. Il tuo scanner per le vulnerabilità, il tuo linter, il tuo test runner: girano tutti con i permessi della tua pipeline. Se la pipeline può fare push in produzione, può farlo anche uno scanner compromesso. Applica il principio del minimo privilegio a ogni step.

La scomoda verità su tooling AI e supply chain

Ecco cosa continua a tornarmi in mente su questo caso. Lo stack di sviluppo AI è giovane, in rapida evoluzione e tenuto insieme da un numero relativamente ristretto di pacchetti open source da cui tutti dipendono: LiteLLM, LangChain, vari framework per agenti. Questi progetti si muovono velocemente, rilasciano spesso e sono mantenuti da team piccoli. Non è una critica: è semplicemente la realtà di dove ci troviamo.

Il 2026 State of DevOps Modernization Report ha rilevato che quasi un quarto dei deployment richiede remediation, con tempi medi superiori alle 7,5 ore. Aggiungi codice generato dall'AI e dipendenze gestite dall'AI a questo mix, e ottieni una supply chain che si espande più rapidamente di quanto la maggior parte dei team riesca ad auditare.

Dal nostro lavoro PHP e Docker con clienti enterprise, sappiamo che la disciplina sulla supply chain è noiosa. Non fa notizia. Nessuno vuole spendere uno sprint a stringere i pin delle dipendenze e a rivedere i permessi CI. Ma i team che lo fanno sono quelli che dormono tranquilli durante incidenti come questo, invece di dover ruotare freneticamente ogni credenziale in loro possesso.

Se qualcosa di tutto questo suona fastidiosamente familiare, o se non sei sicuro che la tua pipeline CI/CD sopravvivrebbe a questo tipo di attacco, parliamone. Facciamo security review che coprono specificamente le pipeline di build e la gestione delle dipendenze, non solo il perimetro di produzione, e portiamo la nostra esperienza di sviluppo per capire cosa è davvero praticabile per il tuo team.