Trivy ecosystem supply chain briefly compromised

Entre 19 e 23 de março de 2026, um ator de ameaça usou credenciais comprometidas para publicar artefatos maliciosos em três repositórios do ecossistema Aqua Trivy — o binário/imagem trivy v0.69.4 (e depois v0.69.5/v0.69.6 só no Docker Hub), 76 das 77 tags do GitHub Action trivy-action, e todas as 7 tags do setup-trivy. O CVSS 9.4 reflete o impacto real: quem executou essas versões em pipeline de CI/CD teve memória de processo e sistema de arquivos varridos por um infostealer que rouba credenciais de nuvem, SSH, Kubernetes e carteiras cripto. É a continuação direta de um incidente de fevereiro/março de 2026 que não foi contido de forma atômica — rotação de credenciais parcial permitiu ao atacante reter acesso e reaproveitá-lo.

Não é uma falha de código no Trivy em si, mas um comprometimento de cadeia de suprimentos (supply chain compromise, próximo de CWE-506 Embedded Malicious Code / CWE-829 Inclusion of Functionality from Untrusted Control Sphere) via credenciais de release comprometidas. No trivy v0.69.4, o atacante empurrou um commit que trocou a referência do actions/checkout por um commit impostor contendo uma composite action que baixava código-fonte Go malicioso de um domínio typosquat, adicionou `--skip=validate` ao goreleaser para pular a validação do binário, e tagueou esse commit como v0.69.4, disparando o pipeline de release oficial — o artefato malicioso saiu por todos os canais legítimos (GHCR, ECR Public, Docker Hub, deb/rpm, get.trivy.dev).

No trivy-action, o atacante fez force-push em 76 das 77 tags de versão para commits que injetavam um infostealer no entrypoint.sh, executado antes do scan real do Trivy. No setup-trivy, as 7 tags existentes (v0.2.0–v0.2.6) foram substituídas por commits que injetavam o mesmo malware no action.yaml, como um passo 'Setup environment' que roda antes da instalação legítima do Trivy.

O malware injetado despeja a memória do processo do runner via /proc//mem para extrair segredos, varre mais de 50 caminhos de sistema de arquivos por chaves SSH, credenciais AWS/GCP/Azure, tokens Kubernetes, configs Docker, arquivos .env, credenciais de banco e carteiras cripto, criptografa tudo com AES-256-CBC + RSA-4096 híbrido e exfiltra para infraestrutura do atacante. Se a exfiltração falha e a variável INPUT_GITHUB_PAT estiver definida, o malware cria um repositório público chamado 'tpcp-docs' na conta GitHub da vítima e sobe os dados roubados como release asset — um mecanismo desenhado para funcionar mesmo com egress bloqueado.

Em 22 de março houve um segundo incidente separado: credenciais do Docker Hub (diferentes das do GitHub) foram usadas para publicar diretamente aquasec/trivy:0.69.5 e 0.69.6 com o mesmo domínio de C2, sem tags ou releases correspondentes no GitHub — evidência de que o comprometimento atingiu mais de um sistema de credenciais.

O vetor não é um usuário final do Trivy sendo atacado diretamente, mas qualquer pipeline de CI/CD (GitHub Actions, builds automatizados) que baixou e executou uma das versões comprometidas durante a janela de exposição — poucas horas a até ~12 horas, dependendo do componente. Pré-condições reais: (1) ter referenciado trivy-action ou setup-trivy por tag mutável (não por SHA fixo) ou pelo parâmetro `version: latest` explícito durante a janela; (2) ter baixado o binário/imagem trivy v0.69.4 (ou v0.69.5/0.69.6 via Docker Hub) por tag, e não por digest; quem referenciava por SHA pin de commit seguro ou por digest de imagem não foi afetado. O código malicioso executa automaticamente no runner antes do próprio scan de segurança do Trivy — não exige interação do usuário, só que o pipeline chame a ação/binário.

O efeito colateral mais grave já confirmado é o comprometimento da cadeia do LiteLLM: segundo a própria equipe do BerriAI, 'o comprometimento veio de uma dependência de scan de segurança trivvy/trivy' na CI deles. Isso permitiu que um atacante (conta 'teampcp') sequestrasse a conta de mantenedor do PyPI (krrishdholakia) e publicasse diretamente no PyPI as versões 1.82.7 e 1.82.8 do pacote litellm — versões que nunca passaram pelo CI/CD oficial do GitHub (que só chegou a v1.82.6.dev1). A versão 1.82.7 embute o payload em proxy_server.py, disparado ao importar litellm.proxy; a 1.82.8 adiciona um arquivo litellm_init.pth de 34.628 bytes que executa em qualquer inicialização do Python, sem necessidade de import — mesmo modus operandi de coleta (SSH, env vars, credenciais de nuvem, carteiras cripto), mesma criptografia AES-256-CBC+RSA-4096, exfiltrando para o domínio typosquat models.litellm.cloud (registrado horas antes do ataque).

A CVE está no catálogo KEV da CISA com exploração confirmada — não é um cenário teórico. O impacto final obtido pelo atacante em ambos os casos (Trivy e LiteLLM) é exfiltração de credenciais de produção/nuvem presentes no ambiente de CI, o que abre caminho para movimento lateral, comprometimento de outros pipelines e potencialmente novos ataques de cadeia de suprimentos usando os segredos roubados.

Atualize para as versões seguras confirmadas pelo fornecedor: trivy binário/imagem v0.69.3 (protegida por immutable releases do GitHub, habilitado em 3 de março, antes de ser publicada) ou v0.69.2 verificável via assinatura sigstore; trivy-action tag 0.35.0 (commit 57a97c7, também protegida por immutable releases); setup-trivy v0.2.6 recriada com commit seguro 3fb12ec. Referenciar por digest de imagem ou SHA de commit — não por tag mutável — é o controle compensatório real quando não é possível atualizar imediatamente, já que tags podem ser force-pushed novamente.

Se você executou qualquer versão dentro das janelas de exposição (trivy v0.69.4: 19/03 ~18:22–21:42 UTC; v0.69.5/0.69.6 no Docker Hub: 22/03 15:43–23/03 ~01:40; trivy-action: 19/03 ~17:43–20/03 ~05:40; setup-trivy: 19/03 ~17:43–21:44), trate todos os segredos presentes naquele pipeline como comprometidos e rotacione imediatamente — não basta trocar a versão do Trivy. Bloqueie no perímetro de rede o domínio de C2 scan.aquasecurtiy.org (typosquat de aquasecurity) e o IP 45.148.10.212. Quem usa litellm 1.82.7 ou 1.82.8 deve verificar a existência de litellm_init.pth em site-packages/, remover o pacote, rotacionar todas as credenciais presentes como variáveis de ambiente ou arquivo de configuração no sistema afetado, e checar se surgiu um repositório público inesperado chamado 'tpcp-docs' na conta GitHub usada pelo pipeline (indício do mecanismo de exfiltração de fallback).

O que não funciona como mitigação suficiente: apenas fixar uma versão em lockfile ou requirements.txt sem verificar integridade de origem — como apontado na discussão dos mantenedores, isso não impede bypasses conhecidos em tempo de instalação quando a fonte de distribuição (tag, registry) já está comprometida. Rotação de credenciais não atômica também não resolve — foi justamente essa falha, no incidente de março, que permitiu ao atacante reter acesso e executar o segundo ataque.

Nos pipelines de CI, procure por conexões de saída para o domínio scan.aquasecurtiy.org (nota o typo em 'aquasecurtiy') ou para o IP 45.148.10.212 durante execuções de jobs que usam trivy, trivy-action ou setup-trivy nas janelas de exposição informadas. Verifique se surgiu um repositório público inesperado chamado 'tpcp-docs' em contas GitHub usadas por essas pipelines, com um release asset contendo dados criptografados — é o mecanismo de exfiltração de fallback do malware. Para ambientes com litellm, verifique a presença do arquivo litellm_init.pth (SHA256 ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg, 34.628 bytes) em site-packages/ e tráfego de saída para models.litellm.cloud (domínio distinto do oficial litellm.ai, registrado em 23/03/2026). Se você usou tag mutável ou 'latest' fora das janelas exatas informadas pelo fornecedor, não há sinal confiável de comprometimento retroativo — a única garantia é verificar hash/digest do artefato baixado contra os hashes seguros publicados no advisory.