Megalodon ha trasformato GitHub Actions in una backdoor per 5.561 repo

Una campagna automatizzata ha pubblicato 5.718 commit su 5.561 repository GitHub in sei ore, un lunedì di maggio. I commit sembravano normale manutenzione CI (“ci: add build optimization step”, “build: improve ci performance”, “chore: optimize pipeline runtime”) e arrivavano da autori dai nomi anonimi: build-bot, auto-ci, pipeline-bot. Quando la mattina del 18 maggio è finita, ognuno di quei repository conteneva un file di workflow con un payload bash codificato in base64.

La campagna si chiama Megalodon. Il team di ricerca di SafeDep l’ha resa pubblica il 21 maggio, dopo aver smontato i commit e seguito la traccia degli artefatti fino a un unico server di comando e controllo all’indirizzo 216.126.225.129:8443. La parte interessante non è che GitHub abbia subito un attacco. La parte interessante è che l’aggressore non ha avuto bisogno di compromettere GitHub. Ha usato GitHub Actions, il sistema CI/CD progettato proprio per garantire l’integrità del codice, come veicolo di consegna della backdoor.

Due workflow, uno di massa e uno dormiente

Megalodon ha operato in due modalità. La variante di massa aggiungeva un file di workflow nuovo chiamato SysDiag che si attivava a ogni push e a ogni pull request, raccogliendo tutto ciò che ci passava attraverso. La variante mirata, Optimize-Build, faceva qualcosa di più paziente: sostituiva un workflow esistente con un trigger workflow_dispatch, che resta dormiente finché qualcuno non lo invoca a mano. Una backdoor che dorme nella directory CI di un progetto è molto più difficile da notare di un workflow nuovo chiamato SysDiag, perché la maggior parte dei manutentori non controlla un file che ha scritto lui stesso.

Quando il workflow parte, il payload legge tutto ciò che riesce a raggiungere nell’ambiente CI. Variabili d’ambiente CI. Chiavi di accesso, chiavi segrete e token di sessione AWS. Token di accesso GCP. Chiavi SSH private. Credenziali .npmrc. Configurazioni Docker. Configurazioni Kubernetes. Token OIDC di GitHub Actions, che permettono all’aggressore di impersonare il workflow stesso davanti a qualsiasi account cloud per cui era autorizzato. Prima di uscire, il payload cerca nel codice del repository più di trenta pattern di segreti diversi (chiavi di API, password, frammenti di certificati) nel caso qualche umano ne avesse incollato uno. Gli endpoint di metadati di AWS IMDSv2, GCP e Azure vengono interrogati per ottenere l’identità della macchina nel cloud.

Una pipeline che spedisce la propria backdoor

La vittima più grave finora è Tiledesk, una piattaforma open source di customer engagement i cui nove repository GitHub sono stati colpiti. Tra il 19 e il 21 maggio, Tiledesk ha pubblicato il suo pacchetto tiledesk-server su npm con la backdoor compilata dentro. Le versioni dalla 2.18.6 alla 2.18.12 di @tiledesk/tiledesk-server portano adesso il codice del payload, installato da ogni sviluppatore che ha eseguito npm install in quella finestra. Quella è la leva per cui Megalodon è stato costruito: mettere una backdoor in un progetto open source perché la sua pipeline di release ne metta in centinaia di progetti dipendenti.

Black-Iron-Project ha perso otto repository. Centinaia di progetti più piccoli (account di singoli sviluppatori, cluster universitari, sandbox abbandonate) ne hanno presi uno o due ciascuno. L’aggressore non sembrava scegliere. Il pattern è stato l’ampiezza al posto della precisione: account usa-e-getta con nomi casuali di otto caratteri che pubblicavano messaggi di commit identici minuto dopo minuto. Il server C2 registrava in silenzio ciò che tornava indietro.

Perché i file CI sono sopravvissuti all’audit

Questo attacco ha funzionato per lo stesso motivo per cui si ripeterà nel resto del 2026. Le pipeline CI/CD si reggono sulla fiducia per costruzione. Uno sviluppatore diffidente verso uno strano binario in un download esegue senza pensarci un file di workflow arrivato nel suo repository la settimana scorsa, perché i file di workflow sono esattamente questo: codice che la piattaforma è tenuta a eseguire. I log di audit esistono, ma quasi nessun team li legge. I commit nuovi arrivano firmati da nomi come build-bot e ci-bot. I diff sono piccoli. La stringa base64 in fondo al workflow è opaca di proposito.

Il manuale difensivo è semplice e poco soddisfacente. Ruotare ogni segreto che abbia toccato un repository tra il 18 maggio e oggi. Controllare la directory .github/workflows di ogni progetto sotto gestione. Ispezionare i commit la cui email dell’autore non corrisponde a un membro del team. Considerare qualsiasi blob base64 dentro un file Actions colpevole fino alla decodifica. Le organizzazioni che usano Tiledesk dovrebbero tornare a 2.18.5 o aspettare una release pulita. Chi ha una relazione di fiducia OIDC tra Actions e un provider cloud dovrebbe revocarla e riemetterla.

Megalodon è la prima campagna a questa scala che tratta il workflow CI stesso come il bersaglio molle. Non sarà l’ultima. La lezione che lascia l’attacco è una che gli sviluppatori hanno già sentito in voce più bassa: la parte della pipeline che non leggi è la parte che l’aggressore scrive al posto tuo.

Altri articoli simili

Un bug di login ha lasciato 70 milioni di siti cPanel aperti a chiunque

Una scansione di 380.000 app costruite con l’IA ne trova migliaia senza alcuna autenticazione

Un’IA ha scritto un exploit zero-day funzionante — Google l’ha intercettato per primo

Un’estensione VS Code avvelenata ha rubato 3.800 repository interni di GitHub