L'attacco Megalodon ha compromesso oltre 5.500 repository GitHub

Una serie di commit apparentemente innocui, firmati da un fantomatico “build-bot“, ha trasformato migliaia di repository GitHub in punti di raccolta per credenziali cloud, token CI/CD e chiavi SSH. L’operazione, ribattezzata Megalodon dai ricercatori che l’hanno individuata, ha colpito oltre 5.500 repository pubblici nell’arco di circa 6 ore; un dato che rende bene l’idea della scala raggiunta dagli attacchi alla supply chain software. La particolarità non sta solo nel numero di repository compromessi, ma nel metodo usato: niente exploit zero-day, nessuna vulnerabilità tradizionale da correggere: gli aggressori hanno sfruttato meccanismi perfettamente legittimi di GitHub Actions e dei workflow CI/CD.

Il caso arriva dopo settimane già complicate per il mondo open source: il gruppo TeamPCP ha infatti compromesso diversi progetti noti tra marzo e aprile 2026, prendendo di mira strumenti come Trivy, KICS e LiteLLM. Megalodon sembra inserirsi nella stessa linea operativa: colpire l’infrastruttura di sviluppo invece dell’applicazione finale.

Un runner GitHub Actions può accedere a credenziali AWS per gestire risorse cloud, token Kubernetes per controllare cluster e container, chiavi Terraform usate per automatizzare l’infrastruttura, registri Docker privati contenenti immagini software riservate e sistemi di deployment automatico. Compromettere questo livello significa spesso ottenere accesso diretto ai sistemi cloud e all’infrastruttura critica di un’azienda.

Come funziona Megalodon

L’attacco ha modificarto direttamente i file presenti nella directory .github/workflows: gli aggressori sostituiscono o alterano i workflow YAML di GitHub Actions inserendo payload Bash codificati in Base64. A prima vista il commit sembra una normale ottimizzazione, spesso accompagnata da messaggi rassicuranti come ci: add build optimization step.

La parte interessante, dal punto di vista tecnico, è che il malware non si attiva immediatamente in tutti i casi. Alcune varianti usano trigger come workflow_dispatch, lasciando il payload dormiente finché qualcuno non avvia manualmente il workflow oppure finché non si verifica un determinato evento GitHub. Una scelta furba: riduce il rumore operativo e rende più difficile individuare l’infezione nei log.

Megalodon evidenzia un aspetto spesso poco considerato: GitHub Actions si comporta esattamente come previsto dal suo modello di funzionamento. Se un attaccante riesce a ottenere permessi di scrittura su un repository, ad esempio tramite un PAT (Personal Access Token, cioè un token che consente l’accesso all’account), una deploy key oppure un account compromesso, può modificare un workflow automatizzato; GitHub eseguirà automaticamente quel codice senza effettuare controlli di sicurezza aggiuntivi particolarmente restrittivi.

Non esiste oggi un sistema nativo che imponga firma crittografica obbligatoria dei workflow oppure controlli di integrità avanzati sui file YAML CI/CD. Le protezioni disponibili, come branch protection e mandatory reviews, funzionano bene solo se configurate correttamente: molti repository open source più piccoli non adottano revisioni obbligatorie per commit interni o chiavi deploy con privilegi limitati.

Il caso Tiledesk e la propagazione verso npm

Uno degli episodi più significativi riguarda Tiledesk, piattaforma open source per live chat e chatbot: i ricercatori di SafeDep hanno rilevato che le versioni comprese tra 2.18.6 e 2.18.12 includevano codice compromesso, mentre la release 2.18.5 risultava ancora pulita.

La cosa interessante è che gli aggressori non avrebbero compromesso direttamente l’account npm del maintainer. Hanno invece modificato il repository GitHub sorgente; successivamente il maintainer ha pubblicato le release dal codice infetto. L’attacco si sposta insomma dalla distribuzione del pacchetto alla sorgente che alimenta la pubblicazione.

Per anni buona parte delle difese legati alla supply chain si sono concentrate sui registri come npm o PyPI: autenticazione forte, 2FA, verifica publisher, firma pacchetti.

Megalodon aggira completamente quel modello: anche con account npm protetti da MFA, il codice malevolo può comunque finire online se la repository GitHub da cui parte la build è stata alterata.

Secondo gli esperti di Ox Security non esistono prove definitive che colleghino Megalodon direttamente a TeamPCP, anche se stile operativo e obiettivi ricordano molto le campagne viste nei mesi precedenti.

Le informazioni rubate valgono più del codice sorgente

Molti sviluppatori tendono ancora a pensare alla compromissione di un repository come a un problema limitato al software pubblicato. In realtà il codice sorgente spesso interessa relativamente poco agli attaccanti moderni. Il vero bersaglio sono le identità cloud e i sistemi di automazione.

Un runner CI/CD contiene spesso credenziali ad alto privilegio: non solo token GitHub, ma anche accessi AWS IAM, service account Google Cloud, segreti Kubernetes, credenziali Docker Hub e token Slack. Alcuni payload Megalodon cercano esplicitamente pattern associati a segreti AWS, token GitHub, PyPI, npm e Slack.

Le analisi pubblicate da Oligo Security sui precedenti attacchi TeamPCP mostrano che i criminali verificano le credenziali rubate quasi immediatamente usando chiamate API reali come sts:GetCallerIdentity su AWS. Non aspettano giorni o settimane. Nel giro di poche ore iniziano attività di ricognizione sugli account e permessi IAM, l’enumerazione dei servizi ECS, l’accesso ai bucket S3 e i tentativi di esfiltrazione dei dati, cioè il trasferimento non autorizzato di informazioni verso sistemi esterni.

Gli interventi difensivi realmente utili

Bloccare un attacco simile richiede controlli più vicini alla gestione dell’identità che all’antivirus tradizionale: nessuno scanner CVE individua un workflow YAML apparentemente legittimo che contiene una shell Base64 offuscata.

La prima misura consiste quindi nel proteggere rigorosamente la directory .github/workflows: ogni modifica ai workflow dovrebbe passare da Pull Request obbligatorie, approvazioni multiple e branch protection severe. Conviene inoltre limitare l’uso di PAT permanenti e preferire token temporanei o GitHub App con privilegi minimi.

Megalodon mostra chiaramente quanto basti poco per trasformare un semplice commit YAML in una compromissione infrastrutturale su larga scala.