TeamPCP/UNC6780: sei breach enterprise da Trivy a LiteLLM

L'analisi si basa su dati Hudson Rock — non verificabili indipendentemente — e sulla timeline tecnica di SOCRadar. Il 19 marzo 2026 TeamPCP, gruppo tracciato da Google Mandiant come UNC6780, ha force-pushed i tag di Trivy verso commit malevoli. Cinque giorni dopo, versioni avvelenate di LiteLLM sono approdate su PyPI. Secondo Hudson Rock, sei breach enterprise ne sono derivati, con un arco di esposizione che SOCRadar quantifica al 95% prima ancora della pubblicazione su repository pubblico.

Come uno scanner è diventato il punto di ingresso

Nei giorni 27-28 febbraio 2026, TeamPCP ha sfruttato la direttiva pull_request_target nel workflow GitHub Actions di Trivy per infiltrarsi nella pipeline CI. Il 1 marzo Aqua Security ha ruotato le credenziali compromesse, ma l'operazione non è stata atomica: token residui sono rimasti validi.

Il 19 marzo alle 17:43 UTC, gli attaccanti hanno force-pushed 76 dei 77 tag di trivy-action e tutti e 7 i tag di setup-trivy verso commit malevoli. Quattro minuti dopo, alle 17:47 UTC, Trivy 0.69.4 è stato costruito e pubblicato. Versioni successive (0.69.5 e 0.69.6) sono arrivate su Docker Hub il 22 marzo.

LiteLLM, che nei propri workflow installava Trivy senza pinning di versione, ha incorporato lo scanner compromesso. Il 24 marzo alle 10:39 UTC, la versione 1.82.7 è salita su PyPI; alle 10:52 UTC è seguita la 1.82.8, con l'aggiunta di litellm_init.pth. Questo hook di startup Python ha eliminato il requisito di importazione: il payload si attivava automaticamente all'avvio dell'interprete.

PyPI ha messo in quarantena entrambe le release intorno alle 11:19 UTC, circa 40 minuti dopo la prima pubblicazione. Secondo SOCRadar, il 95% delle organizzazioni esposte era già stata raggiunta nei cinque giorni precedenti.

"Il 95% delle organizzazioni interessate era già esposto prima del 24 marzo, quando i pacchetti sono andati live. I 40 minuti su PyPI hanno chiuso una corsa di raccolta che durava già da cinque giorni." — SOCRadar

Il payload e la superficie di attacco

Il malware raccoglieva chiavi cloud, token SSH, credenziali Kubernetes, password di database, secret da file .env e chiavi per provider AI — tra cui OPENAI_API_KEY e ANTHROPIC_API_KEY. L'esfiltrazione puntava al dominio models.litellm[.]cloud, controllato dagli attaccanti.

LiteLLM riceve circa 3,4 milioni di download al giorno. Le cifre di esposizione ricostruita convergono tra SOCRadar, CloudSEK (via The Hacker News) e SecurityWeek: circa 434 mila file CI catturati e oltre 2.500 organizzazioni. CloudSEK ha qualificato questi numeri come "esposizione ricostruita, non conteggio di vittime confermate".

Hudson Rock, dalla propria piattaforma Cavalier, ha ottenuto un archivio RAR di 153 GB con 433.909 file e 118.829 dump CI attribuiti a 2.488 domini aziendali.

Sei breach, sei profili di impatto diverso

Hudson Rock ha analizzato sei casi con dettagli specifici, segnalando che "queste violazioni sono state estremamente difficili da evitare. Le organizzazioni colpite non sono in colpa". Le specifiche tecniche che seguono riportano le affermazioni di Hudson Rock, non conferme indipendenti delle organizzazioni coinvolte.

Guesty: secondo Hudson Rock, 700 GB di dati estorti, 4 milioni di email inviate e ricevute, dati di integrazione con Airbnb e Booking.com. Il gruppo ransomware Vect ha elencato l'azienda sul proprio leak site.

S&P Global: secondo Hudson Rock, 250 GB esfiltrati, migliaia di secret inclusi token GitHub, JWT e chiavi private RSA. Anche qui, Vect ha rivendicato l'attacco.

Cisco: secondo Hudson Rock, codice sorgente rubato dal repository cisco-it-cloud-infrastructure tramite container Trivy avvelenato; esposti GitHub PAT, token Artifactory e chiave API Conjur.

European Commission: secondo Hudson Rock, credenziali AWS IAM, chiave SSH privata hardcoded e token GitLab CI compromessi. CERT-EU ha valutato con alta confidenza la compromissione dell'account AWS e quantificato in circa 91,7 GB (compressi) i dati esfiltrati.

Mercor: secondo Hudson Rock, circa 4 TB estratti in totale, di cui 939 GB di codice sorgente proprietario. SSN e dati biometrici di oltre 40.000 contractor esposti. Meta ha sospeso il contratto di condivisione dati con l'azienda; sono state avviate cause collettive. Lapsus$ ha dichiarato di aver venduto i dati Mercor a imprese cinesi, una rivendicazione che resta non verificabile indipendentemente.

Telnyx: versioni malevole 4.87.1 e 4.87.2 del SDK Python pubblicate su PyPI il 27 marzo 2026. Esposte configurazioni Docker con credenziali in base64 e GitHub PAT. Telnyx ha dichiarato che piattaforma, API e dati cliente non sono stati compromessi.

Cosa fare adesso

Le azioni seguenti si limitano a quanto documentato nelle fonti primarie.

Verificare la presenza di versioni compromesse: controllare nei log di build l'installazione di LiteLLM 1.82.7 o 1.82.8, Trivy 0.69.4-0.69.6, o Telnyx SDK 4.87.1/4.87.2. Il record CVE-2026-33634 elenca i CPE affetti nel database NVD.

Controllare esfiltrazioni note: il dominio models.litellm[.]cloud è documentato come destinazione di esfiltrazione. La sua presenza nei log di rete indica contatto con l'infrastruttura degli attaccanti.

Valutare l'esposizione CI/CD: SOCRadar ha rilevato che il 95% dell'esposizione è avvenuto prima della finestra PyPI del 24 marzo. Le organizzazioni con pipeline che installavano Trivy senza pinning di versione nei giorni 19-24 marzo 2026 hanno rischio documentato di compromissione.

Considerare i limiti delle fonti: i dettagli di breach specifici (volumi di dati, categorie di secret) provengono da Hudson Rock, piattaforma single-vendor con dati non verificabili indipendentemente. Le cifre di esposizione ricostruita (2.500+ organizzazioni, 434K file) non equivalgono a conteggio di vittime confermate.

Il dettaglio che cambia la lettura

Il gap di 13 minuti tra le due release PyPI è il dettaglio tecnico più rilevante. La versione 1.82.7 richiedeva che un'applicazione importasse LiteLLM per attivare il payload. La 1.82.8 ha aggiunto litellm_init.pth, eliminando anche questo requisito. Come ha notato SOCRadar, "i 13 minuti tra le due release sono il dettaglio da tenere a mente".

Questa evoluzione all'interno della stessa finestra di pubblicazione indica che gli attaccanti stavano ottimizzando la superficie di attacco in tempo reale, non distribuendo un payload statico.

La campagna TeamPCP/UNC6780 non ha richiesto vulnerabilità zero-day nel codice sorgente di LiteLLM, ma l'inserimento di un artefatto malevolo in una pipeline già compromessa. La distinzione è rilevante per la valutazione del rischio: il punto di fallimento era il processo di build, non il design del gateway AI.

Fonti: Hudson Rock/Infostealers.com; SOCRadar; The Hacker News/CloudSEK; SecurityWeek; NVD CVE-2026-33634; Mandiant/Google Cloud Community.

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

Fonti

• https://www.infostealers.com/article/from-ci-pipeline-to-ransomware-breaches-6-high-profile-breaches-in-the-litellm-trivy-attack/
• https://www.infostealers.com/article/largest-ai-supply-chain-breach-of-2026-litellm-hack-impacts-thousands-of-global-enterprises-claim-your-ethical-disclosure/
• https://socradar.io/blog/litellm-supply-chain-attack/
• https://malware.news/t/from-ci-pipeline-to-ransomware-breaches-6-high-profile-breaches-in-the-litellm-triv-attack/124842
• https://nvd.nist.gov/vuln/detail/CVE-2026-33634
• https://security.googlecloudcommunity.com/community-blog-42/protecting-customers-in-record-time-google-security-operations-and-mandiant-s-response-to-the-axios-npm-supply-chain-attack-7321
• https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
• https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/