Ataque Megalodon: Hackers Comprometem Mais de 5.500 Repositórios no GitHub em Menos de Seis Horas

Em um ataque de precisão cirúrgica e escala industrial, uma campanha automatizada identificada como Megalodon comprometeu 5.561 repositórios no GitHub em apenas seis horas — entre 11h36 e 17h48 UTC do dia 18 de maio de 2026. No total, foram enviados 5.718 commits maliciosos, todos projetados para roubar credenciais de ambientes de integração e entrega contínua (CI/CD), chaves de acesso a nuvem e segredos de desenvolvimento.

O ataque foi detalhado pela empresa de segurança SafeDep, que mapeou toda a cadeia de comprometimento. Para não levantar suspeitas, os hackers criaram contas descartáveis no GitHub com nomes de usuário aleatórios de oito caracteres — como rkb8el9r, bhlru9nr e lo6wt4t6 — e falsificaram identidades de autores usando nomes que imitam bots legítimos de automação: build-bot, auto-ci, ci-bot e pipeline-bot. As mensagens de commit também foram escolhidas a dedo para parecerem manutenção rotineira de pipeline, reduzindo a chance de que desenvolvedores percebessem algo errado ao revisar o histórico do repositório.

Como o ataque funcionou, passo a passo

O núcleo técnico do Megalodon está na injeção de arquivos de workflow do GitHub Actions contendo payloads em bash codificados em Base64. Esse tipo de codificação é uma técnica clássica de ofuscação: ao transformar o código malicioso em uma sequência aparentemente inofensiva de caracteres, o hacker dificulta a detecção por ferramentas automáticas de análise de código.

Uma vez que um repositório comprometido recebe um merge do commit malicioso, o payload é executado diretamente dentro do pipeline CI/CD da vítima. A partir daí, o código começa a exfiltrar dados para um servidor de comando e controle (C2) localizado no endereço 216.126.225[.]129:8443.

A lista do que é roubado é extensa e preocupante: variáveis de ambiente de CI, credenciais da Amazon Web Services (AWS), tokens de acesso do Google Cloud, credenciais de papel de instância obtidas consultando endpoints de metadados de AWS IMDSv2, Google Cloud e Microsoft Azure IMDS, chaves privadas SSH, configurações de Docker e Kubernetes, tokens de Vault, credenciais do Terraform, histórico de comandos shell, chaves de API, strings de conexão com bancos de dados, JWTs, chaves privadas PEM e tokens de nuvem identificados por mais de 30 padrões de expressão regular. Além disso, o malware captura o token OIDC do GitHub Actions, além de tokens do GitHub, GitLab e Bitbucket, e arquivos de configuração como .env, credentials.json e service-account.json.

Duas variantes, duas estratégias

Pesquisadores identificaram dois tipos de payload na campanha, com abordagens operacionais distintas.

A primeira, chamada SysDiag, é uma variante em massa: injeta um novo workflow que dispara a cada push e pull request, garantindo execução automática e ampla cobertura de alvos. A segunda, chamada Optimize-Build, adota uma abordagem mais cirúrgica: é ativada apenas via workflow_dispatch, um gatilho manual do GitHub Actions que exige intervenção explícita do usuário ou de outro sistema. Essa escolha sacrifica alcance em troca de maior sigilo operacional.

A lógica por trás da escolha é reveladora. O gatilho on: push garante execução em cada commit ao branch principal, atingindo mais alvos sem intervenção. Já o workflow_dispatch reduz a frequência de disparo, mas torna a atividade menos detectável por sistemas de monitoramento automatizado. Com mais de 5.700 repositórios comprometidos, mesmo uma pequena fração que contenha um GITHUB_TOKEN válido já oferece ao hacker um volume considerável de alvos ativáveis sob demanda.

Um dos pacotes diretamente impactados foi o @tiledesk/tiledesk-server, no qual a variante Optimize-Build foi usada especificamente para comprometer runners de CI/CD — e não quando o pacote npm é instalado por usuários finais.

O contexto maior: TeamPCP e a era dos ataques de cadeia de suprimentos

O Megalodon não existe no vácuo. A campanha se insere num padrão crescente de ataques à cadeia de suprimentos de software, onde a infiltração em ferramentas amplamente utilizadas por desenvolvedores se torna um vetor de infecção massiva e de difícil detecção.

O grupo hacker identificado como TeamPCP está no centro desse movimento. Nas últimas semanas, o grupo transformou a cadeia de suprimentos de software open-source em um vetor de ataque encadeado: uma vulnerabilidade explora a próxima, em um efeito dominó que já atingiu projetos como TanStack, Grafana Labs, OpenAI, Mistral AI e, mais recentemente, o próprio GitHub — de propriedade da Microsoft. Em alguns casos, as vítimas foram extorquidas diretamente.

O TeamPCP também tem conexões estabelecidas com fóruns underground como o BreachForums e parceria com grupos de extorsão como LAPSUS$ e VECT. Além da motivação financeira, há evidências de motivação geopolítica: o grupo já foi associado ao deploy de malware do tipo wiper — software que apaga dados permanentemente — em máquinas detectadas em Israel e no Irã.

O worm Mini Shai-Hulud, associado ao mesmo ecossistema de ataques, levou o npm a tomar uma medida drástica: invalidar todos os tokens de acesso granular com permissão de escrita que contornam a autenticação de dois fatores (2FA). A plataforma também passou a recomendar que mantenedores de pacotes migrem para o sistema de Trusted Publishing, que reduz a dependência de tokens estáticos.

A empresa Socket, especializada em segurança de aplicações, foi direta na avaliação da medida: ao invalidar todos os tokens que contornavam o 2FA, o npm cortou as credenciais já coletadas pelo worm. Mas os mantenedores emitem novos tokens. E o worm, ainda ativo, recomeça a coleta. A ação ganha tempo — mas não fecha a brecha estrutural.

Pacotes falsos no npm: a ameaça paralela do Polymarket

Em paralelo ao Megalodon, pesquisadores identificaram outra operação de comprometimento via supply chain, desta vez focada em usuários de criptomoedas.

Uma conta descartável de nome polymarketdev publicou nove pacotes maliciosos no npm em uma janela de apenas 30 segundos, todos se passando por ferramentas legítimas de trading da plataforma Polymarket.

Os nomes dos pacotes foram escolhidos para parecerem oficiais: polymarket-trading-cli, polymarket-terminal, polymarket-trade, polymarket-auto-trade, polymarket-copy-trading, polymarket-bot, polymarket-claude-code, polymarket-ai-agent e polymarket-trader. No momento da publicação desta reportagem, todos ainda estavam disponíveis para download no npm.

O mecanismo de ataque é elegante em sua crueldade: ao instalar qualquer um desses pacotes, um script postinstall exibe um prompt falso de configuração de carteira, solicitando que o usuário cole sua chave privada de Ethereum ou Polygon. O prompt alega que a chave "fica criptografada" — mas o que acontece na prática é o oposto: a chave é enviada em texto puro para um worker da Cloudflare no endereço:

hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/wallets/keys.

Para dar credibilidade à operação, o hacker construiu uma interface funcional de trading ao redor do script malicioso e criou um repositório no GitHub para simular legitimidade.

A engenharia social, nesse caso, é o vetor principal: o prompt de instalação imita fielmente os fluxos de onboarding de carteiras legítimas, incluindo mascaramento de entrada que simula digitação segura.

O que está em jogo

Moshe Siman Tov Bustan, da empresa OX Security, foi direto ao ponto: o comprometimento do GitHub pelo TeamPCP foi apenas o início. O que vem a seguir é uma onda contínua — um tsunami de ataques direcionados a desenvolvedores em todo o mundo.

A avaliação reflete uma mudança estrutural no cenário de ameaças. Ataques como o Megalodon não visam usuários finais diretamente: eles miram os próprios construtores do ecossistema digital — desenvolvedores, mantenedores de pacotes, equipes de DevOps. Ao comprometer pipelines de CI/CD, os hackers obtêm acesso a credenciais que podem abrir portas para ambientes de produção, infraestrutura de nuvem e dados corporativos sensíveis.

Para as empresas, o risco é duplo: há o impacto operacional imediato do roubo de credenciais, e há o risco de reputação e compliance associado ao vazamento de dados de clientes ou de propriedade intelectual. Para desenvolvedores individuais, a ameaça é igualmente concreta — especialmente aqueles que mantêm pacotes open-source amplamente utilizados sem o suporte de uma equipe de segurança dedicada.