Il ripristino di repository GitHub Actions ha riattivato per breve tempo un payload dormiente della supply chain

Il ripristino dell’accesso ai repository ha riportato in vita vecchi tag malevoli

Il 16 settembre 2026, due GitHub Actions gestite da actions-cool sono tornate brevemente accessibili, riattivando codice malevolo lasciato durante la campagna Mini Shai-Hulud.

I repository interessati erano:

• actions-cool/issues-helper
• actions-cool/maintain-one-comment

Entrambi erano stati compromessi il 18 maggio 2026. I tag delle release non erano mai stati ripuliti del tutto dopo l’incidente e continuavano a puntare a contenuti modificati dagli attaccanti.

Con il ripristino dell’accesso, i workflow che dipendevano da quei tag di versione modificabili hanno potuto scaricare ed eseguire nuovamente il payload. Gli utenti non hanno dovuto modificare i file dei workflow e agli attaccanti non è servito pubblicare un’altra release.

Il ricercatore di Socket Karlo Zanki ha dichiarato che i repository sono rimasti accessibili dalle 11:09 alle 18:16 (GMT+2) del 16 settembre. In seguito sono stati disabilitati di nuovo.

Nella comunicazione di GitHub si leggeva che il personale aveva bloccato l’accesso per una violazione dei termini di servizio. Non è noto perché i repository siano stati riattivati né quale procedura abbia consentito di rendere nuovamente scaricabili riferimenti che in precedenza puntavano a contenuti malevoli.

I tag modificabili hanno trasformato il ripristino in esecuzione

I workflow di GitHub Actions possono caricare automazioni di terze parti tramite riferimenti come:

uses: actions-cool/[email protected]

Il riferimento dopo @ può indicare un tag di versione, anziché un commit immutabile. Un tag può continuare a puntare a contenuti compromessi — o essere reindirizzato verso contenuti diversi — senza che sia necessario modificare il workflow che lo richiama.

È stata proprio questa distinzione a determinare l’incidente. Quando GitHub ha ripristinato l’accesso ai repository di actions-cool, i runner hanno potuto risolvere i tag esistenti e recuperare il codice malevolo già presente a monte.

Il riferimento actions-cool/[email protected] deve essere considerato compromesso. Non è stata resa nota la versione esatta interessata di actions-cool/maintain-one-comment: le organizzazioni dovrebbero quindi verificare ogni utilizzo di questa Action, senza dare per scontato che un tag specifico sia sicuro.

Non è stato necessario pubblicare nuovo codice, modificare la configurazione dei workflow, sfruttare una vulnerabilità o ricorrere a un’infrastruttura controllata dagli attaccanti. È bastato ripristinare la disponibilità dei repository per riattivare il canale di distribuzione.

I workflow bloccati sullo SHA completo di un commit noto come sicuro e precedente al 18 maggio 2026 non sono stati interessati. A differenza di un tag modificabile, l’hash completo del commit vincola la dipendenza a uno stato preciso del repository.

Le attività di routine sui problemi hanno creato frequenti occasioni di esecuzione

Le Actions compromesse svolgono comuni attività di manutenzione dei repository, come controllare i problemi appena aperti, chiudere quelli inattivi e mantenere aggiornato un unico commento automatico.

Spesso questi processi vengono configurati per essere eseguiti ogni giorno o in risposta a eventi come l’apertura di un nuovo problema o di una pull request. La pianificazione ha creato diverse occasioni perché i repository ripristinati raggiungessero i runner CI/CD durante le sette ore di disponibilità.

Socket ha valutato che molti repository dipendenti potrebbero aver eseguito il payload entro un giorno dalla riattivazione delle Actions. Non sarebbe stato necessario alcun ulteriore intervento da parte dell’autore della minaccia.

Il codice malevolo tentava di sottrarre le credenziali disponibili nell’ambiente CI/CD e di inviarle a un server controllato dagli attaccanti. L’indicatore di esfiltrazione noto è:

t.m-kosche[.]com

È quindi opportuno indagare su ogni repository che abbia eseguito una delle due Actions nel periodo interessato, per verificare una possibile esposizione di segreti. Il danno potenziale non si limita al singolo workflow: le credenziali sottratte potrebbero consentire l’accesso a repository, sistemi di build o processi di pubblicazione del software.

Non si sa quali credenziali siano state raccolte nei singoli ambienti interessati. L’esposizione dipende dai segreti e dai permessi disponibili al job al momento dell’esecuzione dell’Action compromessa.

Le prove collegano l’attività a Mini Shai-Hulud

L’incidente è associato al cluster di attività Mini Shai-Hulud, che ha coinvolto anche pacchetti npm dell’ecosistema @antv.

Philipp Burckhardt, responsabile della threat intelligence di Socket, ha valutato che il dominio di esfiltrazione condiviso collegasse la compromissione di GitHub Actions e l’attività su npm allo stesso cluster. Secondo questa valutazione, le somiglianze non giustificavano il trattamento della componente npm come un incidente separato.

Il problema centrale, in questo caso, era la persistenza nella supply chain del software. I contenuti dell’attaccante sono rimasti associati a riferimenti già considerati attendibili dai repository a valle. Disabilitare i repository a monte ha interrotto la distribuzione, ma non ha rimosso gli oggetti compromessi.

Di conseguenza, il ripristino della disponibilità ha riattivato anche il percorso di attacco. Le configurazioni dei workflow esistenti sono tornate a essere pericolose, pur essendo rimaste invariate.

I responsabili dei repository dovrebbero ruotare i segreti e controllare la cronologia delle esecuzioni

Per prima cosa, i difensori dovrebbero cercare nei file dei workflow i riferimenti a entrambe le Actions interessate. La ricerca dovrebbe includere i file attuali, i workflow riutilizzabili e i branch più vecchi che potrebbero ancora avviare automazioni.

Come minimo, i team di risposta dovrebbero:

1. Considerare compromesso actions-cool/[email protected].
2. Rimuovere entrambe le dipendenze da actions-cool o sostituirle con uno SHA completo di un commit verificato e precedente al 18 maggio 2026.
3. Ruotare tutti i segreti che potrebbero essere stati accessibili ai job dei workflow interessati.
4. Esaminare la cronologia delle esecuzioni dei workflow per individuare esecuzioni riuscite dopo una lunga serie di errori Set up job.
5. Analizzare le esecuzioni avvenute durante il periodo di disponibilità del 16 settembre 2026.
6. Controllare la cronologia dei repository per individuare commit inattesi effettuati dopo il 16 settembre 2026.
7. Cercare nei dati di rete, proxy e telemetria CI/CD eventuali connessioni a t.m-kosche[.]com.

La rotazione dei segreti non dovrebbe limitarsi alle credenziali di cui è già stata confermata la sottrazione. Se un token, una chiave o una password era accessibile a un job che ha caricato correttamente l’Action malevola, i difensori dovrebbero presumere che sia stato esposto, a meno che le prove sull’esecuzione non dimostrino il contrario.

I responsabili dei repository dovrebbero inoltre rivedere i permessi assegnati ai token dei workflow interessati. Le conseguenze del furto di credenziali dipendono in larga misura dal fatto che quei token potessero soltanto leggere il codice sorgente o anche modificare i repository e i relativi processi di rilascio.

Il blocco sul commit limita i rischi legati alle dipendenze riattivate

Questo episodio mette in luce una debolezza specifica delle dipendenze GitHub Actions basate sui tag: la fiducia resta legata allo stato mutevole di un repository esterno.

Un workflow che fa riferimento a @v2.2.1 può sembrare vincolato a una versione precisa, ma il tag non equivale a un artefatto software immutabile. La sua sicurezza può cambiare se il repository a monte viene modificato, compromesso, rimosso o ripristinato.

Bloccare le Actions di terze parti sugli SHA completi dei commit riduce il rischio, perché il workflow richiede una revisione specifica. Le organizzazioni devono comunque verificare il commit scelto e monitorare gli eventi di sicurezza a monte, ma il ripristino di un repository non può reindirizzare silenziosamente il riferimento bloccato verso codice diverso.

I controlli di accesso e la disattivazione dei repository restano misure di contenimento utili. Non eliminano però i contenuti malevoli ancora associati a tag di release considerati attendibili.