TeamPCP avvelena LiteLLM su PyPI: 40 minuti di pacchetto…

Il gruppo TeamPCP ha compromesso il pacchetto Python LiteLLM in marzo 2026, distribuendo versioni malevole per circa 40 minuti attraverso un ingresso nel CI/CD

{"main_topic":"cybersecurity","topics":["cybersecurity","ai-infrastructure","supply-chain","malware","python"]}

Il gruppo TeamPCP ha compromesso il pacchetto Python LiteLLM in marzo 2026, distribuendo versioni malevole per circa 40 minuti attraverso un ingresso nel CI/CD upstream. L'attacco ha convertito uno strumento di sicurezza in vettore di infezione e ha generato un'esposizione potenziale di oltre 2.500 organizzazioni e quasi 434.000 pipeline, secondo il report originale di CloudSEK. Il caso conferma che l'infrastruttura AI è diventata attack surface strategica e che la rimozione di un pacchetto non chiude l'incidente se le credenziali rimangono attive.

Punti chiave

Le versioni malevole 1.82.7 e 1.82.8 di LiteLLM sono state pubblicate su PyPI nel marzo 2026 per circa 40 minuti, con propagazione automatica via file .pth senza richiesta di import esplicito.
L'ingresso nel sistema è avvenuto attraverso il security scanner Trivy, compromesso tramite un token di automazione leaked e non revocato, con una finestra di circa 20 giorni prima del rilascio avvelenato.
Il malware SANDCLOCK, tracciato da Google secondo CloudSEK, ha escalato a root e letto segreti direttamente da /proc/<pid>/mem, inclusi i valori che GitHub Actions tenta di mascherare.
L'esposizione potenziale riguarda oltre 2.500 organizzazioni e circa 434.000 pipeline CI/CD; l'FBI ha emesso nel luglio 2026 il FLASH-20260702-01 sulla possibile weaponization delle credenziali raccolte.

Come un security scanner è diventato il vettore

L'attacco non ha colpito direttamente l'account PyPI del mantainer di LiteLLM. Secondo quanto documentato da CloudSEK e ripreso da Cryptonomist, il punto di ingresso è stato il Trivy security scanner integrato nella pipeline CI/CD del progetto. Gli aggressori hanno sfruttato un token di automazione leaked che, pur essendo stato rotato, non era stato completamente revocato. Questa lacuna ha lasciato una finestra di circa 20 giorni durante la quale il sistema di build era controllato dall'esterno.

Il rilascio delle versioni 1.82.7 e 1.82.8 è avvenuto nel marzo 2026. Il codice malevolo veniva eseguito attraverso un file .pth, un meccanismo di Python che permette l'esecuzione automatica all'avvio dell'interprete senza che l'utente effettuasse un import esplicito del pacchetto compromesso. Questo dettaglio architetturale ha esteso la superficie di attacco ben oltre i contesti in cui LiteLLM veniva importato direttamente: qualsiasi ambiente Python che caricasse il path di installazione era esposto.

La persistenza e l'occultamento erano progettate per sfruttare la fiducia implicita che gli sviluppatori ripongono nei security scanner. Il principio dello "shift-left" — spostare la verifica di sicurezza il più a monte possibile nel ciclo di sviluppo — è stato qui invertito: lo strumento di verifica è diventato il canale di contaminazione.

SANDCLOCK: dall'esecuzione all'esfiltrazione

Una volta attivato, il malware identificato come SANDCLOCK ha operato in più fasi. Secondo il report CloudSEK, il payload ha escalato i privilegi fino a root e ha letto i segreti di sistema direttamente dalla memoria dei processi attraverso /proc/<pid>/mem. Questa tecnica bypassa le protezioni di mascheramento implementate da GitHub Actions: i valori che la piattaforma tenta di occultare nei log risultano visibili quando estratti a livello kernel.

I dati targetati comprendevano cloud keys, repository tokens, SSH keys, Kubernetes secrets, package publishing credentials, environment variables e AI provider keys. L'esfiltrazione avveniva con un doppio meccanismo: i dati venivano cifrati con AES-256 sotto una chiave RSA-4096 hardcoded e inviati verso un dominio typosquatted. In caso di fallimento del canale principale, il malware creava un repository pubblico all'interno dell'account GitHub della vittima e caricava i dati rubati come release asset — una tecnica di fallback che sfrutta la stessa piattaforma compromessa per l'occultamento.

"Removal does not end the incident. A package can disappear in minutes while copied credentials remain usable for weeks or months unless they are rotated and downstream activity is investigated." — CloudSEK report originale

Il dataset CloudSEK: tra esposizione e compromissione

CloudSEK ha ricostruito un dataset che associa l'esposizione potenziale a oltre 2.500 organizzazioni e circa 434.000 pipeline CI/CD. La lista delle organizzazioni con match ad alta confidenza include NVIDIA, AWS, Samsung, Cisco, ServiceNow, S&P Global, X Corp, Zscaler, Volkswagen, Thales e London Stock Exchange Group. I numeri specifici di secrets ricostruiti nel dataset sono: 153 per NVIDIA Corporation, 1.218 per S&P Global, 3.459 per X Corp e 5.642 runs per Orange S.A.

La fonte stessa impone una calibrazione rigorosa di questi dati. Il report originale afferma esplicitamente che le cifre di 2.500+ aziende e 434.000 pipeline "descrivono esposizione ricostruita" e "non devono essere lette come prova che ogni organizzazione elencata sia stata compromessa con successo o che ogni credenziale sia stata rubata". La distinzione tra esposizione potenziale e compromissione verificata è centrale: un match ad alta confidenza indica che l'organizzazione era nel perimetro di esposizione, non che ha subito esfiltrazione o uso malevolo confermato.

CloudSEK raccomanda che un match ad alta confidenza attivi "validazione privata, notifica, review delle credenziali e investigazione dei log", specificando che la formulazione pubblica deve restare su "potentially exposed" a meno che esecuzione malevola, esfiltrazione, accesso non autorizzato o uso a valle non siano stati verificati indipendentemente.

La post-incidente: credenziali attive e advisory FBI

Il report CloudSEK cita l'FBI FLASH-20260702-01 del luglio 2026, secondo cui "affiliated actors are likely to weaponize the harvested credentials long after the original intrusion". Questo elemento, sebbene non verificabile indipendentemente dalle fonti disponibili, introduce una temporalità critica: la rimozione dei pacchetti malevoli da PyPI non ha eliminato il rischio, poiché le credenziali copiate durante la finestra di esposizione restano valide fino alla rotazione esplicita.

Il gap tra la durata del pacchetto su PyPI (circa 40 minuti secondo la fonte) e la persistenza del rischio credenziale (settimane o mesi) definisce la struttura del danno. Le pipeline CI/CD sono progettate per velocità di esecuzione, non per isolamento post-compromissione. L'automazione che rende efficiente il software development diventa qui il moltiplicatore dell'impatto.

CloudSEK ha un conflitto di interesse dichiarato nella promozione del proprio strumento AIVigil per la verifica dell'esposizione; questo elemento va considerato nella valutazione del report, che resta tuttavia la fonte primaria e più dettagliata disponibile sull'incidente.

Cosa fare adesso

Per le organizzazioni che utilizzano LiteLLM o che operano nel perimetro di esposizione ricostruito, le azioni prioritarie sono:

Verificare l'esposizione tramite il tool CloudSEK all'indirizzo exposure.cloudsek.com e confrontare i risultati con i log interni di installazione pacchetti PyPI nel marzo 2026.
Ruotare tutte le credenziali potenzialmente accessibili non solo quelle specifiche di LiteLLM, inclusi cloud keys, repository tokens, Kubernetes secrets e AI provider keys, indipendentemente dall'evidenza di uso malevolo.
Investigare i log di accesso e le release GitHub per identificare repository pubblici creati automaticamente o asset sospetti che potrebbero indicare attivazione del meccanismo di fallback.
Trattare l'infrastruttura AI come attack surface strategica con controlli di integrità sui security scanner integrati nel CI/CD e verifica della revoca completa dei token, non solo della rotazione.

Perché questo attacco ridefinisce la supply chain AI

La durata breve dell'esposizione — circa 40 minuti — non ha impedito la creazione di un dataset di potenziale impatto enterprise-wide. Questa asimmetria tra velocità di attacco e velocità di risposta è il dato strutturale del caso. Il 2026 ha già visto supply chain attack su pacchetti software, ma il targeting esplicito dell'infrastruttura AI, con la sua concentrazione di credenziali ad alto valore per provider di modelli e piattaforme di deployment, segna un cambio di strategia nei gruppi di minaccia.

La conversione di Trivy da scanner di sicurezza a vettore di ingresso è il dettaglio più significativo per gli operatori. Non si tratta di una vulnerabilità nel codice dello scanner, ma di una compromissione del contesto operativo in cui lo scanner esegue — una distinzione che rende più difficile la protezione basata su firme e più necessaria la segmentazione del CI/CD.

L'incidente misura anche la distanza tra la cultura della disclosure di sicurezza e la realtà delle pipeline automatiche. CloudSEK ha pubblicato dettagli tecnici sostanziali, ma l'assenza di advisory strutturati da parte del vendor o di enti come ZDI/GHSL lascia un vuoto nel percorso di remediazione standardizzato. Le organizzazioni devono navigare tra esposizione ricostruita e compromissione verificata senza il supporto di CVE o bollettini ufficiali — un pattern che si ripeterà man mano che la supply chain AI diventa bersaglio prioritario.

Domande frequenti

Cos'è un file .pth e perché è pericoloso in questo contesto?

Un file .pth in Python definisce path aggiuntivi per la ricerca dei moduli e può contenere codice eseguito automaticamente all'avvio dell'interprete. Nel caso LiteLLM, questo ha permesso l'esecuzione del malware senza che l'utente importasse esplicitamente il pacchetto compromesso, estendendo la superficie di attacco a qualsiasi operazione Python nell'ambiente infetto.

Qual è la differenza tra "potentially exposed" e "compromised" nel dataset CloudSEK?

"Potentially exposed" indica che l'organizzazione era nel perimetro di installazione delle versioni malevole secondo la ricostruzione di CloudSEK. "Compromised" richiederebbe evidenza di esfiltrazione, uso malevolo delle credenziali o accesso non autorizzato verificato — condizioni che la fonte non attribuisce automaticamente alle 2.500+ entità elencate.

Perché l'FBI FLASH del luglio 2026 è rilevante se l'attacco è del marzo 2026?

L'advisory segnala che le credenziali raccolte possono essere weaponizzate da attori affiliati anche mesi dopo l'intrusione originale. Questo allunga la finestra di rischio oltre la breve durata della disponibilità del pacchetto malevolo su PyPI, rendendo la rotazione credenziale prioritaria indipendentemente dalla data dell'incidente iniziale.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti