Multiple Reviewdog actions were compromised during a specific time period

Entre 18:42 e 20:31 UTC de 11 de março de 2025, a tag v1 de reviewdog/action-setup foi repontada para um commit malicioso hospedado em um fork, injetando código que despeja segredos do GitHub Actions nos logs do workflow. Como cinco outras actions do projeto (action-shellcheck, action-composite-template, action-staticcheck, action-ast-grep, action-typos) referenciam action-setup@v1 internamente, todas ficaram comprometidas nessa janela — independentemente de o usuário final ter pinado sua própria action por SHA ou não, porque o pin interno delas apontava para a tag flutuante v1. Não é uma falha de lógica explorável a qualquer momento: é uma injeção de código malicioso limitada a uma janela de ~1h49min, descoberta pela Wiz Research junto com o caso relacionado do tj-actions/changed-files (CVE-2025-30066).

O vetor de ataque foi de cadeia de suprimentos, não uma vulnerabilidade de código no sentido tradicional (CWE-506, Embedded Malicious Code). O commit malicioso (f0d342d) foi adicionado ao script install.sh de action-setup e passou a executar, antes da instalação normal do reviewdog, um payload Python codificado em base64. Esse payload é uma variante de técnica de memory scraping (baseada em publicação de davidebove.com sobre leitura de /proc//maps e /proc//mem): ele localiza o processo Runner.Worker, percorre suas regiões de memória legíveis e despeja o conteúdo, filtrando por padrões JSON no formato usado internamente pelo Actions Runner para armazenar valores marcados como secret ("isSecret":true). O resultado filtrado é reempacotado em base64 e ecoado para o log do workflow com ::group::, tornando os segredos visíveis a qualquer um com acesso de leitura ao log da execução.

O código só executa a extração se sudo estiver disponível sem senha e o runner for GitHub-hosted Linux (RUNNER_ENVIRONMENT=github-hosted, RUNNER_OS=Linux) — restrição que o próprio script malicioso verifica antes de rodar o dump de memória, então runners self-hosted ou não-Linux não são afetados por esse payload específico. Não há interação do usuário nem autenticação prévia necessária: basta que o workflow do repositório invoque, na janela de compromisso, action-setup@v1 (ou qualquer uma das cinco actions dependentes) em um runner hospedado pelo GitHub para os segredos configurados naquele workflow — tokens, credenciais de cloud, chaves de API — acabarem impressos no log de execução, que pode ser público se o repositório for público.

Não há uma versão "corrigida" para instalar em substituição — o problema foi a tag v1 apontando para commit malicioso, que a mantenedora já retagueou para o código legítimo (commit 3f401fe). A ação corretiva real é auditar: verificar se algum workflow do repositório executou reviewdog/action-setup@v1 (ou action-shellcheck, action-composite-template, action-staticcheck, action-ast-grep, action-typos nas versões afetadas) entre 11/03/2025 18:42 e 20:31 UTC; se sim, tratar todos os segredos expostos naquele workflow como comprometidos e rotacioná-los. A mantenedora recomenda pinar todas as GitHub Actions por hash de commit (não por tag de versão) e garantir que as próprias actions usadas não dependam internamente de outras actions por tag flutuante — o próprio reviewdog já migrou seus repositórios para pins por SHA usando a ferramenta pinact. Pinar sua chamada da action por SHA não protegeria neste caso específico, porque a dependência interna (action-setup@v1) usava tag, não SHA — por isso a recomendação inclui verificar as dependências internas das actions, e, para quem quer eliminar esse vetor por completo, instalar o binário reviewdog diretamente em vez de usar as actions wrapper.

O sinal mais direto é procurar, nos logs de execução de workflows do GitHub Actions do repositório, blocos ::group::🐶 Preparing environment ... seguidos de saída em base64 gerada por chamadas sudo python3 $TEMP/runner_script.py — isso indica que o payload malicioso rodou e potencialmente vazou segredos para o log. Também vale auditar o histórico de execuções de workflow (Actions > runs) filtrando pela janela de 11/03/2025 18:42–20:31 UTC para checar se algum job usou as actions afetadas nesse intervalo específico; fora dessa janela não há indicador de comprometimento, já que o código malicioso só existiu enquanto a tag v1 apontava para o commit forjado.