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\u00f9 grandi e pericolosi attacchi alla supply chain della storia moderna. In questo post verr\u00e0 illustrato come controllare i flussi di lavoro automatizzati e proteggere l\u2019infrastruttura cloud aziendale.<\/p>\n
Il 19 marzo \u00e8 stato effettuato un attacco mirato alla supply chain tramite Trivy, uno strumento open source di scansione delle vulnerabilit\u00e0 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\u2019attivazione 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\u2019incidente, gli \u00e8 stato assegnato l\u2019identificatore CVE-2026-33634<\/a>, con un punteggio CVSS4B quasi massimo di 9,4.<\/p>\n Pi\u00f9 tardi, lo stesso giorno, il team di Trivy ha rilevato l\u2019attacco e rimosso gli artefatti dannosi dai canali di distribuzione, arrestando questa fase dell\u2019attacco. Tuttavia, gli autori degli attacchi avevano gi\u00e0 ottenuto l\u2019accesso agli ambienti di molti utenti Trivy.<\/p>\n Il 23 marzo \u00e8 stato rilevato un incidente simile<\/a> in un altro strumento di protezione dell\u2019applicazione: un\u2019azione GitHub per Checkmarx KICS, nonch\u00e9 Checkmarx AST. Tre ore dopo, anche il codice dannoso \u00e8 stato rimosso da l\u00ec. TeamPCP \u00e8 anche riuscito a compromettere le estensioni OpenVSX<\/a> supportate da Checkmarx: cx-dev-assist<\/em> 1.7.0 e ast-results<\/em>. I rapporti sul momento in cui questa parte dell\u2019incidente \u00e8 stata risolta variano.<\/p>\n Il 24 marzo \u00e8 stato attaccato un popolare progetto che utilizzava la scansione dei codici di Trivy, il gateway LiteLLM AI, una libreria universale per l\u2019accesso a vari provider LLM. Le versioni 1.82.7 e 1.82.8, caricate nell\u2019archivio PyPI, sono state compromesse. Queste versioni sono rimaste disponibili al pubblico per circa cinque ore.<\/p>\n Ma il fatto che l\u2019attacco sia durato solo poche ore non \u00e8 un motivo per ignorarlo. Data la popolarit\u00e0 dei progetti interessati, il codice dannoso potrebbe essere stato eseguito migliaia di volte, anche all\u2019interno dell\u2019infrastruttura di aziende di grandi dimensioni.<\/p>\n Ci\u00f2 ha consentito agli utenti malintenzionati di distribuire backdoor persistenti nei cluster Kubernetes, nonch\u00e9 di avviare CanisterWorm<\/a> auto-replicante nell\u2019ecosistema JavaScript npm.<\/p>\n Il codice degli autori dell\u2019attacco ha capacit\u00e0 distruttive<\/a> 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.<\/p>\n Secondo gli esperti, pi\u00f9 di 20.000 archivi sono considerati potenzialmente vulnerabili. Gli autori degli attacchi affermano di aver rubato centinaia di gigabyte di dati e pi\u00f9 di mezzo milione di account<\/a>.<\/p>\n Per compromettere Trivy, gli autori dell\u2019attacco hanno utilizzato le credenziali rubate in un incidente precedente. La precedente compromissione di Trivy <\/a>, avvenuta a fine febbraio, probabilmente non era stata completamente contenuta e gli autori dell\u2019attacco, lo stesso gruppo TeamPCP, sono tornati con un nuovo attacco. Gli sviluppatori di Trivy, Aqua Security, ipotizzano<\/a> che, poich\u00e9 le credenziali venivano gradualmente eliminate in seguito all\u2019incidente precedente, gli autori dell\u2019attacco siano stati in grado di generare nuovi token di accesso prima che quelli vecchi compromessi venissero revocati.<\/p>\n In seguito a questa operazione, TeamPCP \u00e8 stato in grado di compromettere le azioni GitHub utilizzate nelle pipeline CI\/CD. Utilizzando le credenziali con privilegi di scrittura tag, gli autori dell\u2019attacco hanno forzato l\u2019override 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<\/a>. Di conseguenza, i flussi di lavoro della pipeline hanno iniziato a eseguire il codice degli autori dell\u2019attacco, mentre i metadati della versione non hanno mostrato modifiche visibili.<\/p>\n Allo stesso tempo, gli autori dell\u2019attacco 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.<\/p>\n La compromissione del popolare strumento di accesso per modelli linguistici LiteLLM potrebbe innescare di per s\u00e9 una grave ondata di attacchi lungo la catena di progetti che lo utilizzano. L\u2019attacco 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<\/em> e la versione 1.82.8 conteneva anche un contenitore litellm_init<\/em> dannoso. I dati rubati sono stati esfiltrati nel server models.litellm[.]cloud<\/em>.<\/p>\n I clienti che utilizzavano LiteLLM Cloud o l\u2019immagine 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\u2019intervallo di tempo specificato sono stati compromessi.<\/p>\n Entro tre ore i pacchetti dannosi sono stati rimossi dall\u2019archivio PyPI e il team di LiteLLM ha sospeso le nuove versioni, ruotato le credenziali e avviato un processo esterno di risposta agli incidenti. \u00c8 consigliabile che i team che utilizzano LiteLLM nei propri progetti controllino immediatamente la presenza dell\u2019indicatore di compromissione litellm_init.pth<\/em> e ruotino periodicamente tutti i secret potenzialmente compromessi.<\/p>\n Gli utenti malintenzionati hanno aggiunto una nuova logica a GitHub Actions e all\u2019eseguibile Trivy mantenendo la funzionalit\u00e0 originale. I risultati della scansione delle vulnerabilit\u00e0 tramite Trivy sembravano normali, ma allo stesso tempo venivano ricercati ed estratti dati preziosi. Il codice dannoso stava eseguendo le seguenti operazioni:<\/p>\n 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[.] or<\/em>g). Come meccanismo di backup, gli autori dell\u2019attacco hanno fornito un metodo per caricare i dati in un archivio denominato docs-tpcp<\/em>.<\/p>\n L\u2019attacco a CheckMarx e LiteLLM ha utilizzato una tattica simile con altri domini di typosquatting: models.litellm[.]cloud<\/em> e checkmarx[.]zone<\/em>.<\/p>\n Un\u2019analisi tecnica dettagliata del malware, insieme agli indicatori di compromissione, \u00e8 disponibile nell\u2019articolo del nostro esperto sul blog Securelist<\/a>.<\/p>\n I controlli basati sulle firme esistenti e la scansione delle dipendenze nei registri pubblici non sono pi\u00f9 sufficienti, poich\u00e9 il codice dannoso \u00e8 stato iniettato direttamente nelle azioni attendibili e firmate ed \u00e8 sfuggito al rilevamento fino all\u2019applicazione del monitoraggio comportamentale. Le pipeline CI\/CD sono diventate il \u201cnuovo perimetro\u201d della sicurezza.<\/p>\n Azioni immediate. <\/strong>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).<\/p>\n 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\u00e9 a un hash SHA specifico, esamina attentamente i registri di esecuzione del flusso di lavoro per la durata dell\u2019attacco attivo alla supply chain.<\/p>\n \u00c8 inoltre necessario verificare la presenza di traffico verso i domini scan.aquasecurtiy[.] nei registri di rete org<\/em>, checkmarx[.]zone<\/em> e models.litellm[.]cloud<\/em>. La presenza di tale traffico indica che i dati sensibili sono stati esfiltrati correttamente.<\/p>\n Se un archivio denominato docs-tpcp \u00e8 apparso nel GitHub dell\u2019organizzazione, ci\u00f2 potrebbe anche indicare una violazione dei dati riuscita.<\/p>\n Controlla host e cluster per individuare segni di compromissione: presenza di file ~\/.config\/sysmon\/sysmon.py pod sospetti in Kubernetes.<\/p>\n Svuota la cache ed esegui un inventario dei moduli PyPI: verifica la presenza di quelli dannosi ed esegui il rollback alle versioni pulite.<\/p>\nIn che modo \u00e8 stato attaccato Trivy<\/h2>\n
Compromissione LiteLLM<\/h2>\n
Funzionalit\u00e0 del malware TeamPCP Cloud Stealer<\/h2>\n
\n
Strategie di risposta e di difesa per CVE-2026-33634<\/h2>\n