Cosa è successo nella pipeline di build di LiteLLM a marzo

L'intrusione non è cominciata con LiteLLM. TeamPCP ha compromesso per primo lo scanner di sicurezza open source Trivy sfruttando un token di automazione trapelato, ottenendo una finestra di circa 20 giorni all'interno del repository stesso di Trivy prima che qualcuno se ne accorgesse. Durante quella finestra, il gruppo ha forzato l'inserimento di codice malevolo nei tag di versione di Trivy - i marcatori di rilascio specifici a cui puntano i progetti a valle quando importano una dipendenza.

La pipeline di integrazione continua di LiteLLM installava Trivy senza fissarlo a una versione stabile e verificata, quindi ha importato automaticamente la versione avvelenata alla successiva esecuzione della pipeline. Quella singola dipendenza non fissata è stata l'unica apertura di cui TeamPCP aveva bisogno: il codice malevolo è entrato nel processo di build di LiteLLM stesso, e da lì in due pacchetti pubblicati, le versioni 1.82.7 e 1.82.8 di LiteLLM, caricate sul Python Package Index.

La difesa di cui tutti si fidano, e come è stata aggirata

La maggior parte degli sviluppatori preoccupati dai pacchetti PyPI malevoli fa affidamento sul flag --ignore-scripts, che impedisce agli script di installazione di un pacchetto di eseguire codice arbitrario. Il payload di TeamPCP non aveva bisogno di uno script di installazione. Era contenuto in un file .pth, un file di configurazione dei percorsi Python che l'interprete stesso esegue automaticamente all'avvio, a ogni esecuzione, indipendentemente da come il pacchetto sia stato installato. Questo dettaglio progettuale è quello che ogni titolo su questa violazione ha omesso, ed è quello che conta di più per qualsiasi team di ingegneria convinto che --ignore-scripts li proteggesse esattamente da questa classe di attacco.

Una volta in esecuzione, il payload raccoglieva chiavi SSH, credenziali cloud per AWS, Google Cloud e Azure, token Kubernetes, il contenuto dei file .env e chiavi API dei provider di IA da qualsiasi macchina su cui fosse installato il pacchetto avvelenato. I dati rubati venivano cifrati con AES-256 e inviati a un dominio di typosquatting costruito per sembrare una risorsa legittima di LiteLLM o Trivy, oppure caricati direttamente in repository sull'account GitHub della vittima stessa - un dettaglio che permetteva all'operazione di confondersi con la normale attività di sviluppo invece di far scattare un evidente allarme sul traffico in uscita.

2.500 aziende, otto nominate in Europa e un vuoto di cinque mesi

CloudSEK ha pubblicato la propria ricerca l'11 agosto 2026, cinque mesi dopo la compromissione di marzo, identificando oltre 2.500 organizzazioni e circa 434.000 pipeline CI/CD come potenzialmente esposte - quella che l'azienda definisce la più grande violazione della catena di fornitura IA scoperta finora nel 2026. Tra le corrispondenze ad alta affidabilità citate da CloudSEK figurano Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, l'azienda energetica finlandese Fortum Oyj e il riassicuratore Munich Re, che spaziano tra manifattura, telecomunicazioni, ferrovie, finanza e assicurazioni in più giurisdizioni europee.

CloudSEK precisa esplicitamente che comparire nel proprio dataset non è una prova automatica di una violazione riuscita - il riscontro significa che credenziali, domini, repository o infrastruttura collegati a quell'organizzazione sono emersi nei dati raccolti, e ciascuna organizzazione deve condurre una propria indagine per confermare cosa, se qualcosa, sia stato effettivamente sottratto o utilizzato in modo improprio. Ciò che non è in discussione è il vuoto di cinque mesi tra l'intrusione di marzo e la divulgazione di agosto, una finestra durante la quale ognuna delle organizzazioni citate potrebbe aver operato su infrastrutture con credenziali compromesse senza alcun avviso pubblico che la compromissione fosse avvenuta.

Cosa significa per chiunque gestisca strumenti di infrastruttura IA

L'avviso FLASH dell'FBI di luglio 2026 aggiunge un dettaglio scomodo alla cronologia: le credenziali raccolte a marzo sono ancora considerate attive e utilizzabili mesi dopo, e l'agenzia si aspetta che TeamPCP o attori affiliati le sfruttino in future intrusioni non correlate, invece di lasciarle scadere. Per qualsiasi organizzazione che abbia eseguito le versioni 1.82.7 o 1.82.8 di LiteLLM in produzione o in CI durante marzo 2026, la risposta corretta non è attendere una conferma individuale da CloudSEK o LiteLLM - è trattare ogni credenziale che ha toccato quella pipeline di build come compromessa e ruotarla ora, che siano cinque mesi di ritardo o meno.

La lezione strutturale va oltre LiteLLM. Qualsiasi organizzazione che lasci che la propria pipeline CI importi una dipendenza di strumenti di sicurezza, come uno scanner, senza fissarla a una versione verificata, ha la stessa apertura sfruttata qui da TeamPCP, e --ignore-scripts non è la protezione che la maggior parte dei team crede contro un payload consegnato tramite un file .pth. I responsabili della sicurezza europei che gestiscono strumenti di infrastruttura IA costruiti sulla stessa catena di fornitura open source dovrebbero considerare questo caso meno come una vicenda specifica di LiteLLM e più come un'anteprima di come verrà probabilmente consegnata la prossima compromissione di strumenti IA.

Da leggere ora: 141.006 test, tre intrusioni reali  |  Micron: il 2027 sarà più teso del 2026