Un workflow che si chiama «Security Audit» compare all’improvviso in un repository GitHub, firmato con l’identità del suo manutentore. Sembra un controllo di sicurezza, ma fa l’opposto: raccoglie password, token e chiavi di accesso e li spedisce a un server esterno. È la nuova ondata di GhostAction, una campagna che a ottobre 2026 ha cambiato passo: tra il 31 agosto e il 9 ottobre i repository colpiti e verificati sono almeno 790, e l’8 e il 9 ottobre una nuova raffica ha raggiunto decine di migliaia di repository.
Per chi sviluppa software, gestisce siti o automatizza il rilascio di applicazioni, la novità più grave è un’altra: il nuovo workflow non si limita a rubare i segreti configurati nel progetto, ma scava in tutta la cronologia di Git alla ricerca di credenziali che gli sviluppatori credevano di aver cancellato da tempo.
Cos’è GhostAction
GhostAction è stata documentata per la prima volta a settembre 2025, quando ha colpito 817 repository di 327 utenti GitHub e sottratto 3.325 segreti, tra cui token di PyPI, npm e DockerHub e chiavi AWS. Il meccanismo è semplice. Gli attaccanti entrano in possesso delle credenziali di un account GitHub, elencano tutti i repository su cui quell’account può scrivere e in ognuno inseriscono un file di workflow di GitHub Actions. Il commit porta il nome e l’identità della vittima e spesso finisce direttamente sul ramo principale, senza revisione.
Il workflow si avvia a ogni push o su richiesta manuale. A quel punto gira sui server di GitHub con accesso ai segreti del progetto, cioè proprio le chiavi che servono per pubblicare pacchetti, collegarsi ai server di produzione o accedere al cloud.
La nuova ondata del 2026
La campagna è tornata a fine estate. Tra il 31 agosto e il 30 settembre 2026 il workflow malevolo è stato inserito in 772 repository pubblici di 373 utenti e organizzazioni, con 2.577 segreti presi di mira. I più cercati sono chiavi SSH private e credenziali dei server di deploy (446), credenziali Azure (218) e credenziali dei registri di container. I dati vengono inviati in chiaro, via HTTP, all’indirizzo IP 193.32.204.199.
L’8 ottobre è comparsa una variante più aggressiva. Due account compromessi hanno inserito il file security-audit.yml in 346 repository in pochi minuti, compresi progetti fermi da circa dieci anni, fork e un repository di proprietà di Uber. L’inclusione di progetti abbandonati indica un’enumerazione automatica di tutto ciò che l’account poteva modificare, non una scelta mirata. Nelle ore successive gli account coinvolti sono diventati più di 500 e i repository toccati decine di migliaia.
| Periodo | Nome del file | Cosa ruba |
|---|---|---|
| Set. 2025 | github_actions_security.yml | Segreti di GitHub Actions con nome noto |
| 31 ago – 30 set 2026 | github_actions_security.yml, security-check.yml | Segreti di GitHub Actions con nome noto |
| Dall’8 ott 2026 | security-audit.yml | Segreti, credenziali nei file e in tutta la cronologia Git |
| Metà ott 2026 | lint.yml, ci-check.yml, audit.yml e altri | Come sopra, più wiki del progetto e un ladro di credenziali per VS Code |
Come funziona il nuovo workflow
Il file security-audit.yml combina tre raccoglitori. Il primo legge i segreti di GitHub Actions di cui conosce il nome: gli attaccanti li ricavano in anticipo dai workflow legittimi del progetto, perché un workflow non può elencare i segreti ma può usarli se ne conosce il nome. Il secondo cerca nei file del repository stringhe che somigliano a credenziali: chiavi AWS, token di GitHub, GitLab, Google, Slack e SendGrid, chiavi API di OpenAI, Anthropic e OpenRouter. Il terzo fa la stessa ricerca in tutta la cronologia.
Per farlo il workflow scarica il repository con l’opzione fetch-depth: 0, che recupera tutta la storia dei commit invece della sola versione recente, e poi esegue git log -p –all, analizzando fino a 200.000 righe. Accanto alle chiavi AWS salva anche le due righe vicine, dove spesso si trova la chiave segreta corrispondente. Ogni esecuzione invia almeno il nome del repository, quindi funziona anche come segnale per gli attaccanti che il progetto è attivo.
Qui sta il punto più delicato. Molti sviluppatori, accorgendosi di aver salvato per errore una password nel codice, la cancellano con un nuovo commit e considerano chiuso il problema. Ma Git conserva tutte le versioni precedenti: la credenziale resta leggibile nella cronologia finché non viene revocata o la storia non viene riscritta. GhostAction va a prenderla proprio lì.
La seconda fase: VS Code e un font finto
A metà ottobre la campagna ha aggiunto una seconda fase che sopravvive alla rimozione del workflow. Gli attaccanti inseriscono nel repository un file .vscode/tasks.json e un falso file di font, public/fonts/fa-solid-400.woff2. Quando uno sviluppatore apre il progetto in Visual Studio Code, l’attività configurata avvia un programma che ruba credenziali dal computer e installa un cron job che ogni cinque minuti esegue i comandi inviati dal server degli attaccanti.
Nella stessa ondata compare un secondo workflow con nomi sempre diversi (lint.yml, ci-check.yml, build-check.yml, repo-health.yml, audit.yml, code-review.yml, test-suite.yml), che legge anche la wiki del progetto e, se l’invio diretto fallisce, carica i dati in un gist segreto. Alcuni proprietari che avevano già ripulito i repository sono stati colpiti di nuovo sei giorni dopo, perché non avevano revocato l’accesso usato dagli attaccanti.
Perché riguarda anche le piccole aziende
GitHub Actions non è uno strumento solo per i grandi progetti open source. Viene usato per pubblicare siti, aggiornare applicazioni web e PWA, distribuire gestionali e collegarsi in automatico a server e servizi cloud. I segreti salvati nei workflow sono spesso le chiavi di casa: accesso SSH al server di produzione, credenziali del database, token per pubblicare pacchetti, chiavi dei servizi di AI pagati a consumo.
Una chiave API di un servizio di AI rubata si traduce in costi addebitati al proprietario. Una chiave SSH rubata apre la porta del server. Un token di pubblicazione permette di distribuire una versione modificata di un pacchetto a tutti quelli che lo usano. Per questo un singolo account compromesso diventa un problema per l’intera catena di fornitura del software.
Come capire se sei stato colpito
- cercare nei propri repository file in .github/workflows/ con i nomi github_actions_security.yml, security-check.yml o security-audit.yml comparsi dal 31 agosto 2026;
- cercare l’indirizzo 193.32.204.199 nei workflow e nei log delle esecuzioni;
- controllare i commit con messaggi come «Add security audit workflow», «Add Github Actions Security workflow» o «Add security check workflow»;
- verificare la presenza di .vscode/tasks.json e public/fonts/fa-solid-400.woff2 non aggiunti da te;
- leggere il registro di sicurezza dell’account GitHub cercando accessi e token che non riconosci.
Se trovi uno di questi file, va trattato come una violazione confermata: ogni segreto configurato e ogni credenziale presente nella cronologia è stato offerto agli attaccanti.
Cosa fare subito
L’ordine delle operazioni conta. Prima si toglie l’accesso agli attaccanti, poi si pulisce:
- da un computer pulito, revocare tutte le sessioni GitHub, i token personali, le autorizzazioni OAuth, le chiavi SSH e le deploy key, cambiare la password e attivare un secondo fattore resistente al phishing;
- conservare i file malevoli, i log delle esecuzioni e i commit, utili per capire cosa è uscito;
- rimuovere i workflow e i file aggiunti da tutti i rami e da tutti i fork;
- ruotare ogni segreto di GitHub Actions e ogni credenziale mai finita nella cronologia, anche se cancellata;
- controllare pacchetti, immagini, rilasci e deploy prodotti nel periodo della compromissione, oltre all’attività sugli account cloud.
Come prevenire
Le linee guida di GitHub sulla sicurezza di Actions indicano il principio del privilegio minimo per token e segreti e la revisione del codice dei workflow. A questo si aggiungono alcune misure mirate: proteggere i rami principali in modo che nessun commit arrivi senza revisione, richiedere l’approvazione per ogni modifica ai file in .github/workflows, limitare le connessioni in uscita dei runner ai soli indirizzi necessari, usare dove possibile credenziali temporanee al posto di chiavi permanenti e attivare la scansione dei segreti sui repository. L’approvazione obbligatoria delle modifiche ai workflow ha bloccato l’esfiltrazione nei progetti che l’avevano attivata.
Il nostro consiglio
Una credenziale finita nel codice va considerata esposta per sempre, anche dopo averla cancellata: l’unica correzione vera è revocarla e crearne una nuova. Conviene fare oggi un inventario dei segreti usati nei workflow, eliminare quelli inutili, ridurre i permessi degli altri e proteggere gli account GitHub di tutti i collaboratori con l’autenticazione a due fattori. Se gestisci siti, PWA o gestionali con rilascio automatico e vuoi una verifica dei tuoi repository e delle pipeline, possiamo aiutarti.
In breve
- GhostAction usa account GitHub compromessi per inserire workflow malevoli travestiti da controlli di sicurezza.
- Almeno 790 repository verificati fino al 9 ottobre 2026, poi decine di migliaia nella raffica dell’8-9 ottobre.
- La nuova variante cerca credenziali anche in tutta la cronologia Git.
- Una seconda fase usa VS Code e un finto font per installare un ladro di credenziali.
- Togliere il workflow non basta: bisogna revocare gli accessi e ruotare tutti i segreti.
Fonti
- OpenSourceMalware – GhostAction Attack Escalates By Targeting GitHub Users
- OpenSourceMalware – GhostAction Copycats PolinRider by Hiding a Stealer in a Fake Font File
- Socket – New GhostAction Wave Hits Hundreds of Repos
- StepSecurity – GhostAction Returns
- GitGuardian – GhostAction Returns: 772 Repos Hit
- GitGuardian – The GhostAction Campaign: 3,325 Secrets Stolen (2025)
- GitHub Docs – Security hardening for GitHub Actions
