GitHub Actions Mini Shai-Hulud riattivate: il contenimento diventa attacco

Il 16 settembre 2026, tra le 11:09 e le 18:16 ora italiana, due GitHub Actions compromesse nella campagna Mini Shai-Hulud sono tornate accessibili. I tag di rilascio puntavano ancora al contenuto malevolo del 18 maggio. I workflow downstream che le referenziavano per versione mutabile hanno ripreso automaticamente a scaricare ed eseguire il payload, senza che l'attaccante dovesse compiere alcuna azione nuova. È il primo caso documentato in cui una risposta a incidente — la disabilitazione temporanea di repository — genera una bomba ad orologeria attivabile dal mero ripristino dell'accesso.

Come funziona l'attacco: la fragilità dei tag mutabili

GitHub Actions permette di referenziare un'azione tramite tag semantici: uses: owner/repo@tag. Questi tag sono mutabili. Un maintainer può spostarli da un commit a un altro senza che il workflow downstream ne sia informato. Il 18 maggio 2026, nella campagna Mini Shai-Hulud, questo meccanismo è stato sfruttato per puntare i tag v2.2.1 e successivi al commit malevolo a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d.

Il payload, contenuto in index.js offuscato, installa il runtime Bun tramite oven-sh/setup-bun e lo utilizza per eseguire il codice malevolo con accesso al contesto del workflow. I log analizzati da Socket mostrano la transizione netta: prima del re-enablement, i run fallivano in 5-8 secondi con errore di repository non disponibile; dopo, duravano 9 minuti e 34 secondi in media, con esecuzione completa del payload. Un run specifico, il #1850, ha richiesto 11 minuti e 25 secondi.

I dati esfiltrati raggiungevano il dominio t.m-kosche[.]com, già osservato nella campagna Mini Shai-Hulud su pacchetti npm dello scope @antv. La sovrapposizione infrastrutturale conferma il cluster di minaccia, non un incidente separato.

La regressione di sicurezza: quando il contenimento genera nuovo rischio

La risposta standard a un repository compromesso è la disabilitazione: blocca l'accesso, interrompe la diffusione, dà tempo all'analisi. Ma in questo caso la disabilitazione ha lasciato intatti i tag malevoli. Al re-enablement, qualsiasi workflow con riferimento per tag ha automaticamente risolto il nuovo — anzi, il vecchio — commit e ha eseguito il payload.

Karlo Zanki, ricercatore di Socket, ha documentato la dinamica: "Most supply chain incidents involve something new: a newly published malicious version, a newly hijacked account, or a newly injected workflow. This one did not. No new code was published and no configuration was changed". L'attore della minaccia non ha dovuto pubblicare exploit nuovi, infrastructure nuova o compromessi aggiuntivi. Il codice malevolo era in posizione dal 18 maggio; l'unica variabile cambiata è stata la disponibilità del repository.

Questo pattern — security regression re-activation — non è documentato in letteratura come vettore sistematico. Il caso Mini Shai-Hulud ne costituisce la prima istanza verificata in supply chain software.

"Any workflow that references either action by a version tag resumed downloading and executing the payload on its next run."
— Karlo Zanki, Socket researcher

La finestra di esposizione e i limiti della visibilità

Nove giorni di re-enablement, dal 16 al 25 settembre 2026. La finestra esatta di esecuzione attiva resta parzialmente oscura: Socket ha rilevato il re-enablement e documentato i log di alcuni run, ma il numero totale di workflow eseguiti con payload in quel lasso non è quantificato. Analogamente, non è noto quanti dei circa 15.000 repository dipendenti da issues-helper usassero tag mutabile anziché SHA pinning; solo questi ultimi erano immuni, poiché puntano a un commit specifico pre-18 maggio che il tag non può ridirigere.

Il motivo del re-enablement è ignoto. Potrebbe derivare da una richiesta del maintainer legittimo, da un processo automatico di GitHub, da un errore operativo. Il dossier non lo specifica e nessuna delle fonti lo determina. Ciò che è documentato è l'assenza di notifica preventiva ai maintainer downstream: i repository sono tornati accessibili senza avviso che i tag malevoli persistevano.

Philipp Burckhardt, head of threat intelligence presso Socket, ha confermato il collegamento con il cluster Mini Shai-Hulud: "That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident". L'identità completa dell'attore rimane non attribuita.

Cosa fare adesso

Per i maintainer che utilizzano GitHub Actions in workflow propri:

• Verificare immediatamente se i workflow referenziano le azioni actions-cool/issues-helper o actions-cool/maintain-one-comment, anche transitivamente in action composte da terze parti
• Sostituire i riferimenti per tag con SHA pinning: il commit uses: owner/repo@sha impedisce la risoluzione dinamica a contenuto malevolo
• Rivedere i log di esecuzione dei workflow tra il 16 e il 25 settembre 2026 per identificare run con durata anomala (oltre i 9 minuti vs i 5-8 secondi tipici di un'azione non compromessa) o presenza di oven-sh/setup-bun non richiesto esplicitamente
• Se esposizione è confermata, considerare la rotazione di GITHUB_TOKEN e secrets eventualmente accessibili nel contesto di quei workflow, verificando nei log eventuali connessioni a t.m-kosche[.]com

Perché il caso cambia il paradigma del contenimento

La lezione del Mini Shai-Hulud non riguarda un nuovo tipo di malware, ma un nuovo modo in cui il malware persistito può riattivarsi. La disabilitazione di repository, pratica difensiva consolidata, assume qui una proprietà emergente: diventa vettore di ri-attacco se i tag non sono ripuliti. Il contenimento richiede ora una fase di post-contenimento — verifica dello stato dei riferimenti mutabili — che precede qualsiasi re-enablement.

Per GitHub, il caso solleva una questione di processo: il re-enablement di repository precedentemente disabilitati per violazione dei ToS dovrebbe includere un controllo automatico sui tag di rilascio e, in caso di anomalie, una notifica ai dipendenti downstream. La piattaforma non ha comunicato pubblicamente il motivo del re-enablement né i criteri di review applicati.

Il settore CI/CD ha costruito un ecosistema su un trade-off: i tag offrono convenienza, gli SHA offrono integrità. Mini Shai-Hulud dimostra che il trade-off, quando si interseca con interventi difensivi parziali, può generare danni maggiori di quelli originari. La convenienza del tag mutabile non è più un compromesso accettabile senza consapevolezza del rischio di regressione.

Domande frequenti

Perché il re-enablement non ha richiesto azione dell'attaccante?

Il payload era già in posizione dal 18 maggio 2026 nei tag. La disabilitazione del 19 maggio aveva solo reso il repository irraggiungibile; al ripristino dell'accesso, i workflow con riferimento per tag hanno automaticamente scaricato ed eseguito il contenuto disponibile. Nessuna nuova compromissione è stata necessaria.

Cos'è SHA pinning e perché avrebbe protetto?

SHA pinning consiste nel referenziare un'azione tramite l'hash completo del commit (40 caratteri esadecimali) anziché tramite tag. Il tag può essere spostato da un commit a un altro; l'hash è immutabile. I workflow che usavano SHA pre-18 maggio non erano affetti perché puntavano a un commit legittimo non alterato dalla campagna Mini Shai-Hulud.

Quanti repository sono stati effettivamente compromessi?

Non è quantificato. La dependency graph GitHub mostra circa 15.000 repository dipendenti da issues-helper, ma il numero di workflow che usavano tag mutabile e che sono effettivamente eseguiti in quel lasso non è disponibile nelle fonti. Il dato riguarda esposizione potenziale, non impatto verificato.

Fonti

• https://thehackernews.com/2026/09/compromised-github-actions-came-back.html
• https://socket.dev/blog/mini-shai-hulud-actions
• https://nuclearcoffee.org/compromised-github-actions-came-back-online-and-resumed-executing-mini-shai-hulud-malware/
• https://www.guardianmssp.com/2026/09/25/compromised-github-actions-came-back-online-and-resumed-executing-mini-shai-hulud-malware/
• https://blog.netmanageit.com/compromised-github-actions-came-back-online-and-resumed-executing-mini-shai-hulud-malware/
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence
• https://thehackernews.com/search/label/Vulnerability
• https://thehackernews.com/search/label/Cyber%20Attack

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti