Il gruppo threat actor TeamPCP ha compromesso la pipeline CI di LiteLLM nel marzo 2026, iniettando versioni malevole del popolare proxy server Python tramite un scanner Trivy compromesso. La finestra di esposizione su PyPI è stata di circa 40 minuti, secondo quanto ricostruisce CloudSEK, vendor di cybersecurity che ha divulgato pubblicamente l'incidente l'11 agosto 2026. La portata stimata — 2.500+ organizzazioni e 434.000 pipeline CI/CD potenzialmente esposte — illustra come l'automazione delle supply chain moderne abbia compresso il tempo di propagazione a zero: ciò che una volta richiedeva giorni ora avviene nel tempo di un commit.
- TeamPCP ha compromesso il scanner Trivy nella CI pipeline di LiteLLM per circa 20 giorni, sfruttando un token non revocato per iniettare il payload nel build system
- Le versioni malevole 1.82.7 e 1.82.8 sono state pubblicate su PyPI per circa 40 minuti; il payload usava file .pth per esecuzione automatica all'avvio di Python
- Il malware SANDCLOCK, tracciato da Google, raccoglieva credenziali cloud, chiavi AI provider, token Kubernetes e secret CI/CD da /proc/<pid>/mem
- Le stime di CloudSEK descrivono esposizione ricostruita, non conferma di compromissione: le 2.500+ aziende e 434.000 pipeline sono potenzialmente a rischio, non verificatamente violate
Da Trivy a PyPI: la catena a cascata
L'attacco ha seguito una catena di tre compromissioni concatenate, come ricostruisce CloudSEK. Il vettore iniziale era il token di un account CI non revocato, che ha permesso a TeamPCP di compromettere il scanner Trivy — tool di vulnerability scanning ampiamente usato nelle pipeline — per circa 20 giorni. Da lì, il build system di LiteLLM ha automaticamente installato la versione corrotta dello scanner, permettendo l'iniezione del payload nelle release del progetto.
Il risultato: le versioni 1.82.7 e 1.82.8 del pacchetto Python, disponibili su PyPI per circa 40 minuti prima della rimozione. Il payload utilizzava file .pth — meccanismo di inizializzazione Python che esegue codice automaticamente all'avvio dell'interprete senza richiedere import esplicito — per attivare il malware SANDCLOCK sui sistemi che installavano o aggiornavano LiteLLM in quella finestra temporale.
"Trivy, then the [LiteLLM] build system, then the LiteLLM release: one unrevoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure." — CloudSEK
SANDCLOCK: l'infostealer che legge la memoria dei processi
Una volta attivo, SANDCLOCK escalava a privilegi root e raccoglieva credenziali direttamente dalla memoria dei processi, inclusi i valori che GitHub Actions tenta di mascherare, estraendoli da /proc/<pid>/mem. Il malware era configurato per raccogliere chiavi AWS, GCP e Azure, token Kubernetes, credenziali di pubblicazione pacchetti, chiavi SSH, e chiavi API di provider AI e LLM.
L'esfiltrazione avveniva con crittografia AES-256 sotto chiave RSA-4096 hardcoded, diretta verso un dominio typosquatted. In caso di fallimento della comunicazione, il malware creava un repository pubblico all'interno dell'account GitHub della vittima e caricava i dati rubati come asset di release — una tecnica che sfrutta l'infrastruttura della vittima stessa per bypassare i controlli di egress.
Il metodo di raccolta dalla memoria processo è particolarmente rilevante per le pipeline CI/CD: i secret iniettati come variabili d'ambiente, anche quelli marcati come masked dai sistemi di orchestrazione, restano leggibili nello spazio di memoria del processo che li utilizza. SANDCLOCK sfruttava proprio questa caratteristica architetturale.
Il dataset esposizione: numeri e organizzazioni
CloudSEK ha ricostruito un dataset di esposizione che include nomi di alto profilo enterprise: AWS, Samsung, Cisco, ServiceNow, S&P Global, X Corp, Zscaler, NVIDIA, Salesforce, Volkswagen, Orange, Thales, LSEG, Roche, Airbus, Siemens, Vodafone, Epic Games, Krungthai Bank. Per alcune di queste, il report riporta dati quantitativi specifici: Cisco con 327 secret e 1.900 run; S&P Global con 1.218 secret e 1.108 run; X Corp con 3.459 secret e 1.153 run; Orange con 180 secret e 5.642 run.
CloudSEK ha esplicitamente qualificato queste cifre: "The 2,500+ company and 434,000 pipeline figures describe reconstructed exposure. They should not be read as proof that every listed organization was successfully compromised or that every credential was stolen." L'attribuzione a TeamPCP è ricostruita da CloudSEK, senza conferma indipendente dalle fonti disponibili.
L'FBI ha emesso un FLASH advisory (FLASH-20260702-01) a luglio 2026, secondo quanto riporta CloudSEK, con avviso che attori affiliati a TeamPCP sono probabilmente in grado di weaponizzare le credenziali raccolte. Questo dettaglio non è verificabilmente confermato dalle fonti indipendenti nel dossier.
Quaranta minuti, cinque mesi di persistenza
La struttura dell'incidente rivela un pattern che distingue gli attacchi supply chain moderni dai worm tradizionali come Conficker o Slammer. Dove i worm del 2000-2010 erano rumorosi, rilevabili e scalavano in tempo reale, la compromissione di LiteLLM è stata silenziosa, contenuta in una finestra di 40 minuti, e ha generato un payload — credenziali valide — che persiste come rischio per mesi.
"Forty minutes was the theft. Five months later, the FBI is still warning that the stolen credentials will be weaponized." — Jacob Krell, Suzu Labs
Come ha notato Seemant Sehgal di BreachLock: "The malicious packages were live for 40 minutes, but the window mattered to defenders long after it mattered to the attacker." L'automazione CI/CD ha eliminato il tempo di reazione: le pipeline che dipendono da installazioni automatiche hanno consumato il pacchetto malevolo prima che qualsiasi processo umano potesse intervenire. Le credenziali raccolte, se non ruotate, restano valide indipendentemente dalla rimozione del pacchetto.
Perché è importante
Il dossier non specifica misure correttive specifiche indicate dalla fonte primaria. CloudSEK non ha rilasciato indicazioni operative dettagliate nel report tecnico disponibile, e le fonti secondarie non aggiungono checklist di mitigazione verificabili indipendentemente.
La fonte non specifica se le organizzazioni elencate nel dataset abbiano ricevuto notifica diretta, né documenta un processo di coordinamento con i vendor di sicurezza coinvolti. Il brief non elenca patch management, rotazione automatica credenziali, o monitoring specifico come azioni raccomandate dalla fonte stessa.
Il dossier non chiarisce la timeline esatta dell'attacco iniziale a Trivy (marzo 2026 è indicativo), né fornisce il numero effettivo di organizzazioni realmente compromesse rispetto a quelle esposte. Non emergono sovrapposizioni infrastrutturali che colleghino TeamPCP ad altri gruppi threat actor allo stato attuale. L'entità delle perdite economiche o dei danni concreti non è documentata.
Il vero perimetro è diventato l'infrastruttura AI
L'incidente LiteLLM non è una compromissione di un modello LLM, ma dell'infrastruttura che lo serve. I gateway LLM, i server MCP, le chiavi provider sono diventati obiettivi ad alto valore non per i dati che contengono direttamente, ma per l'accesso che aprono: cloud, dati sensibili, sistemi di azione automatizzata. La catena Trivy → build → PyPI mostra come la sicurezza delle AI infrastructure dipenda dalla sicurezza della toolchain che la precede di tre gradi.
La distinzione tra esposizione e compromissione reale è il limite metodologico centrale di questo report. CloudSEK ha ricostruito la superficie d'attacco, non verificato l'impatto. Per le organizzazioni nel dataset, questo significa che il rischio va verificato internamente, non assunto o escluso sulla base delle stime esterne.
FAQ
Che differenza c'è tra esposizione e compromissione confermata?
Il dataset CloudSEK ricostruisce quali pipeline avrebbero potuto scaricare le versioni malevoli, non quali l'hanno effettivamente fatto o quali credenziali siano state effettivamente esfiltrate. Le cifre di 2.500+ organizzazioni e 434.000 pipeline descrivono esposizione potenziale, non compromissione verificata.
Perché 40 minuti su PyPI sono stati sufficienti?
Le pipeline CI/CD automatizzate installano dipendenze senza intervento umano. Una finestra di 40 minuti copre interamente i cicli di build automatici di molte organizzazioni. La rimozione rapida del pacchetto non annulla le installazioni già avvenute.
Cosa sappiamo dell'attribuzione a TeamPCP?
L'attribuzione al gruppo TeamPCP è ricostruita da CloudSEK nel suo report tecnico. Non emergono conferme indipendenti da fonti primarie multiple nel dossier disponibile.
Fonti
- https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines
- https://itnerd.blog/2026/08/11/2500-organisations-and-434000-ci-cd-pipelines-potentially-exposed-in-the-largest-ai-supply-chain-breach-of-2026/
- https://www.cxtoday.com/security-privacy-compliance/supply-chain-attack-exposes-2500-companies-in-largest-ai-infrastructure-breach-of-2026-so-far/
- https://www.finopotamus.com/post/2-500-organisations-and-434-000-ci-cd-pipelines-potentially-exposed-in-the-largest-ai-supply-chain
- https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/
- https://en.cryptonomist.ch/2026/08/11/ai-supply-chain-breach-2026/
- https://podcast.securityweek.com/
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.