In sintesi
Una nuova ondata GhostAction trasforma un account di maintainer compromesso in uno strumento di raccolta massiva di segreti. L'attaccante inserisce un file di workflow chiamato security-audit.yml (o simile) in ogni repository su cui l'account ha permessi di scrittura. Quando viene eseguito, invia i segreti Actions del repository e qualsiasi chiave cloud, AI o SaaS presente nella cronologia git a un indirizzo IP fisso, in HTTP in chiaro.
Per ogni team che gestisce build e rilasci con GitHub Actions la lezione è semplice. Un segreto che sia mai stato committato, anche anni fa e poi cancellato, va considerato esposto se un workflow del genere ha potuto girare. Prima si ruota, poi si ripulisce la cronologia.
Cosa è successo l'8 ottobre?
Secondo StepSecurity, l'attaccante ha usato prima l'account di Takashi Kitao per inserire il workflow malevolo in 27 repository. Circa otto ore dopo l'account di Henry Wu è stato usato per inserire lo stesso file in 318 repository, per lo più fork, nell'arco di 16 minuti. Entrambe le ondate erano automatizzate: un commit per repository, che aggiunge o modifica un singolo file di workflow dal nome innocuo.
Socket, che ha analizzato la stessa ondata in modo indipendente, ha contato 346 repository colpiti, tra cui uber/athenadriver e kitao/pyxel. Il 9 ottobre il file era ancora presente sul branch predefinito di diversi repository verificati. Al momento della stesura Socket non aveva rilevato versioni malevole di pacchetti pubblicate su PyPI o crates.io, ma i token rubati lo renderebbero possibile. The Hacker News, citando Socket, parla di oltre 500 account compromessi e decine di migliaia di repository dal 7 ottobre.
Cosa ruba il workflow malevolo?
Le ondate precedenti di GhostAction raccoglievano i segreti nominati che i workflow di un repository richiamano, come i token di pubblicazione per PyPI, npm e Docker Hub. GitGuardian ha contato 3.325 segreti rubati in questo modo nella campagna originale del 2025. La nuova versione mantiene questo meccanismo e aggiunge un secondo passaggio: esegue il checkout del repository con fetch-depth: 0, lancia git log -p --all e passa al setaccio l'intera cronologia con espressioni regolari.
I pattern coprono le chiavi di accesso AWS (comprese le chiavi STS temporanee), le chiavi API di Anthropic, OpenAI e OpenRouter, i personal access token di GitHub e GitLab, le chiavi Google, Firebase e GCP e le credenziali di Slack e SendGrid. Una chiave committata per errore nel 2022 e rimossa al commit successivo resta quindi a rischio. I risultati viaggiano in chiaro: chiunque osservi il percorso di rete può leggerli a sua volta.
Cosa cambia per i team software negli Stati Uniti e nell'UE
Primo: il bersaglio è la pipeline, non il codice. All'attaccante non serve una vulnerabilità nella vostra applicazione. Basta un solo token di maintainer con permessi di scrittura per eseguire codice nella vostra CI con i vostri segreti. I team che revisionano ogni pull request applicativa ma lasciano cambiare i workflow senza revisione hanno messo i controlli più forti nel posto sbagliato. Le regole per .github/workflows dovrebbero essere almeno rigide quanto quelle sulla configurazione di produzione della vostra infrastruttura cloud e DevOps.
Secondo: le chiavi API dell'AI sono ormai un bottino di valore. Il workflow cerca le chiavi di Anthropic, OpenAI e OpenRouter insieme alle credenziali cloud. Una chiave di modello esposta è una fattura diretta e, per i team che inviano dati dei clienti ai modelli, un rischio di accesso ai dati. Queste chiavi vanno tenute in un secret manager con limiti di spesa e chiavi distinte per ambiente, non in file .env che finiscono nei commit.
Terzo: per i regolatori è un incidente, non manutenzione. Se una chiave cloud rubata poteva raggiungere dati personali, possono scattare i termini di notifica del GDPR; NIS2, DORA e SOC 2 si aspettano tutti una rotazione documentata dei segreti e una revisione degli accessi. Un registro datato dei repository controllati, delle esecuzioni avvenute e delle chiavi ruotate è esattamente ciò che chiederà un auditor.
Cosa significa per le aziende italiane?
In Italia il rischio si concentra dove le chiavi sono state trattate per anni come semplice configurazione: software house e system integrator che gestiscono decine di repository per conto dei clienti, PMI che hanno integrato in fretta le API di AI generativa, fork di progetti open source mantenuti a mano. Il ragionamento «abbiamo tolto la chiave dal codice, siamo a posto» non regge più: solo la revoca presso il fornitore chiude davvero l'accesso. Per chi lavora con la pubblica amministrazione la questione pesa doppio, perché gli stessi repository spesso contengono credenziali verso ambienti che trattano dati dei cittadini.
Sul piano normativo, se una chiave esposta dava accesso a dati personali, l'articolo 33 del GDPR impone di norma la notifica della violazione al Garante privacy entro 72 ore. I soggetti che rientrano nella NIS2, recepita con il D.Lgs. 138/2024, hanno inoltre obblighi di notifica verso lo CSIRT Italia dell'ACN, con una prima segnalazione entro 24 ore. E dall'11 settembre 2026 il Cyber Resilience Act obbliga i fabbricanti di prodotti con elementi digitali a segnalare al CSIRT competente e all'ENISA gli incidenti gravi che incidono sulla sicurezza del prodotto: una pipeline di rilascio compromessa può rientrare in questo caso. Documentate fin da subito verifiche, rotazioni e decisione sulla notifica.
Cosa fare adesso?
- Cercare i file. Cercate nella vostra organizzazione
security-audit.yml,github_actions_security.yml,security-check.ymle l'IP 193.32.204.199 nei file di workflow, compresi fork e repository archiviati. - Controllare i log delle esecuzioni. Individuate le esecuzioni Actions dal 7 ottobre che non avete avviato. Se il workflow è girato, considerate perso ogni segreto che poteva leggere.
- Prima ruotare, poi ripulire. Ruotate i segreti Actions esposti e qualsiasi chiave comparsa nella cronologia git. Riscrivere la cronologia non annulla un furto già avvenuto.
- Blindare le modifiche ai workflow. Richiedete la revisione dei code owner per
.github/workflows, proteggete i branch predefiniti e limitate account e token autorizzati a fare push. - Ridurre ciò che un job può rubare. Usate credenziali cloud a breve durata tramite OIDC al posto delle chiavi permanenti, legate i segreti agli environment e impostate il
GITHUB_TOKENpredefinito in sola lettura.
Domande frequenti
Che cos'è la campagna GhostAction?
GhostAction è un attacco alla supply chain contro GitHub Actions comparso a settembre 2025. Gli attaccanti usano account di sviluppatori compromessi per aggiungere un file di workflow che invia i segreti del repository a un server sotto il loro controllo. Una nuova ondata, l'8 ottobre 2026, ha usato gli account dell'autore di pyxel e dell'autore originale di athenadriver di Uber per colpire circa 345 repository.
Come capisco se il mio repository è stato colpito?
Cercate nei vostri repository, fork compresi, file di workflow chiamati security-audit.yml, github_actions_security.yml o security-check.yml e l'indirizzo IP 193.32.204.199. Poi esaminate i log di GitHub Actions dal 7 ottobre 2026 alla ricerca di esecuzioni che non avete avviato. Se il workflow malevolo è stato eseguito, i suoi segreti vanno considerati rubati.
Basta cancellare dal codice una chiave esposta?
No. La nuova variante legge l'intera cronologia git con git log -p --all, quindi una chiave committata e poi cancellata può ancora essere trovata. Revocate prima la chiave presso il fornitore, poi rimuovetela dalla cronologia se necessario.
Quali credenziali cerca il workflow?
Raccoglie i segreti GitHub Actions usati dai workflow del repository e cerca nel codice e nella cronologia chiavi AWS, chiavi API di Anthropic, OpenAI e OpenRouter, token GitHub e GitLab, chiavi Google, Firebase e GCP e credenziali Slack e SendGrid.
Bisogna notificare il Garante privacy?
Dipende da cosa permettevano di raggiungere le chiavi rubate. Se potevano essere esposti dati personali, l'articolo 33 del GDPR impone di norma la notifica al Garante entro 72 ore; i soggetti NIS2 hanno anche obblighi di notifica verso lo CSIRT Italia. In ogni caso documentate verifiche e decisione.
Come prevenire attacchi simili?
Richiedete la revisione dei code owner per ogni modifica in .github/workflows, proteggete i branch predefiniti, imponete un'autenticazione forte agli account dei maintainer, impostate il GITHUB_TOKEN predefinito in sola lettura, legate i segreti agli environment e sostituite le chiavi cloud permanenti con credenziali OIDC a breve durata.
Fonti
StepSecurity — GhostAction Returns: Malicious “Security Audit” Workflows Now Mine Credentials from Entire Git Histories
Socket — New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials
The Hacker News — Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories
GitGuardian — The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows