Una serie di commit apparentemente innocui, firmati da un fantomatico “build-bot”, ha trasformato migliaia di repository GitHub in veri e propri 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 sei ore. Un numero che restituisce con una certa brutalità la scala raggiunta oggi dagli attacchi alla supply chain software. E la cosa che fa più impressione non è tanto la quantità di repository compromessi, quanto il metodo: niente exploit zero-day, nessuna vulnerabilità tradizionale. Gli aggressori hanno sfruttato meccanismi perfettamente legittimi di GitHub Actions e dei workflow CI/CD.
Il caso arriva dopo settimane già piuttosto turbolente 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 logica operativa: colpire l’infrastruttura di sviluppo invece dell’applicazione finale. E vale la pena ricordare cosa può fare un runner GitHub Actions a cui viene dato accesso: credenziali AWS per gestire risorse cloud, token Kubernetes per controllare cluster e container, chiavi Terraform per automatizzare l’infrastruttura, registri Docker privati con immagini software riservate, sistemi di deployment automatico. Compromettere questo livello significa, molto spesso, ottenere accesso diretto ai sistemi cloud e all’infrastruttura critica di un’azienda.
Come funziona l’attacco Megalodon e perché è così difficile da individuare
L’attacco ha modificato 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 tipo “ci: add build optimization step”. Nulla che faccia scattare un allarme.
La parte tecnicamente più interessante è 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 su GitHub. Una scelta furba, che riduce il rumore operativo e rende decisamente più complicato individuare l’infezione nei log.
Megalodon evidenzia un aspetto che in tanti sottovalutano: GitHub Actions si comporta esattamente come previsto dal suo modello di funzionamento. Se un attaccante riesce a ottenere permessi di scrittura su un repository, magari tramite un PAT (Personal Access Token), una deploy key oppure un account compromesso, può modificare un workflow automatizzato. E GitHub eseguirà quel codice senza effettuare controlli di sicurezza aggiuntivi particolarmente restrittivi. Non esiste oggi un sistema nativo che imponga firma crittografica obbligatoria dei workflow o 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, però, non adottano revisioni obbligatorie per commit interni né chiavi deploy con privilegi limitati.
Il caso Tiledesk e il vero bottino di Megalodon
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. Il passaggio chiave è che gli aggressori non avrebbero compromesso direttamente l’account npm del maintainer. Hanno invece modificato il repository GitHub sorgente, e successivamente il maintainer ha pubblicato le release partendo dal codice già infetto. L’attacco si sposta insomma dalla distribuzione del pacchetto alla sorgente che alimenta la pubblicazione. Per anni buona parte delle difese legate 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.
Nel dettaglio
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 osservate nei mesi precedenti. 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 di 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. Nel giro di poche ore iniziano attività di ricognizione sugli account e permessi IAM, enumerazione dei servizi ECS, accesso ai bucket S3 e tentativi di esfiltrazione dei dati, cioè il trasferimento non autorizzato di informazioni verso sistemi esterni.
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 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 quanto basti poco per trasformare un semplice commit YAML in una compromissione infrastrutturale su larga scala.
