Il 18 maggio 2026, tra le 11:36 e le 17:48 UTC, una campagna denominata Megalodon ha compromesso 5.561 repository GitHub in una finestra di appena sei ore. Gli attaccanti hanno pushato 5.718 commit malevoli a una frequenza di circa 1.000 commit all'ora, iniettando workflow Actions progettati per esfiltrare credenziali CI/CD verso un server di comando e controllo all'indirizzo 216.126.225.129:8443. Non è servita la compromissione di singoli account sviluppatore: il vettore principale è stata l'impersonificazione di identità automatizzate, sfruttando il trust implicito che gli ecosistemi CI/CD accordano ai commit firmati da bot.
- 5.561 repository GitHub compromessi in 6 ore il 18 maggio 2026, con 5.718 commit pushati a circa 1.000 commit/ora.
- Gli attaccanti hanno forgiato identità di bot CI con username random di 8 caratteri e email come build-system@noreply.dev e ci-bot@automated.dev; le API GitHub restituivano null nei campi author/committer.
- Due varianti di payload: SysDiag per mass compromissione su push/PR, e Optimize-Build per target mirati con trigger workflow_dispatch dormiente.
- Il caso Tiledesk ha documentato la propagazione da repository avvelenato a registry npm: versioni 2.18.6-2.18.12 pubblicate dal maintainer legittimo eljohnny da sorgente compromessa.
La velocità che rende invisibili i commit malevoli
La campagna Megalodon ha raggiunto una scala che rende impraticabile ogni controllo manuale del codice. In sei ore, gli attaccanti hanno generato quasi sei mila commit distribuiti su oltre cinquemila repository. Secondo SafeDep, la distribuzione per email forgiata mostra 2.878 commit da build-system@noreply.dev e 2.841 da ci-bot@automated.dev. Questa simmetria suggerisce un'infrastruttura automatizzata bilanciata, non una serie di azioni manuali.
La tecnica di identity forgery sfrutta una caratteristica strutturale dell'ecosistema GitHub: i commit possono riportare qualsiasi nome utente e email, e le API non verificano la consistenza con un profilo reale. Entrambe le fonti riportano che le chiamate API per author e committer restituivano campi null, indicando nessun account legittimo collegato. In pratica, i maintainer vedevano commit apparentemente firmati da bot di sistema, con nomi come build-bot, auto-ci, ci-bot, pipeline-bot.
Il trust implicito nei commit bot è il cuore del problema. Le pipeline CI/CD sono progettate per eseguire automaticamente il codice proveniente da identità automatizzate; non c'è spazio per il code review umano a queste velocità. Quando un attaccante riesce a impersonare quella classe di identità, il sistema non ha leve di verifica.
Il meccanismo del backdoor: SysDiag e Optimize-Build
I payload analizzati da SafeDep presentano due varianti con funzioni complementari. SysDiag è progettato per la mass compromissione: si attiva su eventi push e pull request, eseguendo la raccolta dei segreti ambiente il più rapidamente possibile. Optimize-Build è invece mirato: utilizza il trigger workflow_dispatch, che consente di avviare manualmente un workflow senza necessità di nuovo codice pushato.
Il trigger workflow_dispatch ha un effetto collaterale critico. Le regole anti-recursion di GitHub Actions impediscono al GITHUB_TOKEN di attivare nuovi workflow in risposta a eventi generati da workflow stessi. Ma workflow_dispatch è esplicitamente escluso da questo blocco: un workflow avviato manualmente può a sua volta innescare altri workflow. Gli attaccanti hanno sfruttato questa eccezione per mantenere persistenza dormiente nei repository target, pronta a essere attivata in un secondo momento.
I permessi richiesti dai workflow malevoli includono id-token: write per l'autenticazione OIDC verso provider cloud, e actions: read per l'accesso ai metadati delle pipeline. La combinazione permette sia l'esfiltrazione di token a breve termine sia la ricognizione dell'infrastruttura CI/CD della vittima.
Il caso Tiledesk: quando il repository avvelena il registry
"The attacker never touched the npm account. They compromised the GitHub repository, and the maintainer published from the poisoned source without realizing it." — SafeDep analysis
Il caso più documentato della campagna riguarda Tiledesk, progetto open source con nove repository colpiti. Il commit acac5a9 del 18 maggio 2026 ha introdotto il payload malevolo nel codice sorgente. Il maintainer eljohnny, con email giovanni@tiledesk.com, ha successivamente pubblicato nel registry npm le versioni dalla 2.18.6 alla 2.18.12 di @tiledesk/tiledesk-server, senza accorgersi che il codice sorgente era stato compromesso.
SafeDep ha pubblicato il diff tra la versione pulita 2.18.5 e la backdoorata 2.18.12, mostrando l'inserzione del payload nelle routine di build. Questa catena — repository avvelenato, pubblicazione mantenitore ignaro, distribuzione automatica tramite registry — è il paradigma della supply chain attack moderna. Il mantenitore non è stato compromesso personalmente; ha semplicemente fatto ciò che faceva abitualmente, su sorgente che non era più autentico.
Altre organizzazioni documentate con repository colpiti includono Black-Iron-Project (otto repository) e WISE-Community. SafeDep fornisce la lista completa dei repository compromessi, con timestamp e identificativi dei commit.
Cosa fare adesso
Per i maintainer di repository GitHub, la prima azione è verificare la presenza di workflow sospetti con trigger workflow_dispatch inseriti tra il 18 e il 19 maggio 2026. SafeDep ha pubblicato IOC completi che includono i pattern di nome file SysDiag.yml e Optimize-Build.yml, oltre all'indirizzo C2 216.126.225.129:8443.
È necessario controllare i log di audit delle organizzazioni per commit con author/committer che restituiscono null dalle API GitHub, o con email dai domini noreply.dev e automated.dev. Questi sono indicatori precisi della campagna documentata.
Per i team che pubblicano su npm o altri registry, la verifica deve estendersi alle versioni pubblicate a partire dal 18 maggio 2026. Il caso Tiledesk dimostra che il codice sorgente compromesso può propagarsi al registry senza compromissione dell'account del maintainer. Confrontare i checksum delle build locali con quelle del repository remoto è un controllo specifico per questo vettore.
La revisione dei permessi dei workflow Actions è un'altra azione diretta. I workflow che richiedono id-token: write e actions: read devono essere limitati ai soli file che li necessitano effettivamente, e il merge di PR che modifichino questi permessi richiede review esplicita.
Cosa sappiamo e cosa resta oscuro
La fonte non specifica il vettore di accesso iniziale: come gli attaccanti abbiano ottenuto le credenziali necessarie per pushare su 5.561 repository rimane il punto oscuro principale. Non emerge se si tratti di una compromissione massiva di account, di un leak di personal access token, di deploy key esposte, o di un meccanismo completamente diverso.
Non emergono sovrapposizioni infrastrutturali che colleghino la campagna a threat actor noti allo stato attuale. L'identità reale o il gruppo dietro Megalodon non sono identificati nelle fonti disponibili. Il server C2 216.126.225.129:8443 è documentato nelle analisi tecniche, ma il dossier non specifica se sia stato sinkholed o se rimanga attivo.
Il numero di 5.561 repository si riferisce a repository target unici con commit pushati; la fonte non documenta quanti di questi workflow siano stati effettivamente eseguiti, né l'estensione della compromissione cloud oltre l'esfiltrazione iniziale. Nessuna delle fonti riporta un CVE assegnato alla vulnerabilità, né interventi di revoca token o blocchi da parte di GitHub.
Il dossier non documenta se le versioni npm backdoorate siano state deprecate o rimosse dal registry.
Perché è importante
La campagna Megalodon esemplifica una transizione strutturale nell'ecosistema delle minacce. Non più compromissione di singoli account sviluppatore, ma sfruttamento sistematico di una classe di identità — i bot CI/CD — che il flusso di sviluppo moderno tratta come trusted by design. La velocità di esecuzione, circa 1.000 commit all'ora, rende i controlli manuali obsoleti per costruzione.
Il caso Tiledesk dimostra che il perimetro di rischio si estende dal repository al registry, senza soluzione di continuità. Il mantenitore legittimo diventa vettore inconsapevole, e la firma della pubblicazione nel registry non garantisce più l'integrità del codice sorgente.
Il pattern è replicabile. Le identità bot non sono verificabili in modo robusto dalle API attuali; il trigger workflow_dispatch fornisce un canale di persistenza che elude le regole anti-recursion. Fino a quando queste caratteristiche rimarranno strutturali, la superficie d'attacco persiste.
Secondo la fonte, ricercatori di Ox Security hanno caratterizzato eventi simili come "l'inizio di un'ondata infinita o di uno tsunami di attacchi". La formulazione è retorica, ma il dato di fondo è che l'automazione CI/CD ha creato una classe di identità non verificabili che gli attaccanti possono impersonare a scala industriale. Megalodon ne è la dimostrazione quantificata.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://socfortress.medium.com/megalodon-attack-swallowed-5-561-github-repositories-92db9361328e
- https://safedep.io/megalodon-mass-github-repo-backdooring-ci-workflows/
- https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow