Tra il 12 e il 13 luglio 2026, attori di minaccia hanno trasformato la piattaforma di CI/CD più grande al mondo in un'infrastruttura di attacco distribuita. Compromettendo l'account di uno sviluppatore PHP legittimo, hanno iniettato 583 workflow malevoli in pacchetti open source che, una volta eseguiti sui runner Ubuntu ephemeral di GitHub, scaricavano payload per l'exploitation su larga scala di cPanel e WHM attraverso CVE-2026-41940.
- L'account GitHub di dinushchathurya, sviluppatore PHP e DevOps legittimo, è stato compromesso e utilizzato per distribuire workflow malevoli attraverso Packagist.
- I workflow risiedevano in
.github/workflows/, non nel codice PHP, sfruttando il fatto che GitHub ignora i workflow annidati invendor/durante l'installazione da pacchetto. - I runner Ubuntu ephemeral venivano convertiti in nodi di botnet con payload multi-architettura scaricati da un server C2 all'indirizzo IP 43[.]228[.]157[.]68.
- Le ricerche su GitHub hanno restituito circa 15.000-16.000 file corrispondenti, ma la fonte precisa che questi rappresentano file abbinati, non account o repository confermati come compromessi.
Come l'account di uno sviluppatore legittimo è diventato un ponte per 583 workflow malevoli
La compromissione ha preso di mira l'account GitHub di dinushchathurya, sviluppatore con attività nei settori PHP e DevOps. Packagist, il principale repository per pacchetti PHP, ha sincronizzato automaticamente versioni di sviluppo malevole su 10 pacchetti associati all'account. Ogni versione conteneva tra 55 e 62 workflow GitHub Actions, per un totale di 583 file.
Il meccanismo è insidioso: il codice PHP stesso era benigno, contenente solo dati di riferimento statici e funzioni di lookup ordinarie. L'attacco risiedeva interamente nella directory .github/workflows/. Secondo la fonte, "il codice PHP della libreria è benigno. Contiene dati di riferimento statici e funzioni di lookup ordinarie, senza hook di installazione malevoli, attività di rete, esecuzione di shell o comportamento al momento dell'importazione. Il codice di attacco risiede sotto .github/workflows/".
Una caratteristica architetturale di GitHub Actions ha protetto gli installatori del pacchetto: la piattaforma ignora i workflow annidati in vendor/. Questo significa che l'installazione via composer non attivava i workflow malevoli. L'esecuzione avveniva invece solo su push al repository compromesso o su trigger manuale, quando GitHub assegnava un runner Ubuntu ephemeral con connettività internet completa.
Il meccanismo tecnico: da runner CI a nodo di botnet in pochi secondi
Una volta attivato, il workflow rilevava l'architettura del processore del runner e scaricava il payload Linux corrispondente dal server C2 43[.]228[.]157[.]68 via HTTP. Gli endpoint esposti erano strutturati per architettura: /api/dl/386, /amd64, /arm, /arm64. Il payload AMD64, con hash SHA-256 22f7…81f1, eseguiva scanning internet-scale configurato con le porte standard di cPanel e WHM: 80, 443, 8080, 8443, 2082, 2083, 2086, 2087.
Il payload implementava funzionalità di infostealer: cercava credenziali AWS, token GitHub/GitLab, API OpenAI e Google, chiavi Stripe, credenziali SendGrid/Mailgun, informazioni database, dati SSH e remote Git. Un heartbeat loop inviava aggiornamenti ogni 30 secondi a /api/github-heartbeat con identificativo del repository. I risultati dello scanning venivano esfiltrati via POST a /api/github-results, con tracking degli offset per evitare duplicati.
"Gli operatori ripropongono i runner Ubuntu ospitati su GitHub come infrastruttura di attacco usa e getta per scanning su larga scala, exploitation e furto di credenziali" — Socket Researchers via GBHackers
La scala: da 6.100 a 16.000 file, ma i numeri nascondono un'incertezza
La ricerca con il DNSHook identifier unico ha restituito circa 6.100 workflow file corrispondenti. Ricerche più ampie, utilizzando indicatori multipli come l'indirizzo C2, gli argomenti dello scanner, i nomi dei file credenziali e l'endpoint heartbeat, hanno portato il totale a circa 15.000-16.000 file corrispondenti. La fonte è esplicita su un punto critico: "queste cifre rappresentano file abbinati piuttosto che account vittima confermati, poiché un singolo repository può ospitare molti workflow clonati e parte dell'infrastruttura è staging controllato dall'attaccante piuttosto che progetti compromessi".
Questa distinzione non è accademica. Significa che il conteggio include repository forkati, mirror e possibili infrastrutture di test gestite direttamente dagli attori di minaccia. Il numero effettivo di account legittimi compromessi rimane indeterminabile dalle fonti disponibili.
Perché è importante
Il dossier non verifica la claim secondo cui GitHub avrebbe restringuto il proprio programma bug bounty. Questo elemento del topic obbligatorio non è coperto da nessuna fonte disponibile.
Il brief non specifica come l'account dinushchathurya sia stato inizialmente compromesso: credential theft, supply chain precedente o altro vettore non sono documentati. Non è nemmeno chiaro se CVE-2026-41940 corrisponda a una vulnerabilità reale con advisory ufficiale, o se il numero sia stato attribuito dalle fonti senza verifica da parte di NVD o vendor primario. L'identità dell'attore di minaccia non è attribuita da nessuna fonte.
Non emergono dettagli su eventuali contromisure di GitHub oltre alla sospensione dell'account compromesso. La fonte non documenta misure correttive specifiche adottate dalla piattaforma per prevenire analoghi abusi strutturali.
La campagna espone una fragilità architetturale: la funzione di "free compute" con runner pubblici, combinata con la sincronizzazione automatica tra repository e registry di pacchetti, permette di convertire repository apparentemente legittimi in infrastruttura di attacco senza che il codice sorgente principale riveli anomalie. La detection tradizionale su pacchetto o codice fallisce perché la minaccia risiede nella configurazione CI/CD, non nel software distribuito.
Il confine trust di GitHub Actions: feature o vulnerabilità?
Il meccanismo di sicurezza che ignora i workflow in vendor/ è progettato per proteggere gli utenti da esecuzioni indesiderate durante l'installazione di dipendenze. Nella campagna documentata, questo stesso meccanismo è diventato un vettore di occultamento: i pacchetti apparivano benigni agli installatori, mentre il payload attivo risiedeva in una trust boundary che gli sviluppatori non controllano direttamente.
La piattaforma GitHub affronta qui una tensione strutturale. I runner pubblici sono progettati per eseguire codice arbitrario su infrastruttura cloud; l'abuso a scala industriale trasforma questa funzione legittima in un servizio di hosting per operazioni criminali. La sospensione di singoli account, documentata per dinushchathurya, non interrompe fork, mirror e infrastruttura C2 attiva che indicano campagna in corso.
Il rischio per le aziende con hosting cPanel/WHM è concreto: CVE-2026-41940 ha punteggio CVSS 9.8 secondo le fonti disponibili, con vettore di rete, complessità di attacco bassa e nessun privilegio richiesto. Per sviluppatori e maintainer open source, la minaccia è più sottile: i propri repository possono essere convertiti in infrastruttura di attacco senza alterazione del codice distribuito, rendendo la detection estremamente difficile per strumenti tradizionali.
Domande frequenti
Il pacchetto PHP installava malware sul mio computer?
No. I workflow in .github/workflows/ sono ignorati da GitHub quando il pacchetto risiede in vendor/. L'esecuzione avveniva solo sui runner cloud di GitHub, non sulle macchine degli sviluppatori che installavano il pacchetto.
I 16.000 file indicano 16.000 repository compromessi?
No. La fonte specifica che si tratta di file corrispondenti a ricerca, che includono workflow clonati, fork e possibili infrastrutture di staging controllate dall'attaccante. Il numero di account effettivamente compromessi non è determinabile.
Che fine ha fatto l'account compromesso?
L'account dinushchathurya è stato sospeso, ma la fonte rileva che fork, mirror e infrastruttura C2 restano attivi, indicando che la campagna prosegue.
Fonti
- https://gbhackers.com/github-actions-into-a-global-botnet/
- https://gbhackers.com/200-malicious-github-repositories-distributing-malware/
- https://socket.dev/blog/github-actions-abuse-powers-cpanel-and-whm-exploitation
- https://cdn.sanity.io/images/cgdhsj6q/production/d4ed4cca713e7d38eeadb82b66f04b17840d9862-1672x941.png?w=1600&q=95&fit=max&auto=format
- https://gbhackers.com/ai-driven-exploitation/
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.