Megalodon transformou o GitHub Actions em backdoor para 5.561 repos

Uma campanha automatizada empurrou 5.718 commits para 5.561 repositórios do GitHub em seis horas numa segunda-feira de maio. Os commits pareciam manutenção rotineira de CI (“ci: add build optimization step”, “build: improve ci performance”, “chore: optimize pipeline runtime”) e vinham assinados por autores de nomes banais: build-bot, auto-ci, pipeline-bot. Quando a manhã do dia 18 de maio terminou, cada um desses repositórios tinha um arquivo de workflow com um payload bash codificado em base64 dentro.

A campanha se chama Megalodon. A equipe de pesquisa da SafeDep divulgou no dia 21 de maio, depois de desmontar os commits e seguir a trilha de artefatos até um único servidor de comando e controle em 216.126.225.129:8443. O interessante não é o GitHub ter sido atacado. O interessante é que o atacante não precisou comprometer o GitHub. Usou o GitHub Actions, o sistema de CI/CD desenhado justamente para garantir a integridade do código, como veículo de entrega do backdoor.

Dois workflows, um em massa e um adormecido

O Megalodon operou em dois modos. A variante de massa adicionava um arquivo de workflow novo chamado SysDiag que disparava a cada push e a cada pull request, capturando tudo o que passasse. A variante dirigida, Optimize-Build, fez algo mais paciente: substituiu um workflow existente por um gatilho workflow_dispatch, que fica adormecido até que alguém o invoque manualmente. Um backdoor adormecido no diretório CI de um projeto é muito mais difícil de notar do que um workflow novo chamado SysDiag, porque a maioria dos mantenedores não audita um arquivo que ele mesmo escreveu.

Quando o workflow roda, o payload lê tudo o que consegue alcançar dentro do ambiente CI. Variáveis de ambiente. Chaves de acesso, chaves secretas e tokens de sessão da AWS. Tokens de acesso GCP. Chaves SSH privadas. Credenciais .npmrc. Configurações Docker. Configurações Kubernetes. Tokens OIDC do GitHub Actions, que permitem ao atacante se passar pelo próprio workflow perante qualquer conta de nuvem para a qual estivesse autorizado. Antes de sair, o payload faz grep no código-fonte do repositório atrás de mais de trinta padrões distintos de segredo (chaves de API, senhas, fragmentos de certificado) caso algum humano tivesse colado um. Os endpoints de metadados da AWS IMDSv2, GCP e Azure também são consultados para obter identidade de máquina na nuvem.

Uma pipeline que entrega o próprio backdoor

A vítima mais grave até agora é a Tiledesk, uma plataforma open source de relacionamento com cliente cujos nove repositórios no GitHub foram atingidos. Entre 19 e 21 de maio, a Tiledesk publicou seu pacote tiledesk-server no npm com o backdoor compilado dentro. As versões 2.18.6 a 2.18.12 de @tiledesk/tiledesk-server carregam agora o código do payload, instalado por cada desenvolvedor que rodou npm install nessa janela. Essa é a alavanca para a qual o Megalodon foi construído: colocar um backdoor num projeto open source para que sua pipeline de release coloque backdoors em centenas de projetos dependentes.

O Black-Iron-Project teve oito repositórios atingidos. Centenas de projetos menores (contas de desenvolvedores individuais, clusters universitários, sandboxes abandonados) ficaram com um ou dois cada. O atacante não parecia escolher. O padrão foi cobertura ampla: contas descartáveis com nomes aleatórios de oito caracteres empurrando mensagens de commit idênticas minuto a minuto. O servidor C2 registrava em silêncio o que voltava.

Por que os arquivos de CI sobreviveram à auditoria

Esse ataque funcionou pelo mesmo motivo pelo qual vai se repetir pelo resto de 2026. As pipelines CI/CD são construídas sobre confiança. Um desenvolvedor desconfiado de um binário estranho num download executa sem hesitar um arquivo de workflow que chegou ao repositório dele semana passada, porque arquivos de workflow são exatamente isso: código que a plataforma deve rodar. Os logs de auditoria existem, mas quase nenhum time os lê. Os commits novos chegam assinados por nomes como build-bot e ci-bot. Os diffs são pequenos. A string base64 no fim do workflow é opaca de propósito.

O manual defensivo é simples e pouco animador. Trocar cada segredo que tenha tocado num repositório entre 18 de maio e hoje. Auditar o diretório .github/workflows de cada projeto sob gestão. Inspecionar os commits cujo email de autor não bate com nenhum membro conhecido do time. Tratar qualquer blob base64 dentro de um arquivo Actions como culpado até decodificar. Organizações que usam Tiledesk devem voltar para 2.18.5 ou esperar um release limpo. Quem tem confiança OIDC entre o Actions e um provedor de nuvem deve revogar e reemitir essa relação de confiança.

Megalodon é a primeira campanha nessa escala que trata o próprio workflow CI como alvo mole. Não vai ser a última. A lição que o ataque deixa é uma que desenvolvedores já tinham ouvido em voz mais baixa: a parte da pipeline que você não lê é a parte que o atacante escreve por você.