Il 27 luglio 2026 entrerà in vigore la restructurazione del programma bug bounty di GitHub, che riduce i payout pubblici e crea un tier VIP invito-only. Nello stesso arco temporale, una campagna attiva ha trasformato GitHub Actions in una botnet distribuita per attacchi a server di hosting, sfruttando repository compromessi e workflow malevoli con comando e controllo attivo. La coincidenza cronologica mette a fuoco una contraddizione operativa: mentre GitHub restringe l'accesso umano alla sua superficie di attacco, la sua infrastruttura automatizzata viene abusata su scala globale.
- GitHub ha annunciato una riduzione dei payout pubblici del bug bounty effettiva dal 27 luglio 2026: i critical scendono da 30.000 a 10.000 dollari, con un tier VIP invito-only che mantiene almeno 30.000 dollari per critical.
- Una campagna attiva converte GitHub Actions in botnet globale: workflow malevoli in repository compromessi scaricano payload multi-architettura da un C2 attivo all'IP 43.228.157.68.
- Il vettore d'attacco non è nel codice dei pacchetti PHP distribuiti — che restano innocui — ma nei file di workflow in .github/workflows/, eseguiti su runner Ubuntu effimeri di GitHub.
- La campagna ha distribuito 583 workflow file malevoli e indicatori che ricerche su GitHub associano a circa 6.100-16.000 file corrispondenti, con heartbeat verso il C2 ogni 30 secondi.
Il taglio del bounty: meno pubblico, più esclusivo
La fonte cita cifre precise per il nuovo sistema. I payout pubblici scendono a 250 dollari per low severity (precedentemente 500-1.000 dollari), 2.000 dollari per medium (da 2.000-5.000), 5.000 dollari per high (da 5.000-20.000) e 10.000 dollari per critical (da 10.000-30.000). Il tier VIP invito-only mantiene payout più alti: almeno 30.000 dollari per critical, con accesso riservato a ricercatori con storia di report validi.
La motivazione ufficiale, espressa da Catherine Cassell, Product Security Engineer di GitHub, è la riduzione del "rumore" generato da report AI-generati e low-effort. Nuovi ricercatori dovranno soddisfare il "signal requirement" di HackerOne, con quattro opportunità iniziali per dimostrare la qualità dei loro report.
"These changes are about two things: reducing the noise so we can focus on the signal, and building a program that serious researchers find rewarding to participate in." — Catherine Cassell, GitHub Product Security Engineer
La riduzione del bounty pubblico e la creazione di un tier esclusivo rappresentano una scommessa operativa: meno report, ma da ricercatori con track record provato. La fonte non specifica se questa restructurazione sia correlata alla campagna botnet attiva sulla stessa piattaforma.
Come funziona la botnet su GitHub Actions
La campagna documentata dalla fonte primaria sfrutta una separazione architetturale di GitHub Actions: i file di workflow in .github/workflows/ sono versionati nel repository ma eseguiti su infrastruttura GitHub, non sull'ambiente dell'utilizzatore finale. Questo crea una trust boundary abusabile: il codice "venduto" come pacchetto PHP su Packagist è innocuo, ma i workflow attivati su push o trigger manuale eseguono operazioni malevoli sui runner di GitHub.
I dieci pacchetti compromessi — tutti associati all'account dinushchathurya, ora sospeso — contengono complessivamente 583 workflow file malevoli distribuiti across le versioni di sviluppo, con una densità di 55-62 workflow per pacchetto. L'attivazione avviene su eventi specifici (push o manual trigger), non sull'installazione via Composer, il che rende il vettore meno immediato ma più persistente: il repository compromesso continua a ospitare payload eseguibili finché rimane online.
I runner Ubuntu effimeri di GitHub scaricano il payload dal server di comando e controllo all'indirizzo IP 43.228.157.68, raggiungibile via HTTP su path specifici per architettura: /api/dl/386, /api/dl/amd64, /api/dl/arm, /api/dl/arm64. Il download avviene con curl o wget e flag permissivi. Il payload AMD64, con hash SHA-256 22f7...81f1, implementa uno scanner per la vulnerabilità CVE-2026-41940 (CVSS 9.8 CRITICAL) orientato a sistemi cPanel/WHM.
Il C2 implementa un heartbeat ogni 30 secondi verso /api/github-heartbeat e un endpoint di esfiltrazione a /api/github-results. L'enumerazione include dati Git, variabili d'ambiente e altre informazioni dal contesto di esecuzione. Il meccanismo trasforma risorse computazionali legittime e temporanee in nodi di una botnet distribuita geograficamente, con rotazione automatica degli IP sorgente per ogni esecuzione di workflow.
La scala: tra file corrispondenti e false positive
La fonte riporta due cifre per la diffusione dei workflow correlati. Ricerche su GitHub per l'identificatore DNSHook hanno trovato circa 6.100 workflow file corrispondenti. Ricerche più ampie con altri indicatori associano la campagna a circa 15.000-16.000 file. Questi numeri non indicano repository compromessi in senso stretto: includono fork, mirror, staging e potenziali false positive. La fonte non quantifica l'impatto effettivo in termini di server compromessi o credenziali rubate.
L'account originale dinushchathurya è stato sospeso, ma la campagna è considerata in corso: il C2 resta attivo, fork e mirror sopravvivono alla rimozione dell'account originale, e l'infrastruttura di GitHub Actions fornisce continuamente nuovi nodi effimeri. La persistenza non è nel malware installato su disco — i runner sono effimeri — ma nella replicabilità del workflow attraverso il fork di repository compromessi.
Perché è importante
Il dossier non specifica se GitHub sia a conoscenza della campagna botnet al momento dell'annuncio della restructurazione bounty. Non documenta misure correttive specifiche adottate contro i workflow malevoli oltre alla sospensione dell'account identificato. Non è confermata l'identità dell'attore dietro la campagna, né esistono sovrapposizioni infrastrutturali che colleghino l'operatore a gruppi di minaccia noti allo stato attuale.
La fonte non quantifica il numero di vittime reali tra i server cPanel/WHM target dello scanner. Non è chiaro se la vulnerabilità CVE-2026-41940 sia presente in database pubblici al momento dell'analisi: il dossier la riporta con CVSS 9.8 CRITICAL ma non fornisce verifica da NVD o advisory ufficiale del vendor.
La dissonanza operativa resta il dato più solido: GitHub sta restringendo il canale umano di segnalazione vulnerabilità mentre la sua infrastruttura automatizzata subisce un abuso sistemico. Per le aziende che usano GitHub Actions, la fonte non specifica controlli preventivi oltre all'audit generico dei workflow in repository propri e dipendenze.
La contraddizione tra controllo dei ricercatori e perdita di controllo dell'infrastruttura
La restructurazione del bug bounty e la campagna botnet non sono causalmente collegate nei documenti disponibili. Tuttavia, la loro coincidenza cronologica solleva una questione strutturale per le piattaforme di sviluppo: il filtro su chi può segnalare problemi non risolve il filtro su cosa viene eseguito nell'infrastruttura stessa. GitHub sta investendo risorse di moderazione sulla frontiera umana del bounty, mentre la frontiera automatizzata di Actions presenta un'area d'attacco più ampia e più difficile da contenere con processi manuali.
Per i ricercatori di sicurezza, la contrazione dei payout pubblici e l'alzata del "signal requirement" riducono le opportunità economiche per talenti emergenti. Per il settore, la tensione tra democratizzazione della security research — assistita dall'AI — e necessità di qualità rischia di espellere competenze prima che possano maturare. La fonte non fornisce dati sul volume effettivo di report AI-generati che ha motivato la restructurazione.
La campagna botnet dimostra invece che l'automazione malevola può sfruttare l'automazione legittima senza competere per le stesse risorse di attenzione umana. I workflow malevoli non richiedono report di bug bounty, né approvazione di moderatori: richiedono solo repository pubblici e trigger di esecuzione.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://www.theregister.com/devops/2026/07/23/github-slashes-public-bug-bounty-payouts-as-ai-report-flood-buries-its-security-team/5277046
- https://gbhackers.com/github-actions-into-a-global-botnet/
- https://www.techradar.com/pro/security/github-restructures-bug-bounty-program-following-flood-of-ai-generated-reports
- https://www.theregister.com/security
- https://www.theregister.com/cyber_crime
- https://www.theregister.com/patches
- https://www.theregister.com/research
- https://www.theregister.com/cso