Trivy é atacado novamente: ampla adulteração de tags do GitHub Actions vaza segredos

• O GitHub Action oficial foi adulterado por meio de atualização forçada de tags, resultando em um ataque à cadeia de suprimentos com distribuição de código malicioso
• O invasor substituiu 75 de 76 tags por commits maliciosos, afetando cerca de mais de 10 mil workflows
• O script adulterado opera em três etapas: coleta, criptografia e exfiltração de segredos, e inclui código do TeamPCP Cloud stealer
• As tags comprometidas ainda permanecem ativas, e foi confirmado que apenas @0.35.0 ou um commit SHA específico são seguros
• É obrigatório substituir todas as credenciais e fixar o uso em commit SHA; foi confirmada a mesma contaminação nas imagens do Docker Hub

---

Visão geral do ataque à cadeia de suprimentos do Trivy GitHub Actions

• O GitHub Action oficial do Trivy (aquasecurity/trivy-action) foi adulterado por invasores por meio de atualização forçada de tags (force-push), em um incidente que distribuiu código malicioso
• O invasor substituiu 75 das 76 tags de versão por commits maliciosos, manipulando-as para execução automática em pipelines de CI/CD
• Como mais de 10.000 arquivos de workflow do GitHub referenciam essa action, o alcance do impacto é amplo
• As tags comprometidas continuam ativas, e foi confirmado que @0.35.0 é a única versão segura
• A Socket detectou em tempo real 182 eventos de GitHub Actions maliciosos a partir de 19:15 UTC, classificados como Backdoor, Infostealer e Reconnaissance

Causa do ataque e forma de execução

• Segundo os mantenedores do Trivy, este ataque ocorreu devido ao roubo de credenciais com permissão de escrita
  • Em uma invasão anterior ocorrida no início de março, segredos do ambiente de CI vazaram, e o processo de rotação não foi concluído por completo, deixando algumas novas credenciais com os invasores
  • Usando essas credenciais, o invasor realizou atualizações autenticadas de tags sem explorar nenhuma vulnerabilidade do GitHub em si
• Em vez de fazer push para branches ou criar releases, o invasor sobrescreveu à força tags existentes com novos commits
  • Cada tag falsificada copiou os metadados do commit original (autor, email, timestamp e mensagem de commit) para parecer legítima
  • Porém, enquanto os commits originais tinham assinatura GPG, os commits do invasor não tinham assinatura, e a data do commit pai divergia, aparecendo em 2026
• Mesmo com a indicação de Immutable Release do GitHub, é possível que o invasor tenha publicado o estado malicioso e depois aplicado o bloqueio
  • Portanto, não se deve confiar no selo “Immutable”; fixar em commit SHA (pinning) é a única forma segura de consumo

Estrutura da adulteração das tags

• O invasor criou novos commits com base no commit mais recente da branch master (57a97c7e)
  • Apenas o arquivo entrypoint.sh foi substituído pela versão maliciosa, mantendo os demais arquivos inalterados
  • Cada tag copiou o número do PR, a mensagem de commit e as informações de autoria do original para forjar legitimidade
• Quando a página de release do GitHub mostra “0 commits to master since this release”, isso pode ser usado como indicador visual de tag adulterada
• A única razão para a tag 0.35.0 não ter sido adulterada é que ela já apontava para o HEAD de master

Estrutura do payload malicioso

• O entrypoint.sh adulterado tem 204 linhas; as linhas 4 a 105 contêm o código do infostealer, seguidas pelo código legítimo de varredura do Trivy
• O código malicioso é composto de três fases
  • Fase 1: Coleta (Collection) — extração de segredos da memória de processos do runner e do sistema de arquivos
  • Fase 2: Criptografia (Encryption) — criptografia dos dados coletados com AES-256-CBC e RSA-4096
  • Fase 3: Exfiltração (Exfiltration) — envio para um domínio controlado pelo invasor ou para a conta GitHub da vítima

• Fase 1: coleta de segredos

  • Lê variáveis de ambiente de processos do runner do GitHub Actions (Runner.Worker, Runner.Listener, runsvc, run.sh) em /proc/<pid>/environ e extrai itens contendo as palavras-chave env e ssh
  • Em runners hospedados pelo GitHub, executa com sudo um script Python de dump de memória para procurar o padrão "isSecret":true na memória do processo Runner.Worker
  • Em runners self-hosted, executa um coletor de credenciais do sistema de arquivos identificado como TeamPCP Cloud stealer
    • Inclui um amplo conjunto de alvos, como chaves SSH, credenciais AWS/GCP/Azure, tokens de Kubernetes, configurações do Docker, senhas de banco de dados, arquivos de ambiente, chaves TLS, configurações de VPN, URLs de webhook e chaves de carteiras

• Fase 2: criptografia

  • Gera uma chave de sessão de 32 bytes com openssl rand e criptografa os dados com AES-256-CBC
  • A chave de sessão é criptografada com uma chave pública RSA-4096 usando padding OAEP
  • Os dados criptografados (payload.enc) e a chave de sessão (session.key.enc) são empacotados em tpcp.tar.gz

• Fase 3: exfiltração de dados

  • Canal primário: envio via HTTPS POST para https://scan[.]aquasecurtiy[.]org (domínio com erro de grafia de aquasecurity)
  • Canal secundário: em caso de falha, usa o GitHub Personal Access Token da vítima para criar um repositório público chamado tpcp-docs
    • Faz upload de tpcp.tar.gz como asset de release → o invasor então localiza esse repositório por busca no GitHub e coleta os dados
  • Ao usar a infraestrutura do GitHub, tenta contornar firewalls e aumentar a evasão de detecção
  • Por fim, remove arquivos temporários para minimizar rastros

Invasor e possível origem

• Há um comentário no código malicioso indicando explicitamente “TeamPCP Cloud stealer”
  • TeamPCP (DeadCatx3, PCPcat, ShellForce) é um grupo voltado a ataques em ambientes cloud-native, com casos de exploração de vulnerabilidades em Docker API, Kubernetes, Redis e dashboards do Ray
  • Em fevereiro de 2026, Flare e The Hacker News relataram campanhas de ransomware, roubo de dados e mineração de criptomoedas atribuídas ao grupo
• A funcionalidade de coleta de chaves de validadores Solana e carteiras de criptomoedas é compatível com motivação financeira

Resposta e recomendações

• Interrompa o uso de todas as tags de versão do Trivy Action e utilize apenas o commit SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 ou a tag 0.35.0
• Pipelines comprometidos devem ser tratados como vazamento completo de segredos, exigindo a troca imediata de todas as credenciais de nuvem, chaves SSH, tokens de API, senhas de banco de dados e tokens do Docker
• Recomenda-se verificar a existência do repositório tpcp-docs na organização GitHub e revisar logs do trivy-action executados após 19 de março às 19:00 UTC

Indicadores de comprometimento (IOCs)

• Indicador de rede: scan[.]aquasecurtiy[.]org
• Hash de arquivo: 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a (entrypoint.sh)
• GitHub Actions infectadas: aquasecurity/trivy-action@0.0.1 ~ @0.34.2, incluindo todas as versões nesse intervalo (total de 75 tags)

Atualização adicional (22 de março)

• Também foi confirmado no Docker Hub que as imagens do Trivy (0.69.4, 0.69.5, 0.69.6, latest) foram contaminadas com o mesmo payload de infostealer
• A tag latest foi apontada para a imagem maliciosa e distribuída aos usuários durante o período de exposição
• Mais detalhes relacionados podem ser consultados no relatório separado da Socket “Trivy Docker Images Compromised”

[GN⁺]

Comentários do Hacker News

• Fico me perguntando por que o GitHub não impõe versionamento imutável (immutable versioning) para Actions
  O guia de segurança recomenda fixar com commit SHA, mas parece que esse tipo de problema poderia ser reduzido se simplesmente não fosse possível publicar uma Action sem fixação

  • Esse tipo de discussão sempre tem dois lados
    Do ponto de vista da equipe de segurança, versões fixadas são mais seguras, mas ao mesmo tempo também é arriscado se atualizações de segurança não forem aplicadas automaticamente
    No fim, é preciso uma solução que atenda aos dois lados sem prejudicar a produtividade
    Eu gostaria de chamar isso de “paradoxo do pinning”
  • Acho que é difícil para o GitHub Actions mudar a estrutura atual porque ele segue o modelo de tags do git
    Ainda assim, em algum momento eles precisam começar esse trabalho de mudança
  • E se a versão fixada já estivesse contaminada?
    Permitir atualizações pode, na verdade, fortalecer a segurança
    Isso é parecido com o debate entre linkagem estática vs dinâmica
    Além disso, a Trivy Action de qualquer forma estava configurada para buscar a versão mais recente

• Este incidente é um alerta de que produtos de “segurança da cadeia de suprimentos (supply chain security)” podem, na prática, ser tão vulneráveis quanto a própria stack que pretendem proteger
  Em especial, ferramentas de segurança que “rodam em todo lugar” fornecem um novo vetor de ataque em que um único comprometimento pode colocar inúmeros usuários em risco ao mesmo tempo

• No começo achei que a Trivy não tivesse feito direito a rotação de credenciais
  Mas eles explicaram que “durante um processo de rotação não atômico (non-atomic), o atacante pode ter descoberto o novo token”
  O GitHub não volta a mostrar o token depois da emissão, mas isso pode variar conforme o método de autenticação usado

  • O criador do OpenClaw disse ter passado por algo parecido
    Assim que criou uma nova organização no GitHub, o nome foi sequestrado, e ele precisou pedir ao GitHub um processamento de criação atômico

• É um caso em que a frase “você deve escanear vulnerabilidades, não se tornar uma vulnerabilidade” cai como uma luva

  • A ponto de surgir a piada: “se você olhar para a vulnerabilidade, a vulnerabilidade também olha para você”

• Houve um caso relacionado em Comprometimento temporário da cadeia de suprimentos do Trivy

  • A expressão “temporário” parece um eufemismo demais

• Em 22 de março, o atacante publicou imagens maliciosas do Trivy v0.69.5 e v0.69.6 no DockerHub usando credenciais roubadas
  (link do aviso de segurança)
  Houve dois incidentes, em 19 e 22 de março, e o atacante aparentemente manteve acesso contínuo apesar de duas rotações de credenciais

  • Na prática, já havia um comprometimento completo do repositório desde fevereiro, e este foi o terceiro ataque bem-sucedido do mesmo invasor

• “As últimas duas semanas foram as piores”
  Por causa do comprometimento do Trivy, foi preciso lidar com uma enorme quantidade de relatórios e reuniões de segurança

• A lição é que “fazer software de segurança não significa necessariamente ser competente”
  Nossa equipe de segurança também tenta introduzir novos scanners todo mês, mas se tivéssemos permitido o amplo nível de acesso que eles pedem, já teríamos sido comprometidos várias vezes

  • Já fiz uma auditoria nas GitHub Actions do Trivy, e a Action setup-trivy clonava diretamente a branch principal e executava um script de shell
    Ou seja, havia possibilidade de execução arbitrária de código em todos os workflows de CI
    A Aqua foi comprometida no começo deste mês e, após duas falhas de contenção, até a conta do Docker Hub foi violada
    Agora acho que eles precisam da ajuda de especialistas externos
  • Dar amplo acesso a “ferramentas de segurança” não reduz risco, espalha risco
    A maioria é só um gerador barulhento de relatórios e não consegue oferecer nenhuma defesa quando um invasor entra no ambiente interno
    Um novo scanner deve acessar apenas dados em modo leitura dentro de um sandbox isolado, e não deve receber permissões de produção até ser validado o suficiente
    Caso contrário, isso não é muito diferente de postar a chave secreta no pastebin
  • Hoje em dia, a segurança corporativa virou instalar soluções de segurança de endpoint em todos os dispositivos e enviar todos os logs para um dashboard de IA
    Virou uma cultura de segurança de “mover rápido e quebrar tudo”
  • Na prática, os departamentos de segurança não têm a opção de dizer “não existe nada utilizável no mercado, então não vamos usar nada”
    Por isso surge uma cultura de adoção obrigatória até de software de segurança de baixa qualidade
    Acho que o Trivy em si não é ruim, e nossa empresa também o usa
    Só que nós fixamos a versão com Nix e escrevemos nossos próprios workflows de Actions, então não fomos afetados por este comprometimento

• O atacante, já autenticado, conseguiu fazer force-update de tags
  Isso teria sido evitado se tivessem apenas ativado a antiga configuração do GitHub de “proibir sobrescrita de tags”
  Quanto mais esse tipo de incidente se repete, mais forte fica a sensação de que precisamos de um padrão como um Software Building Code
  Fico curioso para saber quantos motivos a mais como esse vão surgir em 2026