GitHub sotto attacco: wfx colpisce 8.093 repository e cancella le tracce del malware

🛡️ Executive Summary

• La campagna wfx ha inserito commit malevoli in 8.093 repository GitHub. SafeDep documenta anche 61.879 pull request di ricognizione associate a 4.833 account.
• Il malware prende di mira credenziali e segreti delle pipeline CI/CD. Gli attaccanti modificano i workflow GitHub Actions oppure introducono script npm postinstall, per poi ripristinare i file originali.
• Il rischio supera la compromissione del repository. Il payload tenta di creare accessi persistenti su AWS e Azure, che possono sopravvivere alla semplice rotazione delle credenziali.

Una campagna malevola denominata wfx ha modificato almeno 8.093 repository GitHub tra il 10 e il 12 novembre 2026, utilizzando credenziali sottratte agli sviluppatori per inserire codice destinato al furto di segreti e accessi cloud. L’operazione, inizialmente segnalata da Aikido Security e approfondita da SafeDep, sfrutta principalmente i workflow GitHub Actions, trasformando le normali procedure di compilazione e distribuzione del software in possibili strumenti di esfiltrazione. La caratteristica più insidiosa riguarda la cancellazione delle tracce: dopo aver inserito il payload, gli attaccanti ripristinano quasi sempre i file attraverso nuovi commit, lasciando apparentemente pulito il ramo principale. Il numero dei repository modificati non equivale però a quello delle esecuzioni del malware confermate, distinzione indispensabile per valutare correttamente l’impatto della campagna.

wfx utilizza token GitHub rubati per modificare migliaia di repository

Secondo la ricerca pubblicata da SafeDep il 12 novembre, gli attaccanti hanno inserito commit malevoli in 8.093 repository tra il 10 novembre alle 12:46 UTC e il 12 novembre alle 04:36 UTC. L’attività risultava ancora in corso durante la rilevazione. Prima di introdurre il malware viene spesso aperta una pull request denominata docs: dependency audit notes, proveniente dal ramo wfx-docs, per verificare se le credenziali disponibili consentano di scrivere nel repository. La ricerca ha individuato 61.879 pull request di questo tipo, distribuite in 61.734 repository e associate a 4.833 account. I commit vengono attribuiti agli utenti reali, generalmente attraverso indirizzi GitHub noreply, perché l’operazione sfrutta token già compromessi. È un meccanismo affine a quello osservato nella campagna Gheist, che aveva utilizzato account violati e GitHub Actions per sottrarre segreti.

Leggi anche: GhostAction travolge GitHub: 1.900 account e 30.000 repository nel mirino

Il malware entra nei workflow GitHub Actions e negli script npm

SafeDep identifica tre modalità di inserimento del payload. La più diffusa consiste nella modifica di workflow GitHub Actions esistenti, osservata in 7.309 repository. In altri 771 casi viene introdotto uno script npm postinstall, capace di attivarsi durante l’installazione delle dipendenze quando gli script sono eseguiti. Nei repository vuoti gli aggressori possono invece creare direttamente un nuovo workflow, soluzione osservata in 16 casi. I file malevoli utilizzano nomi apparentemente ordinari e commit come ci: refresh build cache oppure chore: add ci helper.

Una volta avviato, il workflow richiede accesso ai token runtime di GitHub Actions e tenta di trasferire al payload le variabili e i segreti disponibili nel contesto di esecuzione. Dopo pochi minuti vengono introdotti commit come ci: restore e ci: cleanup per rimuovere le modifiche. Questo comportamento richiama la campagna Megalodon, che aveva utilizzato migliaia di workflow GitHub compromessi per colpire la supply chain, ma non dimostra un collegamento operativo tra i responsabili.

wfx cerca credenziali AWS, Azure, GCP e chiavi degli sviluppatori

Il payload è progettato per raccogliere token GitHub, variabili CI/CD, credenziali dei servizi cloud e chiavi API, comprese quelle utilizzate con OpenAI e Anthropic. Cerca inoltre configurazioni AWS, chiavi SSH e GnuPG, credenziali Kubernetes, file .env, Terraform state e informazioni presenti nella memoria dei processi. I dati possono essere inviati attraverso richieste HTTP verso server controllati dagli attaccanti oppure tramite Telegram. Tra gli indicatori pubblicati da SafeDep compaiono 194.150.166[.]244, 18.143.168[.]96 e 153.75.82[.]159. Il codice tenta anche di ottenere token OIDC per accedere a AWS, Azure e Google Cloud, oltre a verificare possibili utilizzi contro Vault e Kubernetes. La presenza di queste capacità nel malware non significa che ogni tentativo sia riuscito: l’esito dipende dai permessi effettivamente disponibili nel repository e dalle relazioni di fiducia configurate nei servizi esterni.

Le backdoor cloud possono sopravvivere alla rotazione dei segreti

La componente più pericolosa di wfx riguarda i tentativi di persistenza negli ambienti cloud. Su AWS il malware prova a creare nuove access key e modificare le policy di fiducia dei ruoli, utilizzando sessioni con prefisso wfx-. In Azure può aggiungere credenziali federate denominate wfx-ci- alle registrazioni delle applicazioni Entra. Questi meccanismi potrebbero permettere nuovi accessi anche dopo la sostituzione delle password o dei client secret originariamente compromessi. L’operazione dimostra perché la sicurezza delle pipeline non possa limitarsi alla protezione del codice sorgente: un workflow modificato può raggiungere sistemi esterni utilizzando le autorizzazioni legittimamente assegnate al progetto. Il problema era già emerso negli attacchi alla supply chain di GitHub Actions che avevano coinvolto SpotBugs, reviewdog e tj-actions.

Tre pacchetti contaminati non equivalgono a tre infezioni automatiche

SafeDep ha individuato il payload anche in versioni pubblicate di tre progetti: digitalelvis/neuronai-studio 3.14.3 su Packagist, github.com/vkuznet/gocurl nella pseudo-versione v0.0.0-20261111095532-8d5aad0cb0da e github.com/onuragtas/redock nelle versioni 1.0.278, 1.0.280 e 1.0.282. La precisazione tecnica è essenziale: un normale composer install o go get non esegue automaticamente il payload contenuto nei workflow GitHub. Nel caso di neuronai-studio, l’esecuzione richiede l’attivazione dello specifico hook npm presente nel progetto. Per gocurl e redock, i workflow contaminati non risultavano eseguiti nelle condizioni analizzate. Rimane comunque necessario evitare le versioni indicate, soprattutto negli ambienti che compilano o distribuiscono software a partire da sorgenti compromessi. L’episodio si inserisce nel problema più ampio degli script postinstall e delle difese introdotte nell’ecosistema npm.

Continua con: GitHub Actions riattiva Mini Shai-Hulud: i tag malevoli erano ancora lì

Come verificare la compromissione e bonificare i repository

Un repository apparentemente pulito non esclude un’esecuzione precedente del malware. Le organizzazioni devono esaminare la cronologia dei commit, le pull request wfx-docs, i workflow GitHub Actions e le esecuzioni avvenute durante la finestra di esposizione. Se emerge una modifica riconducibile alla campagna, occorre revocare i token dell’account utilizzato, controllare le autorizzazioni OAuth e SSH e ruotare i segreti effettivamente accessibili al repository. Devono essere analizzati anche gli ambienti cloud: CloudTrail per individuare nuove chiavi o modifiche ai ruoli AWS, Entra ID per cercare credenziali federate wfx-ci- e i log GCP per eventuali operazioni sui token. Le macchine sulle quali è stato eseguito un hook npm compromesso richiedono verifiche specifiche. La lezione di wfx è che cancellare il commit malevolo non cancella necessariamente gli accessi ottenuti dall’attaccante: la bonifica deve coinvolgere identità, pipeline e infrastrutture cloud collegate.