AnswersPublished25 sources
wfx-loot, la campagna che ha messo nel mirino 61.764 repository GitHub
wfx loot ha sfruttato credenziali GitHub rubate, non una vulnerabilità di GitHub Actions, per sondare 61.764 repository. Aikido riporta l’esecuzione del payload e il furto di credenziali in almeno 1.835 repository; alcune fonti citano una stima precedente di 1.806.
Pubblicato daModificato con GPT-6 LunaImmagini generate con GPT Image 2
Research answer
Key takeaways
- wfx loot ha sfruttato credenziali GitHub rubate, non una vulnerabilità di GitHub Actions, per sondare 61.764 repository.
- Aikido riporta l’esecuzione del payload e il furto di credenziali in almeno 1.835 repository; alcune fonti citano una stima precedente di 1.806.
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: What was the wfx-loot GitHub credential-theft campaign reported by Aikido Security, when did it begin and how long was it active, how did at. Article summary: wfx-loot was a mass CI credential-theft campaign that used valid stolen GitHub credentials—not a GitHub Actions vulnerability—to place secret-stealing code in repositories the compromised accounts could write to. Aikido . Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
wfx-loot è stata una campagna di furto di credenziali che ha sfruttato account GitHub compromessi per sondare i repository e, dove gli account disponevano dei permessi di scrittura, inserire codice progettato per sottrarre segreti dagli ambienti di integrazione continua (CI). Aikido ha riferito di 4.837 account compromessi e di richieste di modifica (pull request) inviate a 61.764 repository; nel suo conteggio pubblicato, il payload è stato eseguito e le credenziali sono state esfiltrate da almeno 1.835 repository.4
9
Quando è avvenuta la campagna e quanto è durata?
L’attività è iniziata intorno alle 12:45 UTC del 10 novembre 2026. Un resoconto colloca la finestra delle pull request di sondaggio fino alle 15:00 UTC dell’11 novembre: circa 26 ore e 15 minuti.6
7 Si tratta del periodo osservato per i tentativi di sondaggio, non della conferma che in quel momento siano cessate tutte le esecuzioni del payload o l’eventuale uso successivo delle credenziali rubate.
Le cifre della campagna si riferiscono a fasi diverse:
- 4.837 account risultano compromessi.
- 61.764 repository hanno ricevuto pull request di sondaggio. È il numero dei repository verificati, non quello dei repository in cui è accertata l’esecuzione del malware.
- Nel conteggio pubblicato da Aikido, il payload è stato eseguito e le credenziali sono state esfiltrate da almeno 1.835 repository.
9
Alcuni resoconti pubblicati nello stesso periodo riportavano una cifra inferiore: 1.806.6
10 Le fonti disponibili non chiariscono la differenza: è quindi meglio considerare i due numeri come conteggi riportati separatamente, senza sommarli o trattarli come equivalenti. Le informazioni fornite non confermano neppure la successiva affermazione di circa 1.970 casi pubblici confermati su oltre 66.000 obiettivi.
Come gli aggressori hanno verificato l’accesso
Gli aggressori hanno aperto pull request con il titolo docs: dependency audit notes, usando branch chiamati wfx-docs. Erano richieste di sondaggio: servivano a verificare se un account compromesso avesse i permessi per scrivere nel repository interessato.3
4
9
Quando i permessi lo consentivano, gli aggressori inserivano nell’ambiente CI un payload in grado di sottrarre segreti. La campagna si basava su credenziali valide rubate, non su una vulnerabilità di GitHub Actions.4
9 OX Security ha descritto il malware come un unico script shell di circa 1.500 righe.
31
Secondo alcuni resoconti, in determinati casi le modifiche malevole e i log dei workflow sono stati rimossi, complicando le indagini.1
6 Le informazioni disponibili supportano il quadro generale — sondaggio degli accessi, esecuzione del payload e successiva pulizia — ma non dimostrano che ogni modalità di distribuzione o messaggio di commit segnalato sia stato usato in tutte le infezioni.
Quali credenziali cercava il payload
L’obiettivo documentato era raccogliere le credenziali accessibili ai job CI, inclusi i segreti di GitHub Actions e le credenziali cloud. I resoconti descrivono anche tentativi di ottenere token per servizi di intelligenza artificiale.3
9 Nell’analisi di OX Security sono elencate credenziali per AWS, Azure e Google Cloud.
31 Altre fonti riferiscono che il malware poteva cercare segreti nella memoria dei processi in esecuzione sul runner; gli estratti disponibili, tuttavia, non indicano quanto spesso questo metodo abbia avuto successo.
17
29
Un riepilogo consultato descrive tentativi di estendere l’accesso tramite modifiche alle policy di trust di AWS e credenziali federate di Azure.5 Questi dettagli vanno considerati comportamenti segnalati, non la prova che siano stati modificati tutti i repository colpiti o tutti gli account cloud collegati. Le evidenze riguardano il furto di credenziali: non dimostrano il furto di codice sorgente o di database dei clienti.
9
15
Cosa indicano — e cosa non dimostrano — i segnali disponibili
Un resoconto riferisce che il 92% delle 10.431 pull request di sondaggio inviate tramite accessi da collaboratori o organizzazioni era ancora aperto al momento della verifica.10
19 Questo suggerisce che molte richieste non erano state gestite entro quel momento, ma non dimostra che i proprietari dei repository o i team di sicurezza non le avessero individuate. La percentuale non riguarda necessariamente tutte le pull request della campagna.
Un playbook investigativo segnala inoltre 173 pull request di sondaggio provenienti da 19 account e inviate tramite token della GitHub App di Fly.io. Questo dato, da solo, non prova che l’infrastruttura di Fly.io sia stata violata né che il payload sia stato eseguito in tutti i repository raggiunti attraverso quei token.37
Cosa dovrebbero verificare i team di sicurezza
Se la tua organizzazione potrebbe essere stata coinvolta, distingui nell’analisi dell’incidente tra repository sondato, payload inserito, payload eseguito e credenziali esfiltrate. Sono fasi diverse e non vanno confuse.
- Cerca gli indicatori di sondaggio. Controlla le pull request intitolate
docs: dependency audit notese i branchwfx-docsnei repository a cui gli account interessati potevano scrivere. - Esamina i log CI e di audit. Verifica le esecuzioni dei workflow, i commit, l’attività dei branch e i log cloud disponibili. Numeri mancanti nelle esecuzioni dei workflow possono essere un indizio, perché alcuni resoconti parlano di esecuzioni e log eliminati; una lacuna, da sola, non prova una compromissione.
1
24
- Revoca gli accessi a rischio. Revoca i token GitHub sospettati di essere compromessi e rivedi gli accessi di account, collaboratori e GitHub App.
- Ruota in modo esteso i segreti esposti. Se il payload è stato eseguito, considera potenzialmente compromessi i segreti e i ruoli cloud accessibili al workflow, non soltanto le credenziali visibili nei log rimasti.
3
- Cerca eventuali modifiche persistenti nel cloud. Controlla cambiamenti inattesi alle policy di trust di AWS e alle applicazioni o credenziali federate di Azure, oltre a chiavi non autorizzate e altre modifiche agli accessi.
5
- Conserva le prove. Salva i log e i dati di audit ancora disponibili prima di intervenire per ripulire l’ambiente, quindi documenta quali fasi dell’attacco sono effettivamente supportate dalle evidenze.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "wfx-loot, la campagna che ha messo nel mirino 61.764 repository GitHub"?
wfx loot ha sfruttato credenziali GitHub rubate, non una vulnerabilità di GitHub Actions, per sondare 61.764 repository.
What are the key points to validate first?
wfx loot ha sfruttato credenziali GitHub rubate, non una vulnerabilità di GitHub Actions, per sondare 61.764 repository. Aikido riporta l’esecuzione del payload e il furto di credenziali in almeno 1.835 repository; alcune fonti citano una stima precedente di 1.806.
Sources
bleepingcomputer.comHackers compromise 4,800 GitHub accounts to steal cloud credentials
al-ice.aiProbe, Payload, Vanish: 4,837 Hijacked GitHub Accounts Fed a CI Secret Stealer Across 61,764 Repositories
unbiasedheadlines.comStolen Logins for 4,837 GitHub Accounts Used to Run Secret Stealer in at Least 1,806 Repositories, Researchers Say