La campagna TeamPCP ha colpito tra marzo e aprile 2026 gli strumenti DevSecOps e i gateway AI più diffusi, compromettendo GitHub Actions di Trivy e Checkmarx e pubblicando versioni malevole del pacchetto Python LiteLLM su PyPI. Il dossier indica un volume stimato di un terabyte di credenziali sottratte, con oltre 434.000 pipeline CI/CD potenzialmente esposte e più di 2.500 organizzazioni interessate dal caso LiteLLM. La novità non è solo la scala, ma la scelta del bersaglio: i gateway AI concentrano token di accesso a multiple infrastrutture cloud, trasformando un singolo compromesso in un moltiplicatore di impatto senza precedenti nella supply chain tradizionale.
- Tra il 19 e il 20 marzo 2026, i tag di trivy-action e setup-trivy sono stati spostati verso commit malevoli: il nome della dipendenza restava invariato, ma il workflow eseguiva codice diverso.
- Il 24 marzo 2026 sono apparse su PyPI le versioni 1.82.7 e 1.82.8 di LiteLLM, un gateway tra applicazioni e provider di modelli linguistici, potenzialmente ricco di token cloud e segreti infrastruttura AI.
- Il payload simulava il comportamento normale dello scanner Trivy: le pipeline producevano risultati corretti mentre i dati venivano esfiltrati da chiavi SSH, token cloud, credenziali Kubernetes e file .env.
- La compromissione iniziale dell'ambiente CI/CD di Aqua Security è avvenuta tramite credenziali non completamente revocate durante una precedente rotazione.
Il vettore: quando il CI/CD diventa porta d'ingresso
Secondo il dossier, l'attacco è iniziato dall'ambiente CI/CD di Aqua Security, produttrice di Trivy. Gli aggressori avrebbero sfruttato credenziali non completamente revocate durante una precedente rotazione, ottenendo token GitHub con privilegi sufficienti per modificare i riferimenti usati dalle GitHub Actions. Tra il 19 e il 20 marzo 2026, diversi tag di trivy-action e setup-trivy furono spostati verso commit contenenti codice malevolo.
La tecnica è insidiosa perché invisibile alla dichiarazione di dipendenza: "il nome della dipendenza restava invariato, ma il workflow eseguiva un contenuto diverso da quello atteso", come riporta IlSoftware.it. Il codice malevolo cercava attivamente segreti disponibili sul runner, tra cui chiavi SSH, token cloud, credenziali Kubernetes e file .env. Una parte del codice simulava il comportamento normale dello scanner, così la pipeline poteva produrre risultati corretti mentre i dati venivano esfiltrati.
La propagazione: da Trivy a LiteLLM, l'economia della supply chain AI
La campagna non si è arrestata ai soli strumenti DevSecOps. Il 23 marzo 2026 sono state colpite le GitHub Actions di Checkmarx KICS e AST; il giorno successivo, il 24 marzo 2026, sono comparse su PyPI le versioni malevole 1.82.7 e 1.82.8 di LiteLLM. Questo pacchetto funziona come gateway tra applicazioni e provider di modelli linguistici, posizione che lo rende potenzialmente ricco di token cloud e segreti infrastruttura AI.
L'espansione della campagna è avvenuta tramite le credenziali rubate per ottenere accesso ad altri repository. Il meccanismo è lineare: un compromesso iniziale genera credenziali, le credenziali generano accessi secondari, gli accessi secondari generano nuovi compromessi. La differenza rispetto alle supply chain tradizionali sta nella natura del gateway AI: un singolo pacchetto come LiteLLM può contenere token per multiple infrastrutture cloud e modelli linguistici, elevando il rendimento dell'attacco rispetto alla compromissione di una libreria generica.
"Un attacco supply chain può trasformare un componente affidabile in un punto di raccolta per credenziali, chiavi API e token di autenticazione" — IlSoftware.it
La scala: 434.000 pipeline e il limite della stima
Una ricerca di CloudSEK ha ricostruito oltre 434.000 pipeline CI/CD potenzialmente esposte e più di 2.500 organizzazioni interessate dal caso LiteLLM. Il volume stimato di credenziali rubate è indicato come "un terabyte". Entrambi i numeri derivano da una sola fonte editoriale e non sono corroborati indipendentemente: la metodologia di stima delle pipeline non è descritta, e non è chiaro se il terabyte si riferisca a credenziali in chiaro, criptate o dati aggregati. Il dossier non specifica inoltre quante organizzazioni siano state effettivamente compromesse rispetto a quelle "potenzialmente esposte".
La fonte CloudSEK, citata da IlSoftware.it, non è linkata né verificabile indipendentemente nel dossier disponibile. Questo costituisce un limite significativo: i numeri sono presentati come stime di una società di threat intelligence, ma il lettore non può accedere al rapporto originale per valutarne la metodologia.
Perché è importante
Il brief non documenta misure correttive specifiche né raccomandazioni operative dettagliate dalla fonte primaria. Ciò che il dossier rende evidente, tuttavia, è la persistenza del problema: "rimuovere il pacchetto infetto non basta. Una credenziale copiata durante l'esecuzione può restare valida dopo la pulizia del runner", come riporta IlSoftware.it. Questa dinamica rende la rimozione del codice malevolo insufficiente a chiudere l'incidente.
Il caso LiteLLM mostra inoltre come i gateway AI si siano trasformati in target ad alto valore. La loro funzione architetturale — mediating layer tra applicazioni e multiple provider LLM — li rende concentratori di privilegi che i tradizionali strumenti DevSecOps non erano. La supply chain AI non è più un'estensione della supply chain software, ma un moltiplicatore di impatto con caratteristiche proprie.
Il dossier non specifica la natura dei dati effettivamente esfiltrati oltre alle categorie generiche (chiavi SSH, token cloud, credenziali Kubernetes, file .env). Non è chiaro se il terabyte di credenziali riguardi solo questa campagna o operazioni aggregate di TeamPCP. Non emergono dettagli su come sia stata determinata l'attribuzione al gruppo, né se Aqua Security abbia confermato pubblicamente la compromissione iniziale del proprio CI/CD. Mancano informazioni su eventuali risposte legali o indicizzazioni.
Domande e risposte
Quali versioni di LiteLLM sono compromesse?
Secondo il dossier, le versioni malevole pubblicate su PyPI sono la 1.82.7 e la 1.82.8, apparse il 24 marzo 2026. IlSoftware.it non riporta quali versioni successive siano state pubblicate per sostituirle.
Come funzionava l'evasione nel payload di Trivy?
Il codice malevolo simulava il comportamento normale dello scanner: le pipeline completavano l'esecuzione con risultati apparentemente corretti, mascherando l'esfiltrazione in corso. Questa tecnica riduce la probabilità di rilevamento da parte di monitoraggi basati sul fallimento del workflow.
Il dossier indica chi ha scoperto la campagna?
IlSoftware.it cita CloudSEK come fonte della stima su pipeline e organizzazioni esposte, ma non fornisce link al rapporto originale né indica se la scoperta tecnica della compromissione sia attribuibile a CloudSEK o ad altri ricercatori.
Fonti
- https://www.ilsoftware.it/pacchetto-ai-compromesso-porta-al-furto-di-un-terabyte-di-credenziali/
- https://www.securityinfo.it/2026/05/11/falso-repository-openai-su-hugging-face-distribuisce-malware/
- https://www.tomshw.it/hardware/shai-hulud-colpisce-pypi-segreti-rubati-parte-python
- https://meteoraweb.com/news/hugging-face-conferma-violazione-con-furto-di-dataset-interni-e-credenziali
- https://www.bleepingcomputer.com/news/security/new-shai-hulud-attack-trojanizes-19-science-focused-pypi-packages/
- https://thehackernews.com/2026/05/fake-openai-privacy-filter-repo-hits-1.html?utm_source=chatgpt.com
- https://www.ilsoftware.it/focus/eseguire-le-applicazioni-piu-delicate-con-diritti-amministrativi-ridotti_2816/
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.