GitHub Action `tj-actions/changed-files` foi comprometida — 23 mil repositórios estão usando

• Uma GitHub Action popular usada para rastrear mudanças em cada branch foi comprometida, e um commit malicioso tentou vazar segredos de CI/CD
• 23.000 repositórios foram afetados, o GitHub removeu essa action e ela não pode mais ser usada
• É necessário substituir por uma action alternativa e, como há possibilidade de exposição de segredos em logs públicos de workflow, é essencial verificar e rotacionar as chaves
• O Harden-Runner da StepSecurity detectou o problema, e a empresa está distribuindo gratuitamente a action alternativa reforçada em segurança step-security/changed-files

Resumo do incidente

• tj-actions/changed-files é usada em mais de 23 mil repositórios e foi comprometida
  • O atacante modificou o código da action e redirecionou as tags de versão para um commit malicioso
  • Com isso, segredos de CI/CD passaram a ser exibidos nos logs de build do GitHub Actions
• Há possibilidade de segredos terem sido expostos em logs públicos de workflow
• O Harden-Runner detectou endpoints inesperados e assim descobriu o problema
• Um script Python malicioso fazia o dump dos segredos a partir do processo Runner Worker
• Todas as tags foram apontadas para o mesmo hash de commit malicioso (0e58ed8671d6b60d0890c21b07f8835ace038e67)

Medidas tomadas pelo GitHub

• O GitHub removeu a action tj-actions/changed-files e interrompeu seu uso
• O CVE oficial é CVE-2025-30066

Como fazer a recuperação

• 1. Usar a action alternativa segura fornecida pela StepSecurity

  • Substituir a action tj-actions/changed-files por step-security/changed-files@v45

• 2. Remover todas as referências a tj-actions/changed-files

  • Procurar e remover referências a tj-actions/changed-files no codebase:

    git grep -l "tj-actions/changed-files"  
    

• 3. Auditar os logs de execução dos workflows do GitHub Actions

  • É necessário verificar se houve vazamento de segredos nos logs de execuções recentes
  • Se forem encontrados segredos expostos, é preciso fazer a rotação (redefinição) imediatamente

• 4. Configurar uma allowlist do GitHub Actions

• Configurar uma allowlist para que apenas GitHub Actions confiáveis sejam executadas:
  • Pode ser definido nas configurações do GitHub:
    • Settings → Actions → Allow select actions

• 5. Configurar o StepSecurity Harden-Runner

  • No Harden-Runner, é possível configurar o monitoramento do tráfego de rede e da execução dos workflows

Próximos passos

• Problema reportado ao GitHub → issue no GitHub: #2463
• O repositório tj-actions/changed-files foi removido
• Registrado oficialmente como CVE-2025-30066
• Problemas de segurança semelhantes podem ser detectados e prevenidos com o StepSecurity Harden-Runner
• Recomenda-se configurar o Harden-Runner para reforçar a postura de segurança e realizar monitoramento em tempo real

[dl57934]

Ontem à noite não estava funcionando, mas agora voltou a funcionar.

[GN⁺]

Comentários do Hacker News

• O autor e mantenedor do Renovate explica o cenário do ataque

  • O invasor tinha permissão de escrita no repositório tj-actions/changed-files
  • O invasor falsificou commits do Renovate para disfarçar commits recentes
  • Essa falsificação não foi para enganar o PR, mas simplesmente para causar confusão
  • Os commits apareciam como Unverified, e a maioria das pessoas não exige apenas commits assinados
  • O Renovate Bot real propõe PRs para atualizar dependências
  • Algumas pessoas ativaram merge automático, mas isso não é a configuração padrão
  • Esse incidente relembra que muita gente pensa, por engano, que tags do git são imutáveis

• Nos últimos anos, a confiança em dependências e extensões de terceiros vem diminuindo

  • Se um pacote npm tem muitas dependências, não instalo
  • Não instalo extensões do vscode nem do chrome
  • É comum adicionarem malware ou mudarem a licença
  • Ao olhar a árvore de dependências do eslint, fica a dúvida se dá para confiar em tudo

• O repositório voltou a ficar online e o desenvolvedor forneceu uma explicação

  • O ataque veio de um token PAT da conta @tj-actions-bot
  • A segurança da conta foi reforçada, e o GitHub revogou o PAT comprometido

• No Clickhouse, investigaram github_events para identificar a conta usada no ataque

  • As contas "2ft2dKo28UazTZ" e "mmvojwip" são suspeitas

• É chocante que a forma de executar CI/CD seja listar repositórios arbitrários do GitHub

  • Com o aumento dos LLMs, o problema fica ainda mais grave
  • Trabalhos importantes deveriam ser executados manualmente

• O cofundador da StepSecurity explica como detectou o incidente de segurança

  • O Harden-Runner detectou comportamento anômalo ao monitorar chamadas de rede em workflows do GitHub Actions

• O problema é que o modo padrão de usar GitHub Actions depende de tags do git que não são imutáveis

  • Como o algoritmo de hash SHA-1 pode sofrer colisões, é necessário suporte a SHA-256

• GitHub Actions imutáveis devem ser introduzidos em breve

  • Fazer fork das Actions ou usar hash de commit

• O projeto maven-lockfile descreve um PR mesclado automaticamente

  • O Renovate Bot verdadeiro mesclou automaticamente um commit do falso Renovate Bot

• GitHub Actions deveria usar lockfile para dependências

  • A notação Semver é uma boa solução para esse problema