GitHub Actions diventa una botnet mentre GitHub restringe il bug bounty

🛡️ Executive Summary

• Migliaia di workflow malevoli trasformano i runner GitHub Actions in nodi temporanei per scansione, exploit ed esfiltrazione contro server cPanel e WHM.
• La campagna sfrutta CVE-2026-41940 per raccogliere token Git, credenziali cloud, chiavi SSH, password database e segreti di servizi esterni.
• GitHub riduce le ricompense pubbliche e crea un programma VIP per privilegiare segnalazioni ad alto impatto rispetto ai report AI di bassa qualità.

Una campagna su larga scala ha trasformato GitHub Actions in un’infrastruttura distribuita per colpire server cPanel e WHM esposti a internet. Gli attaccanti hanno compromesso repository, inserito centinaia di workflow YAML e sfruttato i runner temporanei forniti da GitHub per eseguire scanner, tentare l’exploitation di CVE-2026-41940 e sottrarre credenziali dai sistemi raggiunti. L’indagine è partita da pacchetti Packagist apparentemente contaminati, ma ha rivelato che il codice PHP non rappresentava il vettore di esecuzione. Nello stesso momento GitHub ha ristrutturato il proprio bug bounty, riducendo le ricompense pubbliche e introducendo un circuito VIP destinato ai ricercatori capaci di produrre vulnerabilità realmente significative.

I pacchetti PHP nascondevano un attacco ai workflow

L’indagine è iniziata da dieci pacchetti Packagist associati a un legittimo sviluppatore PHP e DevOps. Tra il 12 e il 13 luglio 2026, il servizio aveva sincronizzato automaticamente nuove versioni di sviluppo provenienti dai repository GitHub collegati. Ogni versione conteneva tra 55 e 62 file GitHub Actions malevoli, per un totale di 583 workflow. Una prima lettura poteva suggerire una classica compromissione della supply chain PHP, nella quale l’installazione del pacchetto esegue codice malevolo sul computer dello sviluppatore o sul server applicativo.

L’analisi ha invece mostrato che le librerie PHP restavano sostanzialmente innocue: non contenevano script di installazione, chiamate di rete o funzioni per eseguire shell command. La componente offensiva si trovava sotto .github/workflows e diventava operativa soltanto quando quei file occupavano la radice di un repository controllato dall’attaccante. Un’installazione ordinaria tramite Composer li avrebbe collocati nella directory vendor, dove GitHub non li interpreta come workflow del progetto principale. Anche clonare localmente il repository non avrebbe avviato automaticamente l’attacco. L’esecuzione avveniva invece dopo un push o mediante avvio manuale di GitHub Actions, dimostrando come un artefatto possa apparire malevolo senza colpire direttamente chi lo installa. La distinzione è essenziale nelle campagne di supply chain che sfruttano repository e sistemi di automazione anziché il codice della dipendenza.

GitHub Actions forniva una rete distribuita di server Linux

Ogni workflow chiedeva a GitHub di creare un runner Ubuntu temporaneo, rilevava l’architettura del processore e scaricava da un server esterno il payload Linux corrispondente. Gli attaccanti distribuivano versioni per x86, AMD64, ARM e ARM64, permettendo alla stessa infrastruttura di adattarsi a differenti ambienti. Una volta avviato, il programma scansionava in modo continuo indirizzi internet alla ricerca delle porte normalmente utilizzate da cPanel e WHM, compresi i servizi web amministrativi esposti su 2082, 2083, 2086 e 2087. Il runner non era quindi il bersaglio finale, ma una risorsa computazionale gratuita e usa e getta fornita dalla piattaforma.

La natura effimera dei sistemi riduceva la persistenza degli indicatori locali e permetteva alla campagna di distribuire l’attività tra numerosi indirizzi appartenenti all’infrastruttura GitHub. I workflow potevano essere attivati su ogni push, creando nuovi nodi ogni volta che un repository compromesso riceveva una modifica. Questo modello estende il concetto di cloud abuse: invece di acquistare server o compromettere una botnet tradizionale, gli operatori utilizzavano l’automazione CI/CD di progetti legittimi come motore per scansione ed exploitation. La tecnica conferma che i workflow GitHub e le pipeline di sviluppo sono ormai una superficie di attacco autonoma, capace di produrre effetti su sistemi completamente esterni al repository compromesso.

CVE-2026-41940 apriva cPanel e WHM ai ladri di segreti

Il payload tentava di sfruttare CVE-2026-41940, una vulnerabilità di bypass dell’autenticazione nei pannelli cPanel e WHM. La distinzione tra i due livelli rende l’attacco particolarmente pericoloso. cPanel controlla file, database, email e configurazioni appartenenti a un singolo account di hosting, mentre WHM opera come piano di amministrazione superiore e può gestire più clienti sullo stesso server. Compromettere un account cPanel permette di raggiungere un sito o un’applicazione; ottenere accesso a WHM può esporre decine o centinaia di domini ospitati sulla stessa infrastruttura. Dopo l’exploitation, lo scanner cercava variabili d’ambiente, repository Git, file di configurazione, database, chiavi SSH e credenziali utilizzate da servizi esterni.

Tra i dati ricercati figuravano token GitHub e GitLab, chiavi AWS, credenziali OpenAI e Google, segreti Stripe, SendGrid e Mailgun, accessi ai database e configurazioni capaci di consentire ulteriore esecuzione remota. Non si trattava quindi di una campagna limitata al furto dei pannelli di hosting. L’obiettivo era raccogliere identità tecniche riutilizzabili per compromettere cloud, repository, sistemi di pagamento, posta transazionale e nuove applicazioni. I token del controllo versione rappresentavano un premio particolarmente importante, perché avrebbero permesso di conquistare altri repository e inserire nuovi workflow, creando un ciclo autoalimentato tra server vulnerabili, credenziali rubate e ulteriore abuso della supply chain. La falla si inserisce nella successione di vulnerabilità cPanel sfruttate attivamente contro infrastrutture di hosting.

Migliaia di file mostrano una campagna ancora più vasta

I dieci pacchetti Packagist rappresentavano soltanto una parte visibile dell’operazione. La ricerca di un identificativo DNSHook utilizzato dai workflow ha restituito circa 6.100 file corrispondenti su GitHub. Query più ampie basate sull’indirizzo del server di comando, sui parametri dello scanner, sui nomi dei file esfiltrati e sugli endpoint di heartbeat hanno individuato tra 15.000 e 16.000 file simili. Questi valori non equivalgono al numero dei repository compromessi. Uno stesso progetto può contenere decine di workflow duplicati, GitHub può raggruppare file identici e alcuni account potrebbero appartenere direttamente agli attaccanti. La presenza dello stesso codice in progetti con storie di sviluppo non correlate conferma però che la campagna superava ampiamente il singolo maintainer. I workflow inviavano continuamente segnali di attività al server degli operatori e caricavano in modo incrementale i risultati appena prodotti, riducendo il rischio di perdere dati quando il runner veniva terminato. L’infrastruttura esterna manteneva separati download del payload, heartbeat ed esfiltrazione, consentendo agli attaccanti di aggiornare lo scanner senza modificare migliaia di file YAML. La sospensione di un account o la rimozione di una serie di workflow interrompe soltanto una parte del sistema: fork, mirror, repository già compromessi e token sottratti possono continuare ad alimentare l’operazione. I proprietari dei progetti devono quindi verificare la cronologia delle modifiche sotto .github/workflows, conservare i log Actions, revocare credenziali e applicazioni OAuth sospette e controllare eventuali consumi anomali dei runner.

La protezione deve partire dai permessi della pipeline

Un repository compromesso non dovrebbe poter diventare automaticamente una piattaforma di scansione internet e furto di credenziali. Le organizzazioni devono richiedere revisioni obbligatorie per ogni modifica ai workflow, proteggere i branch principali e assegnare ownership specifica alla directory .github/workflows. Il token GITHUB_TOKEN deve ricevere soltanto i permessi indispensabili, mentre l’accesso ai segreti deve essere separato tra ambienti di sviluppo, test e produzione. I runner self-hosted richiedono un isolamento ancora maggiore, perché un workflow ostile potrebbe raggiungere reti interne, cache, credenziali persistenti e servizi non esposti pubblicamente. Anche i runner ospitati da GitHub devono essere monitorati sul piano dell’egress: download di eseguibili da indirizzi IP diretti, connessioni verso endpoint non approvati e scansioni su grandi intervalli di rete non appartengono a una normale pipeline di compilazione. Per cPanel e WHM, l’applicazione della patch deve essere accompagnata dallo script di rilevamento degli indicatori fornito dal vendor, dalla verifica delle sessioni amministrative e dalla rotazione dei segreti presenti sui sistemi rimasti esposti. Aggiornare il pannello chiude il bypass iniziale, ma non revoca token, chiavi cloud e credenziali già raccolti. Il rischio maggiore della campagna risiede proprio nella sua capacità di trasformare un singolo server compromesso in nuove opportunità contro repository e servizi esterni.

GitHub riduce il bug bounty pubblico e crea una corsia VIP

Mentre GitHub Actions veniva abusato come infrastruttura offensiva, GitHub ha annunciato una ristrutturazione profonda del proprio Bug Bounty Program. La piattaforma attribuisce la modifica alla crescita della coda di segnalazioni e all’aumento dei report di bassa qualità, spesso generati o amplificati attraverso strumenti AI. Dal 27 luglio 2026, il programma pubblico adotterà ricompense fisse: 250 dollari per le vulnerabilità low, 2.000 per le medium, 5.000 per le high e 10.000 per le critical. Le cifre risultano inferiori rispetto a quelle previste nel nuovo programma privato VIP, destinato ai ricercatori capaci di produrre risultati consistenti e ad alto impatto. Nella corsia riservata, una vulnerabilità low vale 1.000 dollari, una medium 7.500, una high 20.000 e una critical almeno 30.000 dollari. Per ottenere l’invito occorre avere segnalato almeno una falla critica, due alte, quattro medie oppure sette basse riconosciute dal programma. GitHub introduce inoltre un requisito minimo di “signal” su HackerOne: chi non possiede ancora una reputazione sufficiente potrà inviare fino a quattro segnalazioni iniziali per dimostrare la qualità del proprio lavoro. La società sostiene che il cambiamento non chiuda il programma ai nuovi ricercatori, ma sposti gli incentivi dalla quantità alla profondità. La decisione arriva dopo la gestione di vulnerabilità importanti, come la RCE nella pipeline git push corretta da GitHub in meno di due ore, e riflette la difficoltà di distinguere scoperte originali da report duplicati, teorici o generati automaticamente.

La sicurezza GitHub affronta due forme opposte di automazione

La campagna contro cPanel e la ristrutturazione del bug bounty mostrano due conseguenze differenti della stessa trasformazione. Da un lato, l’automazione CI/CD permette agli attaccanti di creare rapidamente migliaia di nodi operativi e sfruttare risorse legittime per colpire sistemi esterni. Dall’altro, strumenti AI e scanner automatici aumentano il volume delle segnalazioni inviate ai programmi di sicurezza, costringendo i vendor a introdurre filtri reputazionali e corsie privilegiate. GitHub deve ridurre gli abusi senza compromettere la natura aperta della piattaforma: workflow, fork, Actions e repository pubblici sono essenziali per lo sviluppo collaborativo, ma possono essere trasformati in una rete distribuita di attacco. Allo stesso modo, un bug bounty aperto consente a nuovi ricercatori di emergere, ma può diventare ingestibile quando il costo di valutare migliaia di report supera il valore delle vulnerabilità reali. La risposta non può limitarsi a bloccare più account o ridurre le ricompense: deve aumentare la qualità del controllo sui workflow, rendere visibile l’uso anomalo dei runner e costruire sistemi capaci di riconoscere rapidamente il segnale tecnico dentro una quantità crescente di automazione offensiva e difensiva.