Secondo i ricercatori di sicurezza, due GitHub Actions associate alla campagna nella supply chain Mini Shai-Hulud sono state nuovamente disabilitate dopo essere tornate brevemente disponibili a metà settembre. I repository interessati, actions-cool/issues-helper e actions-cool/maintain-one-comment, erano stati precedentemente messi offline in seguito a una compromissione nel maggio 2026.
L'azienda di sicurezza Socket ha dichiarato che i repository sono riapparsi il 16 settembre con i tag di rilascio dannosi ancora intatti. Di conseguenza, i progetti che facevano riferimento alle Actions tramite tag di versione modificabili avrebbero potuto scaricare ed eseguire il codice del workflow dannoso durante la successiva esecuzione CI/CD pianificata o attivata da un evento.
I repository ora mostrano l'avviso di GitHub secondo cui l'accesso è stato disabilitato dal personale per una violazione dei termini di servizio. Non è chiaro perché i repository siano tornati accessibili né per quanto tempo siano rimasti disponibili.
I tag esistenti hanno creato una rinnovata esposizione
Secondo quanto riportato, la compromissione originale ha inserito codice progettato per raccogliere credenziali e altri segreti disponibili ai workflow di GitHub Actions, per poi inviarli a un'infrastruttura controllata dagli attaccanti. I ricercatori hanno collegato l'attività al cluster Mini Shai-Hulud sulla base della sovrapposizione con un dominio di esfiltrazione osservato anche in pacchetti npm compromessi legati all'ecosistema @antv.
L'incidente illustra un rischio associato all'uso di tag come @v2 o @v2.2.1 per fare riferimento ad Actions di terze parti. A differenza di un identificatore di commit immutabile, un tag può puntare a codice modificato o tornare disponibile dopo il ripristino di un repository upstream. Non sono state necessarie modifiche ai file di workflow downstream affinché i progetti interessati eseguissero il payload precedentemente inserito.
Queste Actions sono comunemente utilizzate per attività di gestione delle issue, tra cui la gestione delle issue inattive e il mantenimento dei commenti dei bot. Tali workflow possono essere eseguiti quotidianamente o ogni volta che vengono aperte issue e pull request, rendendo potenzialmente rapida e diffusa qualsiasi rinnovata esposizione tra gli utenti delle Actions.
Risposta consigliata
- Identificare tutti i riferimenti nei workflow alle Actions interessate, incluso actions-cool/issues-helper@v2.2.1.
- Rimuovere le dipendenze ove possibile oppure sostituirle con un SHA di commit pulito e verificato, creato prima del 18 maggio 2026.
- Ruotare i segreti che potrebbero essere stati esposti nelle esecuzioni dei workflow interessati.
- Esaminare i log delle Actions alla ricerca di esecuzioni riuscite dopo periodi prolungati di errori o inattività.
- Esaminare la cronologia del repository e dei workflow alla ricerca di modifiche inattese successive al 16 settembre.
Non si ritiene che i workflow già bloccati a un SHA completo di commit noto e pulito, precedente alla compromissione di maggio, siano stati interessati dal temporaneo ritorno del repository.