Attacco alla supply chain tramite Trivy e LiteLLM: protezione della pipeline CI/CD da CVE-2026-33634

Milioni di pipeline di sviluppo software automatizzate si basano su strumenti di sicurezza, come Trivy e Checkmarx AST, integrati nel processo di compilazione. E sono state proprio queste soluzioni affidabili a diventare di recente il punto di ingresso per uno dei più grandi e pericolosi attacchi alla supply chain della storia moderna. In questo post verrà illustrato come controllare i flussi di lavoro automatizzati e proteggere l’infrastruttura cloud aziendale.

Sequenza temporale dell’attacco e conseguenze note

Il 19 marzo è stato effettuato un attacco mirato alla supply chain tramite Trivy, uno strumento open source di scansione delle vulnerabilità ampiamente utilizzato nelle pipeline CI/CD. Gli autori degli attacchi, un gruppo noto come TeamPCP, sono riusciti a iniettare malware nei flussi di lavoro ufficiali di GitHub Actions e nelle immagini Docker associate a Trivy. Di conseguenza, ogni scansione automatizzata della pipeline ha provocato l’attivazione di malware in grado di rubare chiavi SSH, token di accesso al cloud, portafogli di criptovaluta e altri dati preziosi dai sistemi compromessi. Data la natura critica dell’incidente, gli è stato assegnato l’identificatore CVE-2026-33634, con un punteggio CVSS4B quasi massimo di 9,4.

Più tardi, lo stesso giorno, il team di Trivy ha rilevato l’attacco e rimosso gli artefatti dannosi dai canali di distribuzione, arrestando questa fase dell’attacco. Tuttavia, gli autori degli attacchi avevano già ottenuto l’accesso agli ambienti di molti utenti Trivy.

Il 23 marzo è stato rilevato un incidente simile in un altro strumento di protezione dell’applicazione: un’azione GitHub per Checkmarx KICS, nonché Checkmarx AST. Tre ore dopo, anche il codice dannoso è stato rimosso da lì. TeamPCP è anche riuscito a compromettere le estensioni OpenVSX supportate da Checkmarx: cx-dev-assist 1.7.0 e ast-results. I rapporti sul momento in cui questa parte dell’incidente è stata risolta variano.

Il 24 marzo è stato attaccato un popolare progetto che utilizzava la scansione dei codici di Trivy, il gateway LiteLLM AI, una libreria universale per l’accesso a vari provider LLM. Le versioni 1.82.7 e 1.82.8, caricate nell’archivio PyPI, sono state compromesse. Queste versioni sono rimaste disponibili al pubblico per circa cinque ore.

Ma il fatto che l’attacco sia durato solo poche ore non è un motivo per ignorarlo. Data la popolarità dei progetti interessati, il codice dannoso potrebbe essere stato eseguito migliaia di volte, anche all’interno dell’infrastruttura di aziende di grandi dimensioni.

Ciò ha consentito agli utenti malintenzionati di distribuire backdoor persistenti nei cluster Kubernetes, nonché di avviare CanisterWorm auto-replicante nell’ecosistema JavaScript npm.

Il codice degli autori dell’attacco ha capacità distruttive che spazzano via un cluster Kubernetes e tutti i relativi nodi se rileva il fuso orario di Teheran o il farsi come lingua primaria nel sistema compromesso. In altre regioni, il malware ruba semplicemente i dati utilizzando CanisterWorm.

Secondo gli esperti, più di 20.000 archivi sono considerati potenzialmente vulnerabili. Gli autori degli attacchi affermano di aver rubato centinaia di gigabyte di dati e più di mezzo milione di account.

In che modo è stato attaccato Trivy

Per compromettere Trivy, gli autori dell’attacco hanno utilizzato le credenziali rubate in un incidente precedente. La precedente compromissione di Trivy , avvenuta a fine febbraio, probabilmente non era stata completamente contenuta e gli autori dell’attacco, lo stesso gruppo TeamPCP, sono tornati con un nuovo attacco. Gli sviluppatori di Trivy, Aqua Security, ipotizzano che, poiché le credenziali venivano gradualmente eliminate in seguito all’incidente precedente, gli autori dell’attacco siano stati in grado di generare nuovi token di accesso prima che quelli vecchi compromessi venissero revocati.

In seguito a questa operazione, TeamPCP è stato in grado di compromettere le azioni GitHub utilizzate nelle pipeline CI/CD. Utilizzando le credenziali con privilegi di scrittura tag, gli autori dell’attacco hanno forzato l’override di 76 tag di versione su 77 in aquasecurity/trivy-action e tutti e sette i tag in aquasecurity/setup-trivy, reindirizzando le versioni attendibili esistenti a commit dannosi. Analogamente alle tattiche osservate nella campagna Shai-Hulud 2.0. Di conseguenza, i flussi di lavoro della pipeline hanno iniziato a eseguire il codice degli autori dell’attacco, mentre i metadati della versione non hanno mostrato modifiche visibili.

Allo stesso tempo, gli autori dell’attacco hanno pubblicato un file binario Trivy (v0.69.4) infetto nei canali di distribuzione ufficiali, inclusi i rilasci di GitHub e i registri dei contenitori.

Compromissione LiteLLM

La compromissione del popolare strumento di accesso per modelli linguistici LiteLLM potrebbe innescare di per sé una grave ondata di attacchi lungo la catena di progetti che lo utilizzano. L’attacco ha avuto luogo il 24 marzo 2026, quando TeamPCP ha pubblicato direttamente versioni dannose della libreria (1.82.7 e 1.82.8) su PyPI. Tra le 10:39 UTC e le 16:00 UTC, questi pacchetti compromessi contenevano malware che rubava le credenziali. Era incorporato nel file proxy_server.py e la versione 1.82.8 conteneva anche un contenitore litellm_init dannoso. I dati rubati sono stati esfiltrati nel server models.litellm[.]cloud.

I clienti che utilizzavano LiteLLM Cloud o l’immagine Docker proxy LiteLLM ufficiale non sono stati interessati dal blocco rigoroso delle versioni, mentre gli sviluppatori e i progetti a valle che hanno installato versioni sbloccate tramite pip durante l’intervallo di tempo specificato sono stati compromessi.

Entro tre ore i pacchetti dannosi sono stati rimossi dall’archivio PyPI e il team di LiteLLM ha sospeso le nuove versioni, ruotato le credenziali e avviato un processo esterno di risposta agli incidenti. È consigliabile che i team che utilizzano LiteLLM nei propri progetti controllino immediatamente la presenza dell’indicatore di compromissione litellm_init.pth e ruotino periodicamente tutti i secret potenzialmente compromessi.

Funzionalità del malware TeamPCP Cloud Stealer

Gli utenti malintenzionati hanno aggiunto una nuova logica a GitHub Actions e all’eseguibile Trivy mantenendo la funzionalità originale. I risultati della scansione delle vulnerabilità tramite Trivy sembravano normali, ma allo stesso tempo venivano ricercati ed estratti dati preziosi. Il codice dannoso stava eseguendo le seguenti operazioni:

• esecuzione di ricognizioni (raccolta di dati di rete e variabili di ambiente);
• ricerca di token e credenziali per accedere agli ambienti cloud AWS e GCP;
• scansione della memoria (/proc/*/mem ) per estrarre i segreti archiviati nella memoria dei processi Runner.Worker e Runner.Listener;
• estrazione dei secret Kubernetes (/run/secrets/kubernetes.io/serviceaccount);
• raccolta dei dati per la connessione ai server di database (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• raccolta di eventuali altre chiavi API e secret dai file di ambiente e dai file di configurazione CI/CD (.env, .json, .yml);
• ricerca di webhook per i canali Slack e Discord;
• ricerca di dati relativi ai portafogli criptati (variabili relative alla blockchain di Solana, nonché ai dati rpcuser e rpcpassword).

I dati raccolti sono stati sottoposti a criptaggio dei dati e caricati su un server con un nome simile a quello degli sviluppatori di Trivy (scan.aquasecurtiy[.] org). Come meccanismo di backup, gli autori dell’attacco hanno fornito un metodo per caricare i dati in un archivio denominato docs-tpcp.

L’attacco a CheckMarx e LiteLLM ha utilizzato una tattica simile con altri domini di typosquatting: models.litellm[.]cloud e checkmarx[.]zone.

Un’analisi tecnica dettagliata del malware, insieme agli indicatori di compromissione, è disponibile nell’articolo del nostro esperto sul blog Securelist.

Strategie di risposta e di difesa per CVE-2026-33634

I controlli basati sulle firme esistenti e la scansione delle dipendenze nei registri pubblici non sono più sufficienti, poiché il codice dannoso è stato iniettato direttamente nelle azioni attendibili e firmate ed è sfuggito al rilevamento fino all’applicazione del monitoraggio comportamentale. Le pipeline CI/CD sono diventate il “nuovo perimetro” della sicurezza.

Azioni immediate. Verifica che tutti i flussi di lavoro utilizzino versioni protette (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).

Gli amministratori della pipeline CI/CD e i team di sicurezza devono esaminare immediatamente le proprie dipendenze dalle soluzioni Checkmarx (kics-github-action, ast-github-action) e Trivy (setup-trivy e trivy-action). Se i flussi di lavoro fanno riferimento a un tag di versione anziché a un hash SHA specifico, esamina attentamente i registri di esecuzione del flusso di lavoro per la durata dell’attacco attivo alla supply chain.

È inoltre necessario verificare la presenza di traffico verso i domini scan.aquasecurtiy[.] nei registri di rete org, checkmarx[.]zone e models.litellm[.]cloud. La presenza di tale traffico indica che i dati sensibili sono stati esfiltrati correttamente.

Se un archivio denominato docs-tpcp è apparso nel GitHub dell’organizzazione, ciò potrebbe anche indicare una violazione dei dati riuscita.

Controlla host e cluster per individuare segni di compromissione: presenza di file ~/.config/sysmon/sysmon.py pod sospetti in Kubernetes.

Svuota la cache ed esegui un inventario dei moduli PyPI: verifica la presenza di quelli dannosi ed esegui il rollback alle versioni pulite.

In ogni caso, è necessario condurre una ricerca proattiva delle minacce, presupponendo che i sistemi siano stati compromessi e che gli utenti malintenzionati siano avanzati rapidamente all’interno dei sistemi interessati.

È consigliabile ripristinare gli ambienti interessati dai backup verificati.

Pinning delle dipendenze e gestione dei secret. Verifica che le versioni esatte delle dipendenze vengano aggiunte tramite hash di criptaggio in tutte le pipeline e nei Dockerfile. È consigliabile passare dai token di lunga durata alle credenziali di breve durata utilizzando uno strumento di gestione dei secret e implementando le integrazioni OIDC, qualora supportate. Riduci al minimo l’inserimento di secret nell’ambiente di runtime: solo quando è assolutamente necessario. Verifica che i secret non vengano archiviati su disco o in file temporanei e non vengano riutilizzati in processi diversi.

Ruota tutte le credenziali potenzialmente compromesse: chiavi API, variabili di ambiente, chiavi SSH, token dell’account di servizio Kubernetes e altri secret.

Altre soluzioni di sicurezza Consenti solo azioni GitHub da un elenco approvato dall’organizzazione; blocca i processi nuovi e non verificati. Configura GITHUB_TOKEN e altre chiavi di accesso in base al principio del privilegio minimo. Non concedere le autorizzazioni di scrittura a meno che non sia assolutamente necessario.

Per migliorare la sicurezza delle azioni GitHub, sono disponibili diversi strumenti open source:

• zizmor — uno strumento per l’analisi statica e il rilevamento degli errori di configurazione nelle azioni GitHub;
• gato e Gato-X — due versioni di uno strumento che aiuta a identificare le condotte strutturalmente vulnerabili;
• allstar — un’applicazione GitHub, sviluppata da OpenSSF, per configurare e applicare i criteri di sicurezza nelle organizzazioni e negli archivi GitHub.

Per saperne di più sugli attacchi alla supply chain, ti invitiamo a consultare il nostro rapporto analitico Reazione della supply chain: proteggere l’ecosistema digitale globale in un’era di interdipendenza. Si basa sugli approfondimenti di esperti tecnici e rivela con quale frequenza le organizzazioni affrontano rischi nella supply chain e nelle relazioni di fiducia, dove permangono lacune nella protezione e quali strategie adottare per migliorare la resilienza a questo tipo di minacce.