Il 24 marzo 2026 due versioni della libreria Python LiteLLM sono rimaste pubblicate su PyPI per appena 40 minuti, dalle 10:39 UTC. È bastato per innescare quella che i ricercatori di sicurezza descrivono ora, ad agosto, come una delle violazioni della supply chain AI più estese mai documentate: oltre 2.500 organizzazioni coinvolte, circa 434.000 pipeline CI/CD potenzialmente esposte e un archivio da 153 GB di credenziali rubate finito online a metà agosto. Per un pacchetto scaricato più di 95 milioni di volte al mese, quaranta minuti sono bastati a innescare cinque mesi di conseguenze a catena.
Il caso LiteLLM non è un incidente isolato. È il primo grande attacco alla supply chain a colpire in pieno l’infrastruttura che smista il traffico verso i modelli linguistici di aziende e sviluppatori in tutto il mondo, Italia compresa. Ricostruiamo cosa è successo, chi c’è dietro, quali versioni sono a rischio e cosa cambia per chi gestisce pipeline CI/CD in Europa.
Che cos’è LiteLLM e perché conta così tanto
LiteLLM è un gateway AI open source sviluppato da BerriAI. Funziona da proxy unico verso oltre 100 provider di modelli linguistici, traducendo le chiamate in un formato compatibile con le API OpenAI. Migliaia di aziende lo integrano nei backend di produzione e, soprattutto, nelle pipeline CI/CD, dove gestisce chiavi API, token cloud e variabili d’ambiente. Con oltre 95 milioni di download mensili su PyPI, secondo i dati raccolti da Cyberpress, è diventato uno dei componenti più diffusi nello stack AI moderno.
Questa diffusione è esattamente ciò che rende il pacchetto un bersaglio prezioso. Un gateway che smista traffico verso decine di provider vede passare, per definizione, credenziali sensibili: chiavi OpenAI, Anthropic, Azure OpenAI, token AWS e Google Cloud, segreti di database. Compromettere LiteLLM non significa colpire un’app isolata, significa infilarsi nel punto di snodo di intere infrastrutture AI.
Cronologia dell’attacco: da Trivy a PyPI in 40 minuti
Le indagini forensi condotte da Snyk, Trend Micro e Cycode, riprese da Cyberpress, mostrano che LiteLLM non era il bersaglio iniziale. Gli attaccanti hanno prima compromesso la pipeline GitHub Actions di Trivy, uno scanner di vulnerabilità usato da moltissimi team, incluso quello di LiteLLM nel proprio workflow CI/CD. Da lì hanno ottenuto un accesso legittimo all’ambiente di build di LiteLLM e hanno rubato il token di pubblicazione su PyPI.
Con quel token in mano, il 24 marzo hanno pubblicato due versioni trojanizzate del pacchetto, la 1.82.7 e la 1.82.8. PyPI le ha messe in quarantena dopo circa 40 minuti, ma il tempo di esposizione reale conta poco quando parliamo di pipeline automatizzate: chi ha eseguito un pip install in quella finestra ha scaricato codice malevolo, e le credenziali rubate restano valide ben oltre la rimozione del pacchetto.
Il ruolo di Trivy nella catena di compromissione
Il dettaglio che rende questo attacco diverso dai soliti pacchetti trojanizzati è la catena di fiducia sfruttata. Trivy è uno strumento di sicurezza, pensato per scansionare le dipendenze e trovare vulnerabilità prima che raggiungano la produzione. Usarlo come vettore d’ingresso ribalta esattamente la logica per cui viene adottato. Gli sviluppatori si fidano degli scanner di sicurezza per definizione: pochi controllano il codice di un tool che dovrebbe proteggerli.
TeamPCP, il gruppo già dietro Trivy e KICS
Secondo l’attribuzione di CloudSEK, riportata da Cyberpress nell’articolo su TeamPCP, il gruppo dietro l’attacco a LiteLLM ha una storia pregressa proprio nella compromissione di strumenti di sicurezza open source, inclusi Trivy e KICS. Non è un dettaglio secondario: prendere di mira gli strumenti che gli sviluppatori usano per proteggersi, invece dei loro prodotti finali, è una strategia che moltiplica l’impatto di ogni singola intrusione riuscita.
I numeri della violazione
CloudSEK ha ricostruito la portata reale dell’esposizione partendo dalle versioni compromesse 1.82.7 e 1.82.8. I dati, pubblicati ad agosto e ripresi da Cyberpress, disegnano un quadro molto più ampio di quanto lasciasse pensare la finestra di soli 40 minuti su PyPI.
| Indicatore | Dato | Fonte |
|---|---|---|
| Download mensili di LiteLLM su PyPI | oltre 95 milioni | Cyberpress |
| Organizzazioni potenzialmente coinvolte | oltre 2.500 | CloudSEK |
| Pipeline CI/CD potenzialmente esposte | circa 434.000 | CloudSEK |
| Finestra di esposizione su PyPI | circa 40 minuti | LiteLLM/BerriAI |
| Dimensione dell’archivio di credenziali trapelato | 153 GB | Hudson Rock / Help Net Security |
| File contenuti nell’archivio | 433.909 | Hudson Rock |
| Dump di CI runner nell’archivio | 118.829 | Hudson Rock |
| Domini aziendali collegati ai dati trapelati | 2.488 | Hudson Rock |
Il divario tra i 40 minuti di esposizione iniziale e le 434.000 pipeline potenzialmente coinvolte spiega perché gli esperti parlano di un incidente su scala industriale. Una pipeline compromessa una sola volta continua a esporre segreti finché qualcuno non ruota le credenziali, anche mesi dopo che il pacchetto malevolo è stato rimosso.
L’archivio da 153 GB: cosa hanno trovato i ricercatori
A metà agosto, Hudson Rock ha ottenuto e analizzato un archivio da 153 GB collegato direttamente alla compromissione di LiteLLM. Il report, pubblicato da Help Net Security il 13 agosto 2026, descrive un contenuto di 433.909 file, tra cui 118.829 dump di CI runner riconducibili a 2.488 domini aziendali distinti.
Tra i domini presenti nell’archivio compaiono nomi noti come AWS, Samsung, Cisco e Salesforce, segno della diffusione trasversale di LiteLLM in ambienti enterprise di ogni dimensione. Va precisato un punto importante: la presenza di un dominio nell’archivio indica che credenziali o dati collegati a quel dominio sono stati trovati nei dump, non che l’azienda in questione abbia subito un’intrusione diretta e confermata. Le fonti consultate non elencano aziende italiane per nome, ma la scala globale della fuga e la varietà dei fornitori coinvolti rende plausibile una qualche esposizione anche per organizzazioni europee che usano LiteLLM nelle proprie pipeline.
Le vulnerabilità critiche che hanno aggravato l’incidente
Il breach di marzo non è stato l’unico problema di sicurezza per LiteLLM nel 2026. La Cloud Security Alliance conta tre incidenti critici distinti nel corso dell’anno, tra compromissione della supply chain e vulnerabilità dirette nel codice del gateway. Diverse di queste falle sono state corrette solo con la versione 1.83.7.
| CVE | Tipo | Gravità | Versione con patch |
|---|---|---|---|
| CVE-2026-42208 | SQL injection pre-autenticazione | CVSS 9.3 (critica) | 1.83.7 |
| CVE-2026-42271 | Remote code execution, sfruttata attivamente | Critica | 1.83.7 |
| CVE-2026-35029 | Bypass autorizzazione su /config/update, porta a RCE | Alta | successiva a 1.82.x |
| CVE-2026-49468 | Bypass autenticazione sul gateway | Alta | successiva a 1.82.x |
| CVE-2026-59819 | Divulgazione di informazioni via riferimenti OIDC | Media | successiva a 1.82.x |
La combinazione di CVE-2026-42208 e CVE-2026-42271 è particolarmente rilevante: la prima consente un’iniezione SQL senza autenticazione, la seconda permette l’esecuzione di codice da remoto. Secondo l’analisi tecnica pubblicata da Oligo Security, i ricercatori di Horizon3.ai hanno dimostrato che la catena di sfruttamento è raggiungibile senza credenziali, incatenando più falle in sequenza. Chi non ha ancora aggiornato a 1.83.7 resta esposto indipendentemente dal breach di marzo.
Perché gli aggressori puntano ai gateway AI
Il caso LiteLLM segna un cambio di bersaglio rispetto agli attacchi alla supply chain tradizionali. Un pacchetto npm o PyPI compromesso in passato rubava tipicamente credenziali di sviluppo isolate, magari una singola chiave AWS o un token GitHub. Un gateway AI invece concentra in un solo punto le chiavi di accesso a decine di provider di modelli, oltre ai segreti cloud e alle configurazioni interne dell’intera pipeline di deployment.
Colpire quel punto di snodo produce un ritorno molto più alto per l’attaccante rispetto a colpire un singolo repository. È lo stesso principio economico dietro gli attacchi a strumenti come Trivy o KICS: non si compromette il bersaglio finale, si compromette lo strumento che migliaia di bersagli usano ogni giorno per fidarsi del proprio codice.
Confronto con altri attacchi alla supply chain del 2026
Il breach LiteLLM si inserisce in un anno già denso di incidenti alla catena del software. shattered.io aveva già documentato un attacco alla supply chain via OAuth che aveva colpito 700 aziende. Il confronto tra i due episodi aiuta a inquadrare la specificità del caso LiteLLM.
| Caratteristica | Breach LiteLLM (2026) | Attacco supply chain OAuth (2026) |
|---|---|---|
| Vettore iniziale | Pipeline CI compromessa (Trivy) | Token OAuth di app terze |
| Organizzazioni coinvolte | oltre 2.500 | circa 700 |
| Dato rubato | credenziali cloud, token API, config CI/CD | token di accesso OAuth |
| Settore principale colpito | infrastruttura AI e DevOps | applicazioni SaaS integrate |
| Gruppo attribuito | TeamPCP | non identificato pubblicamente |
Il numero di organizzazioni coinvolte in LiteLLM è quasi quattro volte superiore, ma il paragone più utile riguarda la natura del dato rubato. Un token OAuth apre una singola integrazione, mentre le credenziali sottratte da una pipeline CI/CD compromessa aprono potenzialmente l’intero ambiente cloud di un’organizzazione.
Contesto storico: dalla supply chain tradizionale a quella AI
Gli attacchi alla supply chain del software non sono una novità del 2026. La compromissione di SolarWinds nel 2020 aveva già dimostrato quanto possa essere devastante infettare uno strumento fidato da migliaia di clienti. La falla Log4Shell di fine 2021 aveva mostrato come una singola libreria di logging, integrata quasi ovunque, potesse trasformarsi in un rischio sistemico. La backdoor scoperta in XZ Utils nel 2024 aveva ricordato che perfino i progetti open source più maturi restano vulnerabili quando un singolo maintainer viene compromesso o infiltrato.
Il caso LiteLLM aggiunge un tassello nuovo a questa storia: per la prima volta su questa scala, il bersaglio non è un componente infrastrutturale generico ma un pezzo specifico dello stack AI, quello che smista le chiamate verso i modelli linguistici. Con l’adozione dell’intelligenza artificiale generativa che continua a crescere nelle aziende europee, i gateway come LiteLLM diventano infrastruttura critica quanto un firewall o un database, ma con anni di maturità in meno sul fronte della sicurezza.
Impatto per le aziende italiane ed europee
Per le imprese europee che usano LiteLLM nei propri ambienti CI/CD, il breach ha implicazioni che vanno oltre la semplice patch tecnica. Se tra i dati esfiltrati figurano informazioni personali, le organizzazioni soggette al GDPR devono valutare l’obbligo di notifica al Garante entro 72 ore dalla scoperta di un’esposizione concreta. La direttiva NIS2, che estende gli obblighi di gestione del rischio informatico e segnalazione degli incidenti a una platea più ampia di operatori essenziali e importanti, aggiunge un ulteriore livello di responsabilità per chi gestisce infrastrutture IT critiche, comprese quelle basate su componenti AI di terze parti.
Le fonti consultate non riportano un elenco di aziende italiane colpite per nome. Questo non equivale a dire che il rischio sia assente: significa solo che, al momento della pubblicazione, nessuna violazione confermata è stata attribuita pubblicamente a un’organizzazione italiana specifica. Per i team di sicurezza IT nazionali la priorità resta verificare se LiteLLM 1.82.7 o 1.82.8 sono mai stati installati in un ambiente di build, anche temporaneamente.
La risposta di LiteLLM e BerriAI
BerriAI, l’azienda che sviluppa LiteLLM, ha pubblicato un aggiornamento di sicurezza ufficiale in cui conferma che le versioni 1.82.7 e 1.82.8 sono state pubblicate senza autorizzazione, probabilmente attraverso un account maintainer compromesso, e che l’origine più probabile della compromissione è la dipendenza da Trivy nel workflow di scansione di sicurezza usato in CI/CD.
Nell’immediato, il team ha sospeso le nuove release in attesa di una revisione completa della catena di build e ha raccomandato agli utenti di considerare compromesse le versioni 1.82.7 e 1.82.8, suggerendo un downgrade temporaneo alla 1.82.6. Successivamente ha rilasciato la versione 1.83.0, costruita con una nuova pipeline CI/CD v2 che introduce ambienti isolati, controlli di sicurezza più severi e una separazione più netta tra fase di build e fase di pubblicazione. Le vulnerabilità dirette nel codice, incluse CVE-2026-42208 e CVE-2026-42271, sono state chiuse solo con la versione 1.83.7.
Come proteggersi: linee guida per i team DevSecOps
Chi gestisce pipeline CI/CD con LiteLLM dovrebbe agire su tre fronti: verifica delle versioni installate, rotazione delle credenziali e controllo continuo delle dipendenze usate come strumenti di sicurezza, non solo di quelle applicative.
Comandi utili per verificare la versione installata
pip show litellm
pip install --upgrade litellm==1.83.7
# Verifica nei log di build se sono mai state installate
# le versioni compromesse
grep -R "litellm==1.82.7\|litellm==1.82.8" ./ci-logs/
Oltre all’aggiornamento immediato, le organizzazioni dovrebbero ruotare qualsiasi credenziale cloud, chiave API o token di accesso presente negli ambienti di build che hanno anche solo transitato per le versioni compromesse, indipendentemente dal fatto che sia stata trovata prova concreta di furto. È il tipo di precauzione che pesa poco rispetto al costo di una violazione confermata mesi dopo.
- Aggiornare a LiteLLM 1.83.7 o versione successiva su tutti gli ambienti
- Ruotare le chiavi API dei provider LLM configurate nel gateway
- Ruotare i token cloud (AWS, Azure, GCP) usati nelle pipeline CI/CD interessate
- Attivare lo scanning automatico delle dipendenze anche per gli strumenti di sicurezza stessi
- Isolare i runner CI/CD con permessi minimi e credenziali a scadenza breve
- Verificare i log di build da marzo 2026 in avanti per individuare installazioni delle versioni 1.82.7 o 1.82.8
Previsioni: cosa aspettarsi nei prossimi mesi
Alla luce della scala del breach e della sua natura, ecco cinque sviluppi plausibili per il resto del 2026 e l’inizio del 2027.
- Più controlli sugli strumenti di sicurezza stessi. Dopo che Trivy è stato usato come vettore d’ingresso, è probabile che i team di sicurezza inizino a trattare scanner e linter come dipendenze ad alto rischio, non come componenti fidati per definizione.
- Consolidamento attorno a pipeline di build isolate. Il modello CI/CD v2 adottato da LiteLLM, con ambienti separati per build e pubblicazione, diventerà probabilmente uno standard di riferimento per altri progetti open source ad alta diffusione.
- Nuove segnalazioni di credenziali esposte. Con un archivio da 153 GB già in circolazione, è ragionevole aspettarsi ulteriori report su specifiche aziende i cui segreti compaiono nei dump analizzati da ricercatori come Hudson Rock.
- Maggiore attenzione normativa in Europa. Con la direttiva NIS2 già in fase di applicazione e il Cyber Resilience Act che introduce requisiti di sicurezza per i prodotti con componenti digitali, incidenti come questo rafforzano la pressione su chi distribuisce software AI open source affinché documenti la propria catena di build.
- Altri gateway AI sotto esame. LiteLLM non è l’unico proxy AI ampiamente adottato: è realistico attendersi audit di sicurezza indipendenti su prodotti concorrenti, spinti proprio dal precedente di questo caso.
Domande frequenti
Cos’è esattamente LiteLLM?
È un gateway AI open source sviluppato da BerriAI che instrada le chiamate verso oltre 100 provider di modelli linguistici usando un formato compatibile con le API OpenAI, molto diffuso nelle pipeline CI/CD e nei backend di produzione.
Quali versioni di LiteLLM sono state compromesse nell’attacco alla supply chain?
Le versioni 1.82.7 e 1.82.8, pubblicate su PyPI il 24 marzo 2026 e rimosse dopo circa 40 minuti.
A quale versione devo aggiornare per essere al sicuro?
Alla 1.83.7 o successiva, che chiude sia il problema della supply chain sia le vulnerabilità critiche CVE-2026-42208 e CVE-2026-42271 emerse successivamente.
Le mie credenziali cloud sono state rubate se ho usato LiteLLM nel 2026?
Solo se l’ambiente ha installato le versioni 1.82.7 o 1.82.8 durante la finestra di esposizione o successivamente da una copia in cache. In quel caso è prudente ruotare comunque tutte le credenziali presenti nella pipeline.
LiteLLM è ancora sicuro da usare oggi?
Le versioni aggiornate alla 1.83.7 e successive, costruite con la nuova pipeline CI/CD v2, includono controlli più severi. Come per qualsiasi dipendenza critica, resta comunque necessario monitorare nuovi avvisi di sicurezza.
Quali aziende italiane sono state colpite dal breach?
Le fonti disponibili non elencano aziende italiane per nome. L’archivio trapelato coinvolge 2.488 domini aziendali a livello globale, ma senza una lista pubblica specifica per l’Italia.
Chi è TeamPCP?
È il gruppo a cui CloudSEK ha attribuito l’attacco, già noto per aver compromesso in passato altri strumenti di sicurezza open source come Trivy e KICS.
Come posso verificare se la mia pipeline CI/CD è stata esposta?
Controllare i log di build da marzo 2026 in avanti per individuare installazioni di litellm==1.82.7 o litellm==1.82.8, quindi ruotare le credenziali coinvolte anche in assenza di prove dirette di furto.
Copertura correlata
- Attacco Supply Chain OAuth: 700 Aziende Colpite [2026]
- SBOM e Dependency Scan in Node.js: 12 Step, 40 Min [2026]
- CISA KEV: 7 Falle Aggiunte, 5 Hanno Oltre 15 Anni [2026]
- Zero-Day SonicWall SMA1000: 380 Appliance Esposte [2026]
- OWASP Top 10 2025 vs API Security Top 10: 10 vs 10
- Patch Tuesday: Microsoft Cura 751 CVE, 108 Critici [2026]
