23 marzo 2026 · 10 min lettura
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Self-HostingLa cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Self-HostingIscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
900k siti WordPress esposti a RCE critico, 500k a file read su wp-config.php. Se ospiti WordPress in homelab o su VPS, ecco cosa fare nei prossimi 30 minuti.
Trivy è lo scanner di vulnerabilità più usato nell'ecosistema container. Trentaduemila stelle su GitHub, circa cento milioni di download l'anno, oltre diecimila workflow CI/CD che referenziano trivy-action. Il 19 marzo 2026, qualcuno ha fatto force-push su 76 dei 77 tag di quella action, sostituendoli con commit contenenti un infostealer a cinque stadi. E non era la prima volta.
Ventotto giorni prima, un bot autonomo aveva già bucato lo stesso repository.
Questa non è la storia di un singolo incidente. È la dissezione di un fallimento sistemico — dalla misconfiguration iniziale alla rotation dei segreti fatta male, fino a un worm che usa la blockchain come dead-drop. Pezzo per pezzo.
Il 28 febbraio 2026 un account chiamato hackerbot-claw ha aperto una pull request contro trivy-action. Nel profilo si autodefiniva "powered by claude-opus-4-5" — un agente AI autonomo, non un umano con un IDE. La PR sfruttava un workflow pull_request_target mal configurato: quel trigger esegue il codice della PR nel contesto del repository target, con accesso ai segreti del repo. Un errore di configurazione noto da anni, documentato ovunque, e ancora presente nel 2026 su uno degli strumenti di sicurezza più diffusi al mondo.
L'agente ha estratto un Personal Access Token con permessi di scrittura. Con quel token, aveva le chiavi del castello. Ha colpito almeno sette repository di Microsoft, DataDog e CNCF prima che qualcuno se ne accorgesse. Aqua Security ha risposto ruotando i segreti compromessi.
Abbiamo ruotato segreti e token, ma il processo non era atomico e gli attaccanti potrebbero aver intercettato i token aggiornati.
Quella frase — il processo non era atomico — è il cardine di tutto ciò che è successo dopo.
Ruotare segreti dopo un breach è la procedura standard. Ma la rotation deve essere istantanea rispetto all'attaccante: revochi il vecchio, generi il nuovo, lo distribuisci, in una finestra temporale in cui nessuno può intercettare il passaggio. Se quella finestra esiste — se c'è un momento in cui il nuovo segreto è visibile prima che il vecchio sia invalidato — un attaccante già dentro al sistema può catturare entrambi.
Aqua ha ammesso che il loro processo aveva esattamente quella finestra. L'account di servizio aqua-bot, compromesso nel primo attacco, dava accesso non solo al repository GitHub ma anche a chiavi GPG, credenziali Docker Hub, token Twitter e Slack dell'organizzazione. Quando hanno ruotato, gli attaccanti erano ancora in ascolto. Hanno intercettato i nuovi token prima che i vecchi fossero revocati.
Il risultato: accesso persistente, invisibile, con credenziali fresche.
Con i token intercettati, il gruppo TeamPCP ha eseguito force-push su 76 dei 77 tag di trivy-action e tutti e 7 i tag di setup-trivy. Ogni tag puntava ora a un commit contenente un payload chiamato Cloud stealer. CrowdStrike ha confermato che i commit malevoli erano "praticamente identici" agli originali, con metadati falsificati per corrispondere alle date e agli autori dei tag legittimi.
Ma la falsificazione non era perfetta. StepSecurity ha identificato tre artefatti rivelatori: le firme GPG mancavano sui commit (gli originali le avevano), le date dei commit parent erano impossibili (posteriori ai figli), e ogni commit modificava un singolo file. Tre indizi che un sistema di verifica automatizzato avrebbe potuto catturare. Nessuno l'aveva implementato.
Il Cloud stealer non è un malware grezzo. È un'operazione chirurgica in cinque fasi, e vale la pena smontarla perché racconta molto su come si attacca l'infrastruttura CI/CD moderna.
Quel typosquat è un dettaglio che merita attenzione. Chi ha registrato quel dominio conosceva l'infrastruttura di Aqua abbastanza da sapere che un dominio simile non avrebbe alzato allarmi immediati nei log di rete. Non è un attacco opportunistico — è un'operazione pianificata con ricognizione.
Come se il breach di Trivy non bastasse, i token rubati hanno alimentato qualcosa di più ambizioso. Entro 24 ore dall'attacco, 47 pacchetti npm risultavano compromessi. Il vettore: un worm auto-propagante battezzato CanisterWorm da Aikido Security.
Il meccanismo è perverso nella sua semplicità. CanisterWorm usa smart contract sulla blockchain ICP (Internet Computer Protocol) come canale di command & control. Il malware non contatta un server — legge istruzioni da un contratto on-chain, immutabile, non censurabile, non sequestrabile. È il primo caso documentato di malware che usa la blockchain come dead-drop per il C2.
Pensaci un momento. Un server C2 tradizionale lo puoi abbattere, sequestrare il dominio, fare un takedown. Uno smart contract su blockchain, no. Finché la rete esiste, le istruzioni restano lì. Chi ha progettato questo worm non stava pensando al prossimo mese — stava costruendo infrastruttura persistente.
I 47 pacchetti npm compromessi non sono stati resi noti nella loro interezza. Quello che sappiamo è che il worm si propagava sfruttando i token npm estratti dai runner CI/CD, pubblicando versioni avvelenate di pacchetti su cui l'account compromesso aveva permessi di publish. Una catena che si auto-alimenta.
C'è un elemento in questa storia che non si può ignorare: il primo attacco è stato condotto da un agente AI autonomo. Non assistito da un umano che scriveva prompt — autonomo. hackerbot-claw ha trovato la misconfiguration, ha scritto la PR, ha estratto il token, ha pivotato su altri repository. Ne ho scritto quando un'altra operazione autonoma ha infettato il 12% delle skill su OpenClaw: il pattern è lo stesso. Agenti che scandagliano GitHub alla ricerca di workflow mal configurati, repository con segreti accessibili, superfici di attacco che un umano impiegherebbe settimane a mappare.
La differenza di scala è ciò che ha reso possibile il primo breach. Un penetration tester umano analizza decine di target al giorno. Un agente AI ne analizza migliaia all'ora, senza pause, senza cali di attenzione, con una capacità di pattern matching che supera qualsiasi team.
Se usi Trivy nel tuo homelab — e se stai leggendo homelabz.cc, le probabilità sono alte — la domanda concreta è: sei stato esposto? La finestra del binario compromesso (v0.69.4) è stata di circa tre ore. Se hai eseguito trivy image o trivy fs con quella versione in quelle tre ore, il payload ha avuto accesso al tuo filesystem. Chiavi SSH, .env, kubeconfig, token Docker.
Ma anche se non eri nella finestra, il problema strutturale resta: come referenzi le GitHub Actions nei tuoi workflow?
Il punto 4 è quello che fa la differenza strutturale. Quando pinni a un tag (@v1), stai dicendo: "esegui qualsiasi cosa punti a quel tag in quel momento". Il tag è un puntatore mobile — chiunque abbia accesso in scrittura al repository può spostarlo. Quando pinni a SHA, stai dicendo: "esegui esattamente questo commit". Lo SHA è immutabile. È la differenza tra una serratura che qualcuno può cambiare e una che è fissata nel cemento.
# PRIMA (vulnerabile)
- uses: aquasecurity/trivy-action@master
# DOPO (pinned a SHA — verificare sempre il commit)
- uses: aquasecurity/trivy-action@a7a829a0e57927dc35c7b7ab70e5ef7a3110e7e5Ricordo che anche la sandbox DNS exfiltration di AWS Bedrock dipendeva da un assunto implicito di fiducia — l'idea che ciò che esegui in un ambiente controllato sia sicuro per definizione. Qui è lo stesso schema mentale: ci fidiamo delle GitHub Actions perché "sono su GitHub" e "le mantiene un vendor di sicurezza". Due premesse, entrambe irrilevanti se il vendor stesso viene compromesso.
Il D.Lgs. 138/2024, che recepisce la direttiva NIS2, è in vigore dal 1 gennaio 2026. L'articolo 21 impone ai soggetti essenziali e importanti di gestire il rischio supply chain dei propri fornitori ICT. Le sanzioni arrivano a 10 milioni di euro o al 2% del fatturato globale per i soggetti essenziali. La scadenza per implementare le misure di sicurezza di base è ottobre 2026.
Il tessuto produttivo italiano è fatto di PMI interconnesse, dove il fornitore di servizi cloud della manifatturiera di Modena usa le stesse GitHub Actions della software house di Catania. Un attacco supply chain come quello a Trivy non rispetta i confini aziendali — si propaga lungo le dipendenze, e le dipendenze delle PMI italiane sono spesso le stesse, gestite con lo stesso livello di attenzione: poco.
Chi oggi non ha un inventario delle GitHub Actions usate nei propri workflow CI/CD, chi non ha policy di pinning a SHA, chi non monitora le dipendenze per advisory critici — a ottobre 2026 avrà un problema di compliance oltre che di sicurezza. E non servirà spiegare all'autorità che "usavamo il tag consigliato nel README".
Il pattern è identico a quello di tj-actions/changed-files nel 2025, che ha impattato 23.000 repository. La differenza è che questa volta il target era uno strumento di sicurezza — un tool che le aziende eseguono per proteggersi. L'ironia non ha bisogno di commento: lo scanner di vulnerabilità era la vulnerabilità.
StepSecurity, CrowdStrike, Socket.dev e Wiz hanno pubblicato analisi dettagliate entro 48 ore. La comunità di sicurezza ha risposto bene. Ma la comunità di sicurezza non è il problema — il problema sono i centomila workflow che referenziano trivy-action@v1 e i cui maintainer non leggono advisory.
Aqua Security ha ripristinato i tag, pubblicato un post-mortem, e implementato la verifica GPG sui commit. Misure corrette, tardive di ventotto giorni. La domanda che resta è se il modello di distribuzione delle GitHub Actions — basato su tag mobili, senza verifica crittografica di default, con un sistema di permessi che permette a un singolo token compromesso di riscrivere l'intera storia dei rilasci — sia strutturalmente adeguato a distribuire codice che gira nelle pipeline di sicurezza di mezzo mondo.
La risposta, dopo due breach in ventotto giorni sullo stesso repository, mi sembra piuttosto chiara.
Fonti: GitHub Advisory GHSA-69fq-xp46-6x23, Aqua Security — Post-Mortem, CrowdStrike — From Scanner to Stealer, StepSecurity — Trivy Compromised a Second Time, Wiz — Trivy Compromised by TeamPCP, Aikido Security — CanisterWorm