Una campagna di furto credenziali attribuita a GhostAction sta inserendo workflow GitHub Actions dannosi in migliaia di repository attraverso account di manutentori open source compromessi. I file si presentano come controlli di sicurezza, ma cercano segreti nei repository e li inviano a un server controllato dagli attaccanti.
Secondo le analisi citate da The Hacker News, due account di sviluppatori hanno distribuito lo stesso workflow in oltre 340 repository. Socket riferisce inoltre di aver individuato, al 9 ottobre 2026, più di 500 account GitHub coinvolti e decine di migliaia di repository raggiunti dal 7 ottobre.
Un falso audit che estrae segreti
I workflow individuati si chiamano Security Audit (security-audit.yml) oppure GitHub Actions Security (github_actions_security.yml). Il nome è coerente con un controllo tecnico legittimo, mentre il comportamento riportato dai ricercatori è tutt’altro: il codice invia dati sensibili all’indirizzo IP 193.32.204[.]199 tramite HTTP non cifrato.
Il workflow può essere eseguito manualmente e si attiva anche a ogni push senza filtri su rami e tag. Usa inoltre fetch-depth: 0, impostazione che rende disponibile l’intera cronologia Git del progetto anziché solo l’ultima revisione.
Questo dettaglio amplia il perimetro del furto. Oltre ai file presenti nella copia di lavoro, il payload cerca credenziali anche nei commit passati: chiavi AWS, token GitHub e GitLab, credenziali per servizi cloud e SaaS, oltre a chiavi API di Anthropic, OpenAI e OpenRouter. Il codice cerca 13 schemi di credenziali e tenta anche di associare gli AWS access key ID alle rispettive chiavi segrete.
Due maintainer compromessi e una diffusione più ampia
StepSecurity ha rilevato che l’account di Takashi Kitao, autore del motore di gioco pyxel, ha introdotto il workflow in 27 repository a partire dalle 13:20 UTC. Otto ore dopo, l’account di Henry Wu, noto come henrywoo e indicato come autore originario di athenadriver di Uber, è stato usato per distribuire lo stesso file in 318 repository in una finestra di 16 minuti, tra le 21:10 e le 21:26 UTC.
La fonte attribuisce l’attività a GhostAction, una campagna di attacchi alla supply chain emersa nel settembre 2025. In precedenza avrebbe interessato 817 repository collegati a 327 utenti GitHub, con l’esfiltrazione di 3.325 segreti, inclusi token PyPI, npm e DockerHub.
Le cifre più recenti sono superiori: Socket dichiara di avere identificato oltre 500 account che hanno registrato il workflow malevolo in decine di migliaia di repository dal 7 ottobre 2026. I numeri descrivono rilevazioni in momenti diversi e non vanno quindi letti come un unico conteggio consolidato.
Come avviene l’attacco
La ricostruzione indicata dai ricercatori parte dal furto delle credenziali del maintainer, probabilmente un personal access token finito in log di infostealer o in archivi di credenziali sottratte. L’attaccante esamina poi i workflow del repository, inserisce il proprio file nel branch predefinito usando l’identità della vittima e attende l’esecuzione del codice.
Il rischio non resta confinato al repository iniziale. Socket segnala 279 fork nello spazio dei nomi henrywoo che contengono il file: se GitHub Actions è abilitato, i push successivi possono attivare la raccolta delle credenziali. Fork privati e mirror downstream sono particolarmente esposti, perché è più probabile che contengano segreti commessi per errore.
In almeno un caso osservato il 30 agosto 2026, gli autori avrebbero anche modificato il repository kuafuai/DevOpsGPT per inserire un miner di criptovalute XMRig nell’immagine Docker del progetto. La fonte precisa però che, al momento della pubblicazione, non risultavano rilasci di pacchetti dannosi attraverso credenziali di pubblicazione compromesse.
Le verifiche da svolgere sui repository
Gli sviluppatori dovrebbero controllare i repository per la presenza di security-audit.yml e github_actions_security.yml, in particolare per modifiche avvenute dal 31 agosto 2026. Se uno dei due workflow è presente, la raccomandazione riportata dalla fonte è di trattare il caso come una compromissione.
Le azioni indicate comprendono la revoca della credenziale GitHub coinvolta, la rotazione dei segreti potenzialmente esposti, l’eliminazione del workflow dannoso da tutti i branch e il controllo dei fork infetti. Rimuovere soltanto il file dal ramo principale non basta se il workflow è ancora presente in altri branch o nei fork interessati.
FAQ
Quali segreti cerca il workflow malevolo?
Secondo l’analisi, raccoglie i segreti nominati di GitHub Actions e cerca nei file e nella cronologia Git credenziali AWS, token di servizi di controllo versione, chiavi API per servizi AI, cloud e SaaS.
Perché anche i fork possono essere pericolosi?
Un fork che eredita il workflow può eseguirlo quando Actions è abilitato e avviene un push. I fork privati possono contenere credenziali più sensibili rispetto ai repository pubblici.
Sono stati pubblicati pacchetti malevoli con token rubati?
No: la fonte afferma che, al momento della sua pubblicazione, non erano stati osservati rilasci dannosi firmati o pubblicati usando credenziali di pubblicazione compromesse.
Considerazioni finali
Il tratto più grave di questa operazione è l’uso dell’infrastruttura di automazione come strumento di raccolta: un workflow presentato come verifica di sicurezza può accedere sia ai segreti configurati per la CI/CD sia alla storia completa di un progetto. Non è quindi un problema limitato al singolo account violato, ma un rischio che può propagarsi lungo fork, mirror e repository collegati.
La distinzione tra file legittimi e file introdotti da un aggressore diventa decisiva quando il codice viene eseguito automaticamente a ogni push. In questo caso, la verifica dei due nomi di workflow e la rotazione delle credenziali in caso di rilevamento pesano più di qualsiasi rassicurazione: sono le misure direttamente indicate dalle analisi della campagna.