Megalodon transformou o GitHub Actions numa porta traseira para 5561 repos

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

A campanha chama-se Megalodon. A equipa de investigação da SafeDep revelou-a a 21 de Maio, depois de desmontar os commits e seguir o rasto dos artefactos até um único servidor de comando e controlo em 216.126.225.129:8443. O interessante não é que o GitHub tenha sido atacado. O interessante é que o atacante não precisou de comprometer o GitHub. Usou o GitHub Actions, o sistema de CI/CD desenhado precisamente para garantir a integridade do código, como veículo de entrega da porta traseira.

Dois workflows, um massivo e um adormecido

O Megalodon operou em dois modos. A variante massiva adicionava um ficheiro de workflow novo chamado SysDiag que disparava a cada push e a cada pull request, apanhando tudo o que ali passasse. A variante dirigida, Optimize-Build, fazia algo mais paciente: substituía um workflow existente por um disparador workflow_dispatch, que fica adormecido até que alguém o invoque à mão. Uma porta traseira adormecida no directório CI de um projecto é muito mais difícil de notar do que um workflow novo chamado SysDiag, porque a maior parte dos mantenedores não audita um ficheiro que eles próprios escreveram.

Quando o workflow corre, o payload lê tudo o que consegue alcançar dentro do ambiente CI. Variáveis de ambiente CI. 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 fazer-se passar pelo próprio workflow perante qualquer conta na nuvem para a qual estivesse autorizado. Antes de sair, o payload faz grep no código-fonte do repositório à procura de mais de trinta padrões de segredos distintos (chaves de API, passwords, fragmentos de certificados) caso algum humano lá 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.

Um pipeline que envia a sua própria porta traseira

A vítima mais grave até agora é a Tiledesk, uma plataforma open source de engagement de clientes cujos nove repositórios no GitHub foram atingidos. Entre 19 e 21 de Maio, a Tiledesk publicou o seu pacote tiledesk-server no npm com a porta traseira compilada lá 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 programador que correu npm install nessa janela. É essa a alavanca para que o Megalodon foi construído: meter uma porta traseira num projecto open source para que o seu pipeline de release meta portas traseiras em centenas de projectos dependentes.

O Black-Iron-Project perdeu oito repositórios. Centenas de projectos mais pequenos (contas de programadores individuais, clusters universitários, sandboxes abandonadas) levaram um ou dois cada. O atacante não parecia escolher. O padrão foi cobertura larga: contas descartáveis com nomes aleatórios de oito caracteres a empurrar mensagens de commit idênticas minuto a minuto. O servidor C2 registava em silêncio o que voltava.

Porque é que os ficheiros de CI sobreviveram à auditoria

Este ataque funcionou pelo mesmo motivo por que se vai repetir durante o resto de 2026. Os pipelines CI/CD são construídos sobre confiança. Um programador desconfiado de um binário estranho num download corre sem pensar um ficheiro de workflow que chegou ao seu repositório a semana passada, porque os ficheiros de workflow são exactamente isso: código que a plataforma deve correr. Os logs de auditoria existem, mas quase nenhuma equipa os lê. Os commits novos vêm assinados por nomes como build-bot e ci-bot. Os diffs são pequenos. A cadeia base64 no fim do workflow é opaca de propósito.

O manual defensivo é simples e pouco satisfatório. Rodar cada segredo que tenha tocado num repositório entre 18 de Maio e hoje. Auditar o directório .github/workflows de cada projecto sob gestão. Inspeccionar os commits cujo email do autor não bate certo com um membro conhecido da equipa. Tratar qualquer blob base64 dentro de um ficheiro Actions como culpado até ser descodificado. As organizações que usam Tiledesk devem regressar à versão 2.18.5 ou esperar por um release limpo. Quem tiver confiança OIDC entre o Actions e um fornecedor de nuvem deve revogá-la e voltar a emiti-la.

Megalodon é a primeira campanha a esta escala que trata o workflow CI ele próprio como alvo brando. Não vai ser a última. A lição que o ataque deixa é uma que os programadores já tinham ouvido em voz mais baixa: a parte do pipeline que não lês é a parte que o atacante escreve por ti.