GhostAction travolge GitHub: 1.900 account e 30.000 repository nel mirino

🛡️ Executive Summary

• GhostAction ha compromesso circa 1.900 account GitHub e raggiunto oltre 30.000 repository appartenenti a 3.000 utenti e organizzazioni.
• Il nuovo payload cerca credenziali non soltanto nei secret CI/CD e nei file correnti, ma anche nell’intera cronologia Git.
• GitGuardian conta 3.174 tentativi di estrazione di segreti: il numero non equivale automaticamente a 3.174 credenziali valide effettivamente sottratte.

GhostAction ha accelerato sulla supply chain di GitHub trasformando account reali di sviluppatori in vettori per rubare segreti da decine di migliaia di repository. GitGuardian stima che la nuova ondata abbia compromesso circa 1.900 account, raggiunto oltre 30.000 repository appartenenti a 3.000 utenti e organizzazioni e tentato di estrarre 3.174 segreti dalle pipeline CI. Il dato più importante non è però il volume: il nuovo payload non si limita più ai secret esposti al workflow, ma scava nella cronologia Git alla ricerca di credenziali cancellate dal codice ma mai realmente revocate. È il punto in cui un incidente sull’identità dello sviluppatore diventa un problema di cloud, package registry, API AI e software supply chain.

GhostAction trasforma account reali in un vettore contro GitHub Actions

La ricerca originale di GitGuardian ricostruisce un’accelerazione tra l’8 e il 9 ottobre 2026, preceduta da una nuova attività iniziata il 31 agosto. Gli aggressori ottengono accesso in scrittura ai repository attraverso Personal Access Token rubati o credenziali provenienti da infostealer, quindi inseriscono workflow GitHub Actions con nomi rassicuranti come Security Audit o GitHub Actions Security. Il file malevolo viene eseguito dentro l’infrastruttura CI e usa il contesto legittimo del repository per cercare token GitHub e GitLab, chiavi AWS, credenziali cloud, token npm, PyPI e DockerHub e API key dei provider AI. La dinamica è diversa dai repository esca: qui non serve convincere un utente a scaricare un file, perché l’attaccante entra in un account reale e modifica direttamente il processo di automazione.

Leggi anche: FakeGit riattiva 17.610 repository GitHub senza crearne di nuovi

Il nuovo payload ruba anche i segreti cancellati dalla cronologia Git

Il salto tecnico della nuova ondata consiste nella scansione della cronologia completa. Il workflow esegue ricerche sui file correnti ma analizza anche git log e patch storiche, recuperando stringhe che possono essere scomparse dal branch attuale mesi prima. La terza variante osservata aggiunge perfino contesto attorno agli identificatori AWS per provare ad associare access key e secret key.

Cancellare una credenziale da un commit, quindi, non equivale a invalidarla. Se la chiave rimane attiva, GhostAction può recuperarla dal passato del repository e trasformarla in un accesso presente. È la stessa fragilità già emersa con Shai-Hulud, che aveva cercato 469 percorsi utilizzati da ambienti AI, cloud e CI/CD per conservare segreti.

I 3.174 segreti non equivalgono automaticamente a 3.174 credenziali rubate

GitGuardian precisa che i 3.174 segreti rappresentano tentativi di estrazione, non 3.174 credenziali sicuramente valide e successivamente riutilizzate. Questa distinzione è fondamentale. GitHub ha iniziato a impedire l’esecuzione dei workflow malevoli dal 9 ottobre e le ondate osservate il 10 e il 12 ottobre non sarebbero riuscite a completare l’esfiltrazione attraverso lo stesso meccanismo.

Parte delle vittime, tuttavia, era già comparsa nelle precedenti campagne del settembre 2025 e dell’agosto 2026. Il ritorno sugli stessi account indica che l’attaccante scommette su remediation incomplete, token non ruotati o accessi rimasti validi dopo la rimozione del workflow.

Eliminare security-audit.yml non chiude l’incidente

Per un’organizzazione il problema non finisce quindi cancellando security-audit.yml. Se un account maintainer è stato compromesso, bisogna ricostruire quali repository poteva modificare, quali workflow sono stati eseguiti e quali secret risultavano accessibili a quei job. Le credenziali individuabili nella storia Git devono essere considerate esposte anche se non compaiono più nel codice corrente. Vanno ruotati PAT, chiavi cloud, token dei package registry e API key AI potenzialmente accessibili, insieme alla revoca delle sessioni dell’account compromesso. Dove possibile, l’uso di credenziali statiche dovrebbe essere ridotto a favore di identità federate e token a vita breve, perché un secret che scade rapidamente riduce il valore di un archivio storico rubato.

GitHub Actions diventa il moltiplicatore del privilegio rubato

L’altra difesa riguarda l’autorità concessa ai workflow. Branch protection, review obbligatorie sulle modifiche sotto .github/workflows, permessi minimi del GITHUB_TOKEN e controllo dell’egress dei runner possono limitare quanto un account compromesso riesca a fare in pochi minuti. Il precedente degli attacchi supply chain contro GitHub Actions aveva già mostrato che un componente apparentemente fidato può ereditare i privilegi della pipeline. GhostAction aggiunge un passaggio ulteriore: invece di avvelenare soltanto una dipendenza, usa l’identità legittima del maintainer per installare direttamente il raccoglitore di segreti. La scala della campagna sposta infine il problema dall’incidente GitHub al rischio aziendale. Un token sottratto da un repository può aprire un registry npm, una pipeline Docker, un tenant cloud o un account AI utilizzato dall’organizzazione. Da quel punto l’attaccante può cercare nuove credenziali e nuove identità, trasformando il repository nel primo nodo di una catena molto più ampia. È per questo che GhostAction va letto insieme alla crescita degli attacchi contro sviluppatori, package manager e coding agent: il bersaglio non è più il codice in sé, ma la fiducia operativa accumulata attorno a chi può modificarlo e distribuirlo.

Continua con:
GitHub e PyPI introducono difese temporali contro la supply chain
GitHub Actions usate come infrastruttura offensiva distribuita

La bonifica deve partire dagli account e dalle chiavi

La risposta efficace parte dall’identità e dai secret, non dal file malevolo. Repository e workflow devono essere cercati per gli indicatori pubblicati da GitGuardian, ma ogni organizzazione che riconosce un account coinvolto deve assumere che la cronologia Git sia stata interrogata e che le credenziali trovate possano essere state copiate. Il vero danno di GhostAction è proprio questo: rende pericolosi anche segreti che gli sviluppatori pensavano di avere eliminato. Se una chiave è comparsa una volta nel repository e non è mai stata revocata, per l’attaccante continua a essere una chiave valida.