GitHub sotto attacco: wfx-loot compromette 4.837 account e colpisce oltre 61.000 repository

In sintesi

• 4.837 account GitHub compromessi e 61.764 repository raggiunti. La campagna wfx-loot utilizza credenziali rubate per inserire codice malevolo nei progetti accessibili alle vittime.
• Almeno 1.835 repository hanno eseguito il payload secondo il bilancio iniziale. Il malware sottrae segreti GitHub Actions, credenziali AWS, Azure e Google Cloud, token AI e informazioni dai runner CI/CD.
• Gli attaccanti cancellano rapidamente le proprie tracce. Workflow temporanei, registri eliminati e meccanismi di persistenza rendono insufficiente una semplice rotazione delle password.

Una nuova campagna informatica sta colpendo GitHub su scala industriale, trasformando migliaia di account compromessi in strumenti per rubare credenziali dalle infrastrutture di sviluppo software. La ricerca pubblicata il 12 novembre 2026 da Oliver Smith di Aikido Security documenta l’operazione wfx-loot, iniziata il 10 novembre e capace di raggiungere 61.764 repository attraverso 4.837 account GitHub compromessi. Secondo i dati raccolti dagli analisti, almeno 1.835 repository hanno eseguito il codice malevolo con conseguente esfiltrazione di credenziali. Il bersaglio principale non è il codice sorgente, ma l’insieme di segreti utilizzati dalle pipeline GitHub Actions per autenticarsi a servizi cloud, pubblicare pacchetti e amministrare infrastrutture. L’attaccante sfrutta autorizzazioni già disponibili, inserisce temporaneamente workflow malevoli e cancella rapidamente le tracce. L’operazione presenta inoltre sovrapposizioni con la precedente campagna GhostAction, pur mostrando caratteristiche che suggeriscono operatori differenti.

wfx-loot sfrutta 4.837 account per raggiungere oltre 61.000 repository

L’attacco parte da credenziali GitHub già compromesse, utilizzate per accedere ai repository sui quali gli account possiedono permessi di scrittura. A partire dalle 12:45 UTC del 10 novembre, gli operatori hanno aperto pull request con il titolo docs: dependency audit notes, utilizzando un branch denominato wfx-docs. Questa prima attività funziona come una verifica dei privilegi disponibili e precede l’eventuale inserimento del payload. Le ricerche condotte da Aikido individuano 61.839 pull request associate alla campagna, mentre il conteggio dei repository distinti raggiunti è pari a 61.764.

Almeno 10.431 pull request hanno interessato repository non appartenenti direttamente agli account compromessi, raggiunti attraverso autorizzazioni di collaborazione o appartenenza a organizzazioni. Il 92% delle richieste risultava ancora aperto al momento dell’analisi. Aikido indica almeno 1.835 repository con esecuzione del malware nel riepilogo iniziale, mentre una successiva sezione tecnica riporta 1.806 esecuzioni identificate: due rilevazioni dello stesso monitoraggio, non numeri da sommare. Il precedente più vicino è GhostAction, che aveva raggiunto oltre 30.000 repository attraverso circa 1.900 account compromessi.

Tre modalità di infezione e cancellazione delle tracce in meno di un minuto

wfx-loot utilizza tre differenti modalità per inserire il codice malevolo nei repository. La prima modifica un workflow GitHub Actions esistente attraverso un commit denominato ci: refresh build cache, aggiungendo circa 1.500 righe di script. La seconda introduce uno script shell temporaneo e un hook postinstall nel file package.json, che permette l’esecuzione del malware durante un’installazione npm. La terza crea un workflow autonomo all’interno di .github/workflows/, utilizzando branch temporanei con nomi apparentemente ordinari.

La fase successiva consiste nel ripristino quasi immediato del repository. Secondo Aikido, gli attaccanti annullano le modifiche entro un minuto e cancellano l’esecuzione GitHub Actions insieme ai relativi log. Il repository può quindi apparire normale a un controllo superficiale, nonostante il malware abbia già raccolto le informazioni disponibili. Un indizio importante è rappresentato dai numeri mancanti nella sequenza delle esecuzioni dei workflow. Un meccanismo simile di abuso delle automazioni era stato documentato nell’operazione Gheist, caratterizzata da oltre 13.500 branch malevoli e centinaia di account GitHub compromessi.

Leggi anche: Megalodon compromette migliaia di repository GitHub e sottrae credenziali dalle pipeline

GitHub Actions diventa una miniera di credenziali cloud e token AI

Il payload analizzato da Aikido è uno script shell di circa 1.500 righe, organizzato in quattro fasi: raccolta, escalation, persistenza ed esfiltrazione. La prima fase cerca segreti e variabili GitHub Actions, GITHUB_TOKEN, token OIDC, credenziali AWS, Azure e Google Cloud, oltre a configurazioni Docker, Kubernetes, SSH, Terraform, Vault, npm e PyPI. Lo script esamina anche file .env, certificati e cronologie dei comandi, arrivando a interrogare l’ambiente e la memoria dei processi GitHub Actions per recuperare ulteriori credenziali.

Particolare attenzione viene riservata ai servizi di intelligenza artificiale. Il malware cerca token e chiavi associati a OpenAI, Anthropic, Gemini, Hugging Face, Cursor, Copilot e Codex, insieme ad altri strumenti utilizzati dagli sviluppatori. Nei runner self-hosted può raccogliere anche metadati cloud, informazioni sui container e configurazioni di sistema. Il comportamento conferma l’estensione della superficie già descritta nell’analisi su Shai-Hulud e sulla ricerca automatizzata di centinaia di percorsi contenenti credenziali AI e cloud.

AWS, Azure e Google Cloud: il malware tenta di ampliare i privilegi

wfx-loot non si limita a copiare password e token. Lo script contiene procedure per utilizzare le credenziali recuperate e ottenere ulteriori autorizzazioni. Su AWS può assumere ruoli IAM raggiungibili attraverso gli accessi disponibili e tentare la creazione di nuove chiavi persistenti. Su Google Cloud può utilizzare chiavi di service account per produrre token e impersonare altre identità. Su Azure può sfruttare token OIDC, credenziali applicative e sessioni precedentemente memorizzate per raggiungere servizi amministrativi e Key Vault.

La persistenza comprende anche tentativi di modificare le trust policy AWS e aggiungere nuove identità federate alle applicazioni Azure, consentendo potenzialmente accessi successivi anche dopo la sostituzione dei segreti originali. Aikido descrive inoltre una tecnica per pubblicare controlli di stato GitHub falsamente positivi, sfruttando i privilegi disponibili per superare determinate protezioni dei branch. Queste capacità dipendono dalle autorizzazioni presenti nell’ambiente compromesso: non significano che ogni repository raggiunto abbia subito automaticamente un’escalation di privilegi.

Esfiltrazione verso due server e contaminazione dei pacchetti software

Nella configurazione osservata, il malware invia i dati raccolti attraverso richieste HTTP POST verso due indirizzi: 194.150.166[.]244:8080/exfil e 18.143.168[.]96:8080/exfil. Lo script contiene ulteriori funzionalità per trasferire informazioni attraverso cache, artifact e riepiloghi GitHub Actions, ma Aikido precisa che questi canali alternativi non risultavano attivi nella configurazione distribuita. L’assenza di artifact sospetti non permette quindi di escludere una compromissione.

La campagna ha raggiunto anche alcuni ecosistemi di distribuzione software. Aikido identifica digitalelvis/neuronai-studio versione 3.14.3 su Packagist e il modulo Go github.com/onuragtas/docker-env nelle versioni 1.0.278 e 1.0.280. Nel caso Go, il payload si trova esclusivamente nei file GitHub Actions: codice Go e binari pubblicati non risultano modificati, quindi la semplice compilazione del modulo non implica l’esecuzione del malware. La propagazione attraverso la pubblicazione automatica appare una conseguenza dell’attacco alle pipeline, non il suo obiettivo principale. Il rischio delle automazioni era già emerso con le GitHub Actions compromesse che avevano riattivato payload Mini Shai-Hulud attraverso tag malevoli.

GhostAction e wfx-loot condividono account compromessi, non necessariamente gli autori

Aikido ha individuato sovrapposizioni tra gli account colpiti da wfx-loot e quelli utilizzati nella campagna GhostAction di ottobre. In oltre cento repository il nuovo malware è stato inserito all’interno di workflow precedentemente alterati da GhostAction. Il collegamento dimostra che alcune credenziali compromesse continuano a circolare e possono essere sfruttate da più operatori, ma non costituisce una prova che le due campagne siano gestite dagli stessi responsabili.

Gli analisti ritengono anzi probabile la presenza di attori differenti, considerando infrastrutture, strumenti e procedure operative. Alcune varianti recenti contengono commenti in lingua indonesiana, ma neppure questo elemento permette un’attribuzione geografica affidabile. La coincidenza degli account è compatibile con il riutilizzo di credenziali rubate e con la circolazione degli accessi nei mercati criminali.

Come individuare wfx-loot e bonificare i repository coinvolti

La verifica deve partire dagli indicatori pubblicati da Aikido: pull request docs: dependency audit notes, branch wfx-docs, commit ci: refresh build cache e chore: add ci helper, oltre ai branch temporanei chore/ e ai workflow aggiunti nelle directory GitHub Actions. Gli amministratori devono controllare cronologie Git, esecuzioni mancanti, audit log, modifiche ai workflow e accessi degli account coinvolti, senza considerare rassicurante la scomparsa dei file malevoli. Una pull request di sondaggio indica che l’account utilizzato per aprirla era già compromesso, anche quando non risulta un’esecuzione successiva del payload.

Quando il malware è stato eseguito, Aikido raccomanda di considerare compromessi tutti i segreti accessibili al workflow. Occorre revocare token GitHub, credenziali cloud e chiavi applicative, verificare ruoli IAM e identità federate, controllare eventuali persistenze su Azure e AWS e ricostruire la catena di pubblicazione dei pacchetti. La rotazione dei segreti da sola può risultare insufficiente qualora siano stati creati nuovi meccanismi di accesso. Anche la progressiva introduzione di controlli più restrittivi sulla pubblicazione dei pacchetti npm attraverso GitHub Actions dimostra quanto sia necessario ridurre i privilegi delle automazioni.

Continua con: GhostAction, migliaia di account GitHub e repository coinvolti

Le pipeline CI/CD diventano un bersaglio centrale della criminalità informatica

wfx-loot dimostra che compromettere un account GitHub può essere sufficiente per raggiungere infrastrutture cloud, applicazioni e sistemi di distribuzione software senza sfruttare una vulnerabilità tradizionale. Gli attaccanti utilizzano autorizzazioni legittime, introducono codice per pochi secondi e sfruttano le credenziali che gli sviluppatori hanno affidato alle automazioni. I numeri raccolti da Aikido descrivono una campagna estesa, ma distinguono chiaramente i repository raggiunti da quelli nei quali è stata osservata l’esecuzione del malware. La priorità non è soltanto recuperare i repository compromessi: è impedire che un singolo token rubato possa diventare una chiave di accesso all’intera infrastruttura aziendale.