In sintesi
Il 24 marzo 2026 il gruppo di attaccanti noto come TeamPCP (UNC6780) ha compromesso le versioni 1.82.7 e 1.82.8 di LiteLLM su PyPI, dopo aver violato lo scanner Trivy di Aqua Security, che custodiva credenziali di pubblicazione PyPI usate dalla pipeline CI di LiteLLM. I pacchetti compromessi sono rimasti online per circa 40 minuti. La società di threat intelligence CloudSEK ha pubblicato l'11 agosto la mappa completa dell'esposizione: oltre 2.500 organizzazioni e circa 434.000 pipeline CI/CD potenzialmente coinvolte. Già a luglio 2026 un avviso FLASH dell'FBI segnalava che le credenziali rubate potevano non essere state ruotate e restavano utilizzabili per attacchi successivi.
Alla vulnerabilità è stato assegnato l'identificativo CVE-2026-33634 (CVSS critico), inserito nel catalogo Known Exploited Vulnerabilities della CISA il 26 marzo 2026. Se il vostro team ha usato LiteLLM in una pipeline di build nella finestra del 24 marzo e non ha ancora ruotato tutti i segreti collegati, l'esposizione non è risolta.
Come Trivy è diventato il punto di ingresso
L'attacco ha sfruttato un singolo token mai revocato, nascosto tre livelli più in profondità in una catena di dipendenze open source. TeamPCP ha prima compromesso lo scanner di vulnerabilità Trivy di Aqua Security il 19 marzo 2026, ottenendo accesso a un token PyPI che la pipeline CI di LiteLLM usava per i rilasci automatici. Quando il sistema di build di LiteLLM ha eseguito Trivy nel normale workflow di rilascio, lo scanner compromesso ha iniettato codice malevolo nel pacchetto in uscita.
Il risultato sono state le versioni 1.82.7 e 1.82.8 di LiteLLM, pubblicate su PyPI il 24 marzo. Entrambe contenevano un file chiamato litellm_init.pth, che Python carica automaticamente tramite il meccanismo dei file .pth all'avvio di qualsiasi processo Python: il raccoglitore di credenziali veniva quindi eseguito anche se LiteLLM non era mai importato direttamente. I pacchetti malevoli sono rimasti disponibili per circa 40 minuti (all'incirca dalle 10:39 alle 16:00 UTC) prima che PyPI li rimuovesse.
Lo schema dell'attacco dice molto sul rischio CI/CD di oggi. Il bersaglio non era LiteLLM in sé, ma uno strumento di sicurezza di cui LiteLLM si fidava implicitamente e le cui credenziali non erano mai state limitate alla sola lettura o a una durata ridotta. Un solo token non ruotato nella pipeline di rilascio di uno scanner si è trasformato, nel giro di un'ora, in un pacchetto avvelenato distribuito a un numero imprecisato di sistemi di build a valle.
Cosa rivela il report CloudSEK
Nell'analisi dell'11 agosto 2026 CloudSEK ha ricostruito l'esposizione esaminando circa 434.000 file recuperati dall'infrastruttura degli attaccanti. Oltre 2.500 organizzazioni sono classificate come corrispondenze ad alta confidenza: i loro ambienti di build mostrano segni di installazione dei rilasci compromessi durante la finestra attiva.
Tra le organizzazioni citate nel dataset ad alta confidenza figurano NVIDIA, Amazon Web Services, Cisco Systems, Samsung Electronics, Salesforce, Deloitte, Siemens, S&P Global, ServiceNow, Vodafone, Volkswagen, FedEx, Thales, Zscaler e il London Stock Exchange Group. L'ampiezza dell'elenco riflette quanto LiteLLM sia diffuso come libreria di gateway IA in settori che vanno dal SaaS enterprise alle infrastrutture logistiche.
Un'avvertenza importante del report CloudSEK: la cifra di oltre 2.500 descrive un'esposizione ricostruita, non una compromissione confermata. Le pipeline CI/CD installano e memorizzano in cache i pacchetti in modo diverso, e l'effetto concreto dipende dall'avvio effettivo di un processo Python nella finestra, dai segreti accessibili in quell'ambiente e dalla raggiungibilità del dominio degli attaccanti. I team dovrebbero analizzare i propri log di build invece di attendere una notifica ufficiale.
Cosa è stato sottratto e perché conta ancora
Il raccoglitore in litellm_init.pth puntava a un ampio insieme di credenziali e stato dell'ambiente: chiavi API cloud, inclusi token OpenAI e Anthropic, access key e secret key AWS, credenziali Azure, token di service account GCP, token ServiceAccount di Kubernetes, chiavi SSH private, password di database e variabili d'ambiente catturate all'avvio del processo Python. Tutti i dati venivano esfiltrati verso un dominio controllato da TeamPCP – models.litellm[.]cloud –, che imitava un endpoint legittimo di LiteLLM.
L'avviso dell'FBI di luglio 2026 è rilevante perché la rotazione delle credenziali dopo un incidente di supply chain è più lenta e meno completa di quanto dovrebbe. I segreti incorporati in container già distribuiti, conservati in secret manager CI/CD senza rotazione automatica o condivisi tra più servizi sfuggono spesso alle attività di incident response. L'avviso sottolinea che le chiavi API dei provider di IA – OpenAI, Anthropic e simili – comportano un rischio particolare: possono essere usate in silenzio per frodi sui costi di inferenza o per iniettare output malevoli in workflow basati sull'IA, senza far scattare i segnali tradizionali di rilevamento delle intrusioni.
Secondo CloudSEK, TeamPCP ha usato anche un'infrastruttura successiva – repository GitHub e GitLab chiamati tpcp-docs o docs-tpcp – per il command-and-control continuativo. Alcuni ambienti compromessi potrebbero quindi avere un meccanismo di persistenza attivo, sopravvissuto al furto iniziale di credenziali.
Cosa significa per il mercato italiano
In Italia i gateway LLM come LiteLLM compaiono sempre più spesso nei progetti di IA generativa di banche, assicurazioni, PMI manifatturiere e system integrator, perché permettono di usare più provider dietro un'unica interfaccia e di instradare i dati sensibili verso modelli ospitati in cloud europei o on-premise. Proprio perché nasce spesso come progetto pilota di un team data, il gateway rischia di restare fuori dall'inventario degli asset e dalla distinta dei componenti software (SBOM): è il punto cieco che rende urgente una verifica degli ambienti di build, anche per chi non compare nell'elenco di CloudSEK.
Per i team che sviluppano prodotti basati sull'IA, l'incidente LiteLLM mostra una classe di rischio che cresce man mano che le librerie di IA diventano infrastruttura di base: la catena di fiducia di un pacchetto Python comprende ogni strumento della pipeline di rilascio del suo editore, non solo il pacchetto stesso. LiteLLM non ha scritto il codice malevolo. Il suo sistema di build ha scaricato automaticamente una dipendenza compromessa, esattamente come era progettato per fare. L'attacco è riuscito proprio perché l'automazione ha funzionato come previsto.
In pratica, l'audit delle dipendenze deve andare oltre le dipendenze dirette e il loro grafo transitivo. Gli strumenti di build – scanner, formatter, linter, test runner – che detengono credenziali di pubblicazione o girano con accesso ai segreti richiedono le stesse regole di rotazione e di minimo privilegio dei segreti applicativi. Un token di Trivy in grado di pubblicare su PyPI non dovrebbe esistere; se proprio serve, deve essere circoscritto, a scadenza e ruotato con una frequenza più breve del tempo in cui un attaccante può restare inosservato.
Sul piano normativo, i soggetti che rientrano nel perimetro NIS2 – recepita in Italia con il D.Lgs. 138/2024, con l'Agenzia per la Cybersicurezza Nazionale (ACN) come autorità di riferimento – dovrebbero valutare l'incidente rispetto agli obblighi di notifica: la direttiva prevede una preallerta entro 24 ore dalla conoscenza di un incidente significativo. Banche, assicurazioni e altre entità finanziarie sono inoltre soggette a DORA per la gestione degli incidenti ICT e del rischio legato ai fornitori terzi. Se le variabili d'ambiente esfiltrate davano accesso a dati personali, va valutata anche la notifica al Garante per la protezione dei dati personali entro 72 ore prevista dal GDPR. Chi scopre solo ora, grazie al report di agosto, l'esposizione di marzo dovrebbe chiarire le tempistiche con l'ufficio legale e la funzione compliance.
Per le aziende FinTech e HealthTech in particolare: una chiave API di IA rubata da una pipeline di build che gestiva anche dati sanitari o variabili d'ambiente dei sistemi di pagamento crea un rischio composto. La chiave OpenAI o Anthropic in sé può valere poco, ma il dump di variabili d'ambiente con cui è stata sottratta potrebbe contenere password dei database di produzione o credenziali di servizi in ambito PCI DSS.
Piano di bonifica in tre passi
Se la vostra organizzazione usa LiteLLM e non ha ancora completato una revisione post-incidente, date priorità a queste tre azioni:
1. Verificare i log di build nella finestra di esposizione. Cercate nei log degli artefatti della vostra piattaforma CI/CD le installazioni di litellm==1.82.7 o litellm==1.82.8 del 24 marzo 2026, tra le 10:39 e le 16:00 UTC circa. Se la pipeline usa la cache, controllate anche se versioni memorizzate in quella finestra siano state riutilizzate in build successive.
2. Ruotare tutti i segreti accessibili alle pipeline coinvolte. Rientrano qui le chiavi API dei cloud provider (AWS, Azure, GCP), le chiavi API dei provider di IA (OpenAI, Anthropic e qualsiasi altro provider le cui credenziali fossero nelle variabili d'ambiente), i token ServiceAccount di Kubernetes, le chiavi SSH del runner di build e le password di database accessibili all'ambiente di build. Non limitate la rotazione ai segreti che ritenete usati direttamente: ruotate tutto ciò che era alla portata del processo Python.
3. Cercare indicatori di persistenza. Cercate nelle vostre organizzazioni GitHub e GitLab riferimenti ai repository tpcp-docs o docs-tpcp. Analizzate i log di rete dei runner di build alla ricerca di connessioni in uscita verso models.litellm.cloud a partire dal 24 marzo. Se trovate uno di questi indicatori, considerate l'ambiente di build potenzialmente ancora compromesso e attivate le risorse di incident response.
Domande frequenti
Quali versioni di LiteLLM sono state colpite?
Le versioni 1.82.7 e 1.82.8 di LiteLLM pubblicate su PyPI il 24 marzo 2026 contenevano una backdoor. Entrambe sono state rimosse. Qualsiasi build che le abbia installate durante la finestra di circa 40 minuti (all'incirca dalle 10:39 alle 16:00 UTC) potrebbe aver subito la raccolta delle credenziali. Controllate i log delle pipeline per quella data e quella fascia UTC.
Come hanno avuto accesso gli attaccanti alla pipeline di LiteLLM?
TeamPCP ha prima compromesso Trivy, uno scanner di sicurezza open source molto diffuso di Aqua Security, il 19 marzo 2026, ottenendo una credenziale di pubblicazione PyPI che la pipeline CI di LiteLLM usava per i rilasci automatici. Gli attaccanti hanno inserito un file malevolo (litellm_init.pth) eseguito automaticamente all'avvio di Python, senza import diretto di LiteLLM.
Quali credenziali sono state rubate?
La backdoor raccoglieva chiavi API cloud (OpenAI, Anthropic, AWS, Azure, GCP), token ServiceAccount di Kubernetes, chiavi SSH, password di database e variabili d'ambiente, tutto inviato a un dominio controllato dagli attaccanti. Qualsiasi segreto accessibile a un processo Python che eseguiva i pacchetti colpiti durante la finestra di esposizione va considerato compromesso.
Perché conta ancora ad agosto 2026?
A luglio 2026 l'FBI ha diffuso un avviso FLASH secondo cui le credenziali rubate potrebbero non essere state ruotate e restano utilizzabili. Il report CloudSEK dell'11 agosto ha confermato che alcune corrispondenze ad alta confidenza non avevano riconosciuto pubblicamente l'incidente. Il rischio di credenziali attive persiste per le organizzazioni che non hanno completato la bonifica da marzo.
Cosa fare se il team usava LiteLLM a marzo 2026?
Tre passi: (1) verificare nei log delle pipeline le installazioni di litellm==1.82.7 o litellm==1.82.8 del 24 marzo (UTC); (2) ruotare tutti i segreti accessibili a quegli ambienti di build: chiavi cloud, token Kubernetes, chiavi SSH, password di database; (3) cercare nei repository riferimenti a tpcp-docs o docs-tpcp e controllare i log dei runner per connessioni in uscita verso models.litellm.cloud.
Fonti
SecurityWeek — Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack, agosto 2026
The Hacker News — Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations, agosto 2026
CloudSEK — 2,500+ Companies and 434,000 CI/CD Pipelines Exposed (fonte primaria), 11 agosto 2026