Megalodon: ataque de supply chain contamina mais de 5.500 repositórios no GitHub em seis horas

Mais de 5.500 repositórios no GitHub foram contaminados em apenas seis horas pelo ataque de supply chain batizado de Megalodon, que injetou GitHub Actions maliciosos via mais de 5.700 commits automatizados em 18 de maio. Os payloads exfiltram segredos de CI, credenciais AWS, tokens GCP e chaves Azure, criando ainda backdoors dormentes que comprometem novas execuções a cada push ou pull request.

O que aconteceu

A campanha Megalodon foi documentada pela SafeDep e atinge repositórios de organizações e desenvolvedores individuais que hospedam código aberto no GitHub. Em uma janela de pouco mais de seis horas, no dia 18 de maio, mais de 5.700 commits maliciosos foram enviados para 5.500 repositórios distintos, todos contendo workflows do GitHub Actions projetados para roubar credenciais e segredos.

O ataque se diferencia das ondas recentes contra npm, PyPI e Composer porque não depende da publicação de pacotes envenenados, mas sim da contaminação direta do pipeline de integração contínua. Cada execução automática do workflow injetado entrega ao atacante o conjunto completo de variáveis de ambiente do CI, transformando o próprio GitHub em vetor de exfiltração silenciosa.

Como o ataque funciona

Os atacantes desdobraram dois payloads complementares. O primeiro adiciona um novo workflow do GitHub Actions configurado para disparar em todo push ou pull request, garantindo que o malware execute em qualquer interação com o repositório. O segundo substitui workflows existentes por versões maliciosas com triggers específicos, criando backdoors dormentes que só ativam em condições escolhidas pelo operador.

Quando o workflow é executado, o payload lê todas as variáveis de ambiente do CI, captura credenciais AWS, access tokens GCP, credenciais Azure e qualquer segredo registrado no GitHub Actions Secrets. O conteúdo é transmitido a uma infraestrutura de comando e controle controlada pelos invasores.

Commits automatizados falsos injetaram workflows do GitHub Actions contendo payloads para roubar credenciais, segredos do CI, chaves e tokens.

SafeDep, relatório técnico

O método de propagação ainda está sob investigação. As primeiras hipóteses apontam para o comprometimento de tokens de acesso pessoal (PAT) ou de GitHub Apps com escopo amplo, eventualmente obtidos em ataques anteriores contra desenvolvedores, e usados para autenticar os commits maliciosos em larga escala. A homogeneidade temporal dos commits sugere automação ofensiva sofisticada.

Quem é afetado

• Mantenedores de projetos open source com workflows do GitHub Actions configurados e segredos armazenados na plataforma.
• Empresas que utilizam o GitHub como base de seus pipelines de build e deploy, especialmente aquelas com credenciais cloud de longa duração registradas como Secrets.
• Consumidores downstream das bibliotecas afetadas, expostos via dependências transitivas e binários redistribuídos com chaves comprometidas.
• Ambientes multi-cloud que mantêm tokens AWS, GCP e Azure no mesmo conjunto de segredos do CI, ampliando o blast radius de cada credencial vazada.

Análise

O Megalodon se soma a uma série de ataques recentes que migram o alvo do código publicado para o pipeline que o constrói. Casos como Codecov em 2021, SolarWinds antes dele e a sequência de incidentes em runners auto-hospedados em 2024 e 2025 já vinham mostrando que comprometer o CI é mais lucrativo do que comprometer um pacote isolado. O ganho de escala é evidente: 5.500 repositórios em seis horas é uma cadência impossível de atingir por compromissos manuais ou via instalação de pacotes adulterados.

A dependência cultural de segredos de longa duração armazenados como GitHub Secrets é o multiplicador de impacto. Ainda hoje, projetos médios mantêm chaves AWS estáticas com permissão de deploy, em vez de adotar OpenID Connect entre GitHub Actions e a nuvem com tokens efêmeros. Cada repositório comprometido pelo Megalodon que segue o padrão antigo significa uma chave válida em mãos hostis, ativa enquanto o time de SecOps não rotacionar manualmente.

Há uma terceira camada de risco que costuma ser subestimada: os backdoors dormentes deixados pelo segundo payload. Workflows que se ativam apenas em triggers específicos podem permanecer adormecidos por semanas, sobreviver a auditorias superficiais e ressurgir em um release crítico. Limpar o ambiente exige inspeção byte a byte dos arquivos em .github/workflows e revisão das diferenças no histórico do repositório, e não apenas reverter o último commit.

Recomendações práticas

• Audite imediatamente o diretório .github/workflows de todos os repositórios, comparando os arquivos atuais com versões anteriores ao dia 18 de maio e revertendo qualquer alteração não autorizada.
• Rotacione todas as credenciais armazenadas como GitHub Actions Secrets, incluindo chaves AWS, GCP e Azure, e qualquer token de serviço de terceiros.
• Migre o pipeline para autenticação OpenID Connect entre GitHub Actions e provedores de nuvem, eliminando segredos de longa duração armazenados no repositório.
• Habilite branch protection e exigência de revisão de pull request, bloqueando merges automáticos que possam reintroduzir o payload.
• Revogue tokens de acesso pessoal (PAT) e GitHub Apps com escopo amplo, substituindo-os por fine-grained tokens limitados a repositórios e permissões mínimas.
• Configure alertas de auditoria para criação ou alteração de workflows do GitHub Actions e para uso anômalo de Secrets dentro de jobs.
• Inspecione logs de execução do CI nas semanas anteriores em busca de jobs que tenham acessado endpoints externos não documentados, indicando exfiltração.

Fonte: SecurityWeek