Compromisso do Trivy espalha infostealer, worm e wiper contra ambientes Docker e Kubernetes

Versões maliciosas do scanner no Docker Hub e ações do GitHub foram associadas ao roubo de credenciais, propagação para pacotes npm e destruição seletiva de clusters Kubernetes.

Componente	Imagens Docker do Trivy nas versões 0.69.4, 0.69.5 e 0.69.6, além das ações aquasecurity/trivy-action e aquasecurity/setup-trivy.
Vetor	Uso de credencial comprometida para publicar versões trojanizadas, empurrar tags sem releases correspondentes e abusar de conta de serviço com acesso entre organizações GitHub.
Impacto	Distribuição do infostealer TeamPCP, comprometimento posterior de pacotes npm com CanisterWorm, exposição pública e alteração de 44 repositórios internos, além de wiper direcionado a hosts e clusters Kubernetes no Irã.
Prioridade	Remover o uso das versões afetadas, tratar execuções recentes do Trivy em CI/CD como potencialmente comprometidas, rotacionar segredos acessíveis pelos runners e fixar ações por hash de commit.
Versões	Última imagem limpa conhecida no Docker Hub: 0.69.3; imagens maliciosas removidas: 0.69.4, 0.69.5 e 0.69.6.
Artefatos	CanisterWorm, wiper kamikaze, conta de serviço Argon-DevOps-Mgt, organização GitHub aquasec-com e identificador CVE-2026-33634 com CVSS 9.4.

Resumo técnico

O incidente envolve uma cadeia de comprometimento de supply chain centrada no Trivy, scanner de vulnerabilidades mantido pela Aqua Security e amplamente usado em pipelines, imagens de contêiner e fluxos de validação de infraestrutura. O ponto operacional mais relevante é que versões publicadas no Docker Hub foram contaminadas depois da última imagem limpa conhecida, 0.69.3. As versões 0.69.4, 0.69.5 e 0.69.6 foram vinculadas a artefatos maliciosos e removidas do repositório de imagens. Dois desses identificadores, 0.69.5 e 0.69.6, apareceram sem releases ou tags equivalentes no GitHub, criando uma divergência importante entre o canal de distribuição de contêiner e a trilha esperada de publicação do projeto.

A atividade não ficou restrita à substituição de imagens. O mesmo conjunto de eventos foi relacionado a versões trojanizadas do Trivy e das ações aquasecurity/trivy-action e aquasecurity/setup-trivy, com uso de credencial comprometida para inserir um ladrão de credenciais nos fluxos de execução. Como essas ações são chamadas por pipelines automatizados, o risco defensivo não depende de interação humana direta depois que o workflow já está configurado. Um pipeline que referenciou uma tag afetada poderia executar código malicioso dentro do runner, no mesmo contexto em que variáveis de ambiente, tokens de registro, credenciais de cloud, chaves de publicação e permissões de repositório ficam temporariamente disponíveis.

A campanha também apresentou efeitos posteriores. Dados roubados na primeira etapa foram associados ao comprometimento de dezenas de pacotes npm usados para espalhar um worm autorreplicante chamado CanisterWorm. Em paralelo, um conjunto de 44 repositórios internos da organização GitHub aquasec-com foi alterado e exposto publicamente em um intervalo de aproximadamente dois minutos em 22 de março de 2026. A organização afetada é distinta da organização pública aquasecurity, mas continha material sensível de engenharia, incluindo código proprietário, forks internos do Trivy, pipelines de CI/CD, operadores Kubernetes e bases internas de conhecimento.

A escalada técnica mais grave foi a presença de um wiper chamado kamikaze, distribuído por meio do CanisterWorm e ligado à mesma infraestrutura de canister usada na campanha. Esse componente ampliou o escopo do incidente para ambientes Kubernetes e hosts acessíveis por SSH ou APIs Docker expostas. Em sistemas identificados como iranianos, o comportamento descrito foi destrutivo: em clusters Kubernetes, o malware implantava DaemonSets privilegiados nos nós; em hosts fora de Kubernetes, executava uma rotina de apagamento recursivo do sistema de arquivos. Em nós não iranianos, o fluxo observado favorecia persistência por serviço systemd para o backdoor CanisterWorm, em vez da destruição imediata.

Fluxo técnico

A cadeia começa com controle indevido sobre caminhos de publicação e execução confiados por equipes de desenvolvimento. A partir de uma credencial comprometida, o operador conseguiu disponibilizar artefatos maliciosos em locais que normalmente seriam tratados como fontes legítimas: tags de imagem no Docker Hub e tags de ações consumidas por workflows do GitHub. Esse padrão é especialmente perigoso porque muitos pipelines apontam para tags móveis, e não para hashes imutáveis de commit. Quando a tag passa a resolver para um conteúdo diferente, o runner executa a nova carga sem que o arquivo de workflow mude, reduzindo a visibilidade de revisão em pull requests.

Nas imagens Docker do Trivy, a anomalia de publicação é um sinal de alto valor: tags 0.69.5 e 0.69.6 foram publicadas em 22 de março sem correspondência pública em releases ou tags do GitHub. Para defesa, esse desvio entre repositório de origem e repositório de artefatos deve ser tratado como indicador estrutural de comprometimento, não apenas como erro operacional. O conteúdo malicioso foi associado ao infostealer TeamPCP, cujo objetivo era coletar credenciais presentes no ambiente de execução. Em runners de CI/CD, isso pode incluir tokens de GitHub, credenciais de npm, chaves de acesso a registros de contêiner, segredos injetados por cofres e permissões temporárias de provedores cloud.

O incidente também evidencia a fragilidade de contas de serviço com permissões atravessando domínios organizacionais. A conta Argon-DevOps-Mgt, descrita como serviço ou bot, tinha uma característica crítica: acesso a duas organizações GitHub relacionadas. Com um único token comprometido, o operador passou a ter capacidade de escrita ou administração em mais de um perímetro lógico. Esse desenho permitiu a alteração coordenada dos 44 repositórios da organização aquasec-com, com renomeação em massa usando prefixo tpcp-docs-, mudança de descrições e exposição pública. A janela de alteração, entre 20:31:07 UTC e 20:32:26 UTC de 22 de março de 2026, sugere automação, não operação manual repositório por repositório.

A etapa de worm ampliou o dano para a cadeia npm. O CanisterWorm foi usado para propagação por pacotes comprometidos e também serviu como canal para distribuir o wiper kamikaze. O fluxo do wiper tinha ramificações por ambiente: em Kubernetes, tentava operar por DaemonSets privilegiados para alcançar todos os nós, inclusive plano de controle; em hosts sem Kubernetes, o comportamento dependia de identificação geográfica do sistema; em ambientes não iranianos, priorizava instalação persistente do backdoor. A campanha também explorava chaves SSH roubadas e APIs Docker expostas na porta 2375 dentro de sub-redes locais, aumentando o risco em redes onde o daemon Docker foi deixado sem proteção adequada.

Superfície afetada

A superfície principal inclui qualquer ambiente que tenha executado as versões afetadas do Trivy a partir do Docker Hub ou consumido as ações GitHub relacionadas durante a janela do comprometimento. O risco é maior em pipelines que executam scanners com acesso amplo ao repositório, ao registro de imagens e a credenciais de publicação. Mesmo quando o objetivo do job é apenas analisar dependências ou imagens, o runner costuma carregar segredos suficientes para permitir movimentação para outros serviços de engenharia. Por isso, a avaliação deve considerar não somente o binário executado, mas todos os segredos disponíveis no contexto do workflow.

Também entram no escopo organizações que usavam contas de serviço compartilhadas entre múltiplas organizações GitHub ou com permissões administrativas persistentes. O caso da conta Argon-DevOps-Mgt mostra que um token de longa duração pode transformar um incidente localizado em comprometimento transversal. Repositórios internos com pipelines, operadores Kubernetes, forks privados e documentação técnica são alvos valiosos porque revelam arquitetura, nomes de serviços, fluxos de deploy e caminhos de credenciais. A publicação indevida desses repositórios amplia o impacto mesmo quando produtos comerciais não apresentam evidência de comprometimento direto.

• Pipelines de CI/CD que referenciaram aquasecurity/trivy-action ou aquasecurity/setup-trivy por tag em vez de hash de commit.
• Execuções das imagens Docker do Trivy 0.69.4, 0.69.5 ou 0.69.6, especialmente em runners com segredos injetados.
• Ambientes com API Docker exposta na porta 2375, principalmente quando acessível em sub-redes internas.
• Clusters Kubernetes onde cargas privilegiadas podem ser criadas por credenciais comprometidas.
• Organizações GitHub com contas de serviço ou bots que atravessam fronteiras entre repositórios internos e projetos públicos.

Hunting e telemetria

A investigação defensiva deve começar pela reconstrução de execuções. Em GitHub Actions, é necessário revisar históricos de workflows, versões resolvidas de ações, hashes de commit efetivamente usados, logs de runners e eventos de acesso a segredos no período próximo à publicação das tags afetadas. A divergência entre tag de ação e commit esperado é um sinal forte. Também é importante identificar jobs que executaram Trivy em contêiner, porque a imagem maliciosa poderia acessar variáveis do ambiente, diretórios montados e credenciais disponibilizadas para o job. Logs de registro de contêiner devem ser correlacionados com pull de tags 0.69.4, 0.69.5 e 0.69.6.

Em GitHub, a telemetria precisa cobrir eventos de criação, atualização, force push, alteração de visibilidade, renomeação de repositórios, mudança de descrição e uso de tokens por contas de serviço. A janela de modificação dos 44 repositórios internos fornece um padrão temporal claro para correlação: múltiplas alterações administrativas em sequência curta, feitas pela mesma identidade técnica, são comportamento incompatível com manutenção comum. Em ambientes npm, a defesa deve procurar publicações inesperadas feitas com credenciais que também estiveram disponíveis em runners afetados, alterações de pacotes sem revisão equivalente e mudanças em lockfiles que passem a resolver versões publicadas depois do comprometimento.

Para Kubernetes e endpoints, o foco passa a ser execução privilegiada e persistência. A criação de DaemonSets com privilégios elevados, especialmente em todos os nós ou no plano de controle, deve gerar alerta imediato. Em hosts Linux, serviços systemd recém-criados ou modificados, chaves SSH usadas fora do padrão, conexões para infraestrutura de canister associada à campanha e atividade Docker remota na porta 2375 são sinais relevantes. No caso do wiper, a ausência de artefatos após execução destrutiva pode limitar a perícia local; por isso, logs remotos, auditoria do Kubernetes API Server, EDR e telemetria de rede preservada fora do host são essenciais.

• Pull das imagens trivy:0.69.4, trivy:0.69.5 ou trivy:0.69.6 em registros, runners e caches de CI/CD.
• Workflows que resolveram ações Trivy para commits não esperados ou tags publicadas sem release correspondente.
• Uso da conta Argon-DevOps-Mgt ou de bots equivalentes para alterações administrativas em massa.
• Criação de DaemonSets privilegiados, contêineres nomeados como kamikaze ou serviços systemd vinculados ao CanisterWorm.
• Acessos a Docker API na porta 2375 e autenticações SSH com chaves que estiveram presentes em runners afetados.

Mitigação

A resposta deve tratar qualquer execução recente das versões afetadas como evento de exposição de credenciais. A primeira medida é interromper o uso de 0.69.4, 0.69.5 e 0.69.6, voltar para versão limpa conhecida ou versão corrigida validada por trilha de release confiável, e limpar caches de runners e registros internos que possam manter camadas contaminadas. Em paralelo, workflows que usam ações do Trivy devem deixar de depender de tags móveis e passar a fixar hashes de commit auditados. Essa mudança reduz o risco de substituição silenciosa de conteúdo quando uma tag é reescrita ou publicada indevidamente.

A rotação de segredos precisa ser guiada pelo alcance real dos jobs. Tokens de GitHub, credenciais de npm, chaves de cloud, senhas de registros de contêiner, chaves SSH e credenciais de publicação acessíveis durante execuções afetadas devem ser revogados e recriados. Contas de serviço com acesso a múltiplas organizações exigem revisão de escopo, expiração curta de tokens e separação por domínio administrativo. Quando uma identidade técnica atravessa projetos públicos e repositórios internos, o blast radius deixa de ser local; o desenho defensivo deve limitar permissões por função e por ambiente.

Nos clusters Kubernetes, a mitigação exige auditoria de objetos privilegiados, remoção de DaemonSets suspeitos, validação de RBAC, revisão de secrets e verificação de nós que possam ter recebido cargas persistentes. Ambientes com Docker API aberta na porta 2375 devem restringir exposição, exigir autenticação adequada e revisar logs de acesso. Em repositórios e pacotes, equipes devem verificar lockfiles, histórico de publicação, permissões de maintainers e tokens de automação. O objetivo operacional não é apenas remover o artefato malicioso, mas fechar o caminho que permitiu publicação, execução e reutilização de credenciais roubadas.

• Bloquear e remover imagens 0.69.4, 0.69.5 e 0.69.6 de caches, registros internos e pipelines.
• Fixar ações GitHub por hash de commit e revisar qualquer workflow que referencie tags móveis para ferramentas de segurança.
• Revogar tokens e chaves acessíveis por execuções afetadas, priorizando credenciais de GitHub, npm, cloud, SSH e registros de contêiner.
• Separar contas de serviço por organização e reduzir permissões administrativas persistentes em bots de CI/CD.
• Auditar Kubernetes para DaemonSets privilegiados, serviços persistentes inesperados e atividade vinculada ao CanisterWorm ou ao wiper kamikaze.