GitHub Actions riattiva Mini Shai-Hulud: i tag malevoli erano ancora lì

🛡️ Executive Summary

• Due GitHub Actions compromesse a maggio sono tornate raggiungibili il 16 settembre con i tag malevoli ancora associati al payload.
• Non è servito un nuovo exploit: i workflow basati sui tag hanno ripreso automaticamente a scaricare ed eseguire Mini Shai-Hulud.
• Socket raccomanda SHA puliti, rotazione dei segreti e verifica dei workflow eseguiti dal 16 settembre in poi.

Due GitHub Actions compromesse durante la campagna Mini Shai-Hulud di maggio sono tornate raggiungibili il 16 settembre con i tag di release malevoli ancora intatti. Il risultato è stato anomalo e pericoloso: workflow che non erano stati modificati hanno ripreso a scaricare ed eseguire il payload semplicemente perché i repository upstream erano di nuovo accessibili. Socket ha ricostruito il comportamento di actions-cool/issues-helper e actions-cool/maintain-one-comment, poi disabilitati nuovamente da GitHub. Il caso sposta il problema dalla singola compromissione alla gestione della fiducia: contenere un repository non basta se tag e release restano puntati al codice ostile.

I repository sono tornati online senza essere ripuliti

Le due Actions erano state compromesse il 18 maggio 2026 e bloccate da GitHub il giorno successivo. Il 16 settembre sono diventate nuovamente accessibili, ma i tag di release continuavano a risolvere verso il contenuto malevolo introdotto a maggio. La ricerca originale di Socket ha verificato che actions-cool/[email protected] puntava ancora al commit compromesso e che i runner scaricavano il pacchetto durante il normale Set up job, installando Bun ed eseguendo bun run $GITHUB_ACTION_PATH/index.js. Non servivano nuove modifiche al workflow, nuovi exploit o un’ulteriore intrusione da parte dell’attaccante: bastava che il repository tornasse disponibile. La dinamica si inserisce nella crisi già osservata quando Shai-Hulud ha trasformato npm, GitHub e i workflow CI/CD in una superficie unica, dove token e automazioni diventano strumenti di propagazione tanto quanto il codice applicativo.

Leggi anche: TanStack e CrowdSec mostrano gli effetti a distanza della supply chain compromessa

Un tag mutabile può riattivare un attacco mesi dopo

Il punto architetturale è il modo in cui GitHub Actions risolve le dipendenze. Un riferimento come uses: actions-cool/[email protected] usa un tag, non un commit immutabile. Se quel tag viene spostato o resta associato a contenuto compromesso, il runner scarica ciò che il tag indica nel momento dell’esecuzione. Socket rileva circa 15.000 repository dipendenti da issues-helper, senza poter stabilire quanti utilizzino effettivamente un tag mutabile e siano quindi esposti. I workflow interessati sono particolarmente insidiosi perché automatizzano attività ordinarie su issue e commenti e spesso partono su schedule, apertura di issue o pull request. In alcuni casi, quindi, anche un utente esterno può innescare una routine che scarica l’Action. Il precedente attacco a SpotBugs, reviewdog e tj-actions aveva già mostrato come tag e Actions compromesse possano trasformare un componente considerato affidabile in un canale per sottrarre segreti.

Il payload aveva accesso al contesto più sensibile della pipeline

Un’Action eseguita nel runner non è una semplice libreria passiva. Può accedere al GITHUB_TOKEN e ai secret esplicitamente esposti dal workflow, oltre a operare con i permessi assegnati al job. Per questo la riattivazione di Mini Shai-Hulud non richiedeva persistenza sull’endpoint dello sviluppatore: era sufficiente che la pipeline eseguisse nuovamente il codice compromesso. Socket ha osservato run che, dopo giorni di fallimenti immediati dovuti al blocco del repository, tornavano improvvisamente a completarsi in diversi minuti, con il download di oven-sh/setup-bun e l’avvio del payload JavaScript. Il pattern è coerente con una supply chain nella quale il bersaglio reale sono le credenziali di automazione, come Matrice Digitale ha ricostruito nell’analisi sui 469 percorsi cercati da Shai-Hulud per rubare segreti AI, cloud e CI/CD. GitHub ha già rafforzato alcune difese di actions/checkout contro workflow privilegiati, ma quelle protezioni non eliminano il rischio di una terza parte esplicitamente richiamata dal workflow.

Continua con: GitHub e PyPI introducono difese temporali contro la supply chain · GitHub Actions usate come infrastruttura offensiva distribuita

La mitigazione vera è togliere fiducia ai tag e ruotare i segreti

Socket raccomanda di individuare ogni riferimento a actions-cool/issues-helper e actions-cool/maintain-one-comment, trattando come compromessi i riferimenti basati su tag, incluso @v2.2.1. La misura più netta è rimuovere le Actions oppure fissarle a un commit SHA noto come pulito e precedente al 18 maggio 2026; il pinning protegge soltanto se il commit scelto è realmente integro. Per i workflow eseguiti dal 16 settembre in poi, la ricerca consiglia di ruotare tutti i secret accessibili al job, verificare i permessi del GITHUB_TOKEN, controllare la cronologia delle esecuzioni alla ricerca del passaggio da errori immediati a run di durata anomala e cercare nei log il download di Bun o il comando che esegue index.js. Va infine controllata la storia dei repository per commit inattesi successivi al 16 settembre. La lezione più importante non è quindi che GitHub Actions sia insicuro, ma che un riferimento mutabile delega parte della propria sicurezza allo stato futuro del repository upstream. Se quel repository viene riabilitato senza bonifica, il compromesso può tornare operativo senza che nel progetto downstream cambi una sola riga.