A settembre 2026 i ricercatori di Socket hanno documentato la riattivazione di un attacco alla supply chain che si credeva concluso da mesi. Il 18 maggio 2026 due GitHub Action pubbliche - actions-cool/issues-helper e actions-cool/maintain-one-comment, strumenti di automazione molto diffusi per la gestione di issue e commenti nei repository - erano state compromesse nell'ambito della campagna nota come Mini Shai-Hulud, che aveva già infettato 323 pacchetti npm e 639 versioni distinte con payload offuscati capaci di rubare token di sviluppatori, credenziali e segreti delle pipeline CI/CD.

Cosa è successo

GitHub aveva disabilitato i due repository poco dopo la scoperta della compromissione a maggio. Il problema è riemerso il 16 settembre 2026, quando - secondo quanto ricostruito dal ricercatore Karlo Zanki di Socket - entrambi i repository sono tornati accessibili, ma con i tag di rilascio compromessi ancora intatti: qualunque workflow che referenziasse le action tramite un tag di versione, anziché un commit fissato, ha ripreso a scaricare ed eseguire il payload malevolo, esattamente come a maggio. Il codice esfiltra segreti verso un dominio controllato dagli attaccanti (t.m-kosche[.]com). Secondo Philipp Burckhardt, responsabile threat intelligence di Socket, l'episodio è direttamente collegato al cluster Mini Shai-Hulud.

La finestra di esposizione è durata oltre una settimana, dal 16 al 25 settembre 2026, quando GitHub ha nuovamente disabilitato i due repository. Secondo il grafo delle dipendenze di GitHub, circa 15.000 repository dipendono dalla sola action issues-helper: il numero di quelli realmente compromessi dipende da quanti la referenziano tramite tag mobile invece che tramite commit SHA fissato, un dettaglio che nella pratica pochi team verificano davvero.

Un problema strutturale, non un incidente isolato

Il punto debole sfruttato in questo caso non è tecnicamente nuovo, ma è raramente compreso appieno: quando un workflow GitHub Actions referenzia un'azione con un tag (per esempio @v1 o @main) invece che con un commit SHA specifico, sta delegando al proprietario di quel repository - o a chiunque ne prenda il controllo - la decisione su quale codice eseguire ad ogni esecuzione della pipeline. Se il repository viene compromesso, poi ripristinato senza una pulizia completa e reso di nuovo accessibile, il workflow riprende semplicemente a fidarsi di un contenuto che nel frattempo è tornato malevolo, senza che sia necessaria alcuna nuova azione da parte dell'attaccante.

Cosa significa per le aziende italiane

  • Software house e team di sviluppo che usano GitHub Actions per l'integrazione e il rilascio continuo (CI/CD) devono considerare qualunque azione di terze parti referenziata per tag come una dipendenza non fidata a tutti gli effetti, alla pari di un pacchetto npm scaricato da un registro pubblico.
  • Le aziende che sviluppano software distribuito a clienti o alla pubblica amministrazione rientrano nell'ambito della gestione del rischio di supply chain software richiesta dalla NIS2 (art. 24 D.Lgs. 138/2024): un segreto CI/CD rubato può tradursi nella compromissione del prodotto consegnato a valle, con impatti che ricadono sui clienti finali, non solo sull'azienda sviluppatrice.
  • Chi gestisce infrastrutture con dati personali collegate a repository o pipeline (per esempio credenziali di ambienti che trattano dati di clienti) deve considerare la rotazione dei segreti come misura tecnica di protezione ai sensi dell'art. 32 GDPR, da attuare ogni volta che una dipendenza CI/CD nota risulta compromessa, anche se la finestra di esposizione sembra chiusa.
  • La reiterazione dell'attacco a distanza di quattro mesi dimostra che una bonifica percepita come completa (repository disabilitato) non equivale a rischio azzerato: i team italiani dovrebbero verificare periodicamente lo stato delle dipendenze CI/CD note per essere state compromesse in passato, non solo al momento della prima notizia.

Cosa fare subito

  • Cercare nei propri workflow GitHub Actions ogni riferimento a actions-cool/issues-helper e actions-cool/maintain-one-comment, in particolare se richiamati con un tag di versione e non con un commit SHA.
  • Rimuovere le action coinvolte oppure fissarle a un commit verificato antecedente al 18 maggio 2026.
  • Ruotare immediatamente tutti i segreti accessibili dai workflow interessati: token GitHub, credenziali cloud, chiavi API.
  • Rivedere la cronologia delle esecuzioni dei workflow dal 16 al 25 settembre 2026 alla ricerca di comportamenti anomali o connessioni verso domini sconosciuti.
  • Adottare come pratica permanente il pinning delle GitHub Action a commit SHA specifici, invece che a tag mobili, per ogni dipendenza di terze parti usata nelle pipeline CI/CD.
  • Estendere il controllo a tutte le altre dipendenze note della campagna Mini Shai-Hulud (inclusi i pacchetti npm colpiti a maggio e agosto), verificando che non siano state reintrodotte nei propri progetti.