Uma nova campanha de ataque está ativamente mirando repositórios de código aberto no GitHub, disfarçando código malicioso como atualizações de configuração de build de CI totalmente rotineiras. A campanha, conhecida como prt-scan, explora um gatilho de workflow do GitHub Actions amplamente mal utilizado para roubar tokens sensíveis, credenciais e segredos de nuvem de desenvolvedores que acionam acidentalmente pull requests fraudulentos.
Descoberta e escopo da campanha
O ataque surgiu pela primeira vez em 11 de março de 2026, quando um ator de ameaças usando a conta do GitHub testedbefore começou a enviar pull requests maliciosos para repositórios pequenos. Nas semanas seguintes, o mesmo ator alternou entre seis contas separadas do GitHub, abrindo coletivamente mais de 500 pull requests maliciosos. Cada PR falso carregava o mesmo título desarmante — "ci: update build configuration" — facilitando que desenvolvedores perdessem o perigo embutido.
A campanha aumentou dramaticamente em 2 de abril de 2026, quando o pesquisador de segurança Charlie Eriksen sinalizou publicamente a atividade após a conta ezmtebo enviar mais de 475 pull requests maliciosos em uma única janela de 26 horas. Analistas da Wiz Research rastrearam a campanha completa por três semanas antes de qualquer relato público, identificando seis ondas distintas de atividade do mesmo ator de ameaças.
Vetor e exploração técnica
A campanha abusa do gatilho pull_request_target no GitHub Actions. Ao contrário do gatilho padrão pull_request, este executa inteiramente no contexto do repositório base, em vez do fork, concedendo acesso total aos segredos do repositório mesmo quando o PR origina de uma conta de fork externa não confiável. Repositórios que falham em restringir este gatilho a colaboradores verificados estão diretamente expostos a este tipo de ataque.
Quando o workflow vulnerável é executado em um PR malicioso, a carga útil imediatamente começa uma operação de cinco fases. Ela primeiro extrai o GITHUB_TOKEN da configuração git, compacta-o e escreve a saída codificada em base64 nos logs do workflow para que o atacante possa recuperá-los posteriormente. A segunda fase usa esse token roubado para chamar a API do GitHub, mapeando nomes de segredos, ambientes de implantação e arquivos de workflow.
Simultaneamente, o ataque verifica endpoints de metadados de nuvem para credenciais AWS, Azure e Google Cloud. Um daemon em segundo plano então monitora o sistema de arquivos Linux /proc a cada dois segundos por dez minutos, capturando qualquer segredo carregado por etapas de trabalho posteriores e postando dados capturados diretamente nos comentários do PR — onde permanecem mesmo após os logs do workflow serem limpos.
Impacto e alcance
Pesquisadores Rami McCarthy, Hila Ramati, Scott Piper e Benjamin Read confirmaram que o atacante comprometeu com sucesso pelo menos dois pacotes npm — @codfish/eslint-config e @codfish/actions — em 106 versões de pacotes. O roubo verificado de chaves AWS, tokens de API Cloudflare e tokens de autenticação Netlify também foi confirmado, embora alvos de alto perfil incluindo Sentry, OpenSearch e NixOS tenham bloqueado os ataques através de controles adequados de aprovação de contribuidores.
O que diferencia esta campanha é o uso deliberado de automação impulsionada por IA para se adaptar a cada alvo. A ferramenta do atacante faz fork de repositórios, analisa seu stack tecnológico e injeta uma carga útil no arquivo certo para cada linguagem — arquivos de teste Go para repositórios Go, conftest.py para projetos Python e scripts package.json para Node.js.
Medidas de mitigação recomendadas
Organizações devem auditar imediatamente seus repositórios GitHub para os seguintes indicadores de comprometimento: branches correspondendo ao padrão prt-scan-[12-character-hex], PRs com títulos "ci: update build configuration" e marcadores de log de workflow como ==PRT_EXFIL_START_[nonce]==.
Administradores devem restringir pull_request_target apenas a colaboradores aprovados, impor portas de aprovação estritas para colaboradores de primeira vez e aplicar condições de gatilho de workflow baseadas em ator ou caminho. Qualquer credencial exposta — incluindo chaves AWS, tokens NPM e tokens de API de nuvem — deve ser rotacionada sem demora.
Análise técnica detalhada
A adaptação da carga útil para diferentes stacks tecnológicos demonstra um nível de sofisticação que não requer mais habilidades técnicas profundas. É o produto de ferramentas impulsionadas por IA que permitem até mesmo atacantes de baixa sofisticação lançar campanhas de cadeia de suprimentos em grande escala à velocidade da máquina. Apesar de seu alcance amplo, a taxa de sucesso geral da campanha permaneceu abaixo de 10% em mais de 450 tentativas de exploração analisadas.
A maioria dos acertos bem-sucedidos foi contra projetos hobby pequenos, expondo apenas tokens de workflow temporários do GitHub. Ainda assim, em mais de 500 tentativas totais, mesmo uma taxa de 10% pode produzir dezenas de compromissos reais — e o atacante continuou aprendendo ativamente e refinando cargas úteis, melhorando a evasão a cada nova onda.
O que os CISOs devem fazer imediatamente
- Auditar workflows: Verificar repositórios em busca de gatilhos pull_request_target não restritos.
- Monitorar PRs: Implementar alertas para PRs com títulos genéricos de CI vindos de contas externas.
- Rotacionar credenciais: Revogar e renovar qualquer token ou chave que possa ter sido exposto.
- Revisar permissões: Garantir que apenas colaboradores verificados possam executar workflows em PRs.