Ataques à cadeia de suprimentos via Trivy e LiteLLM

Milhões de pipelines de desenvolvimento de software automatizados dependem de ferramentas de segurança, como Trivy e Checkmarx AST, integradas ao processo de compilação. E foram essas soluções confiáveis que recentemente se tornaram o ponto de entrada para um dos maiores e mais perigosos ataques contra a cadeia de suprimentos da história moderna. Nesta postagem, discutiremos como auditar os fluxos de trabalho automatizados e como proteger a infraestrutura de nuvem corporativa.

Linha do tempo do ataque e as consequências conhecidas

Em 19 de março, um ataque direcionado e bem-sucedido contra a cadeia de suprimentos foi realizado por meio do Trivy, uma ferramenta de verificação de vulnerabilidades de código aberto amplamente usada em pipelines de CI/CD. Os invasores, um grupo conhecido como TeamPCP, conseguiram injetar malware nos fluxos de trabalho oficiais do GitHub Actions e nas imagens do Docker associadas ao Trivy. Com isso, cada verificação automatizada de pipeline feita acionou um malware que roubou chaves SSH, tokens de acesso à nuvem, carteiras de criptomoedas e outros dados valiosos dos sistemas comprometidos. Dada a natureza crítica do incidente, o identificador CVE-2026-33634 foi atribuído a ele, com uma pontuação CVSS4B, praticamente máxima, de 9,4.

Mais tarde, naquele mesmo dia, a equipe do Trivy detectou o ataque, removeu os artefatos maliciosos dos canais de distribuição e interrompeu aquela fase do ataque. No entanto, os invasores já tinham conseguido acessar os ambientes de muitos usuários do Trivy.

Em 23 de março, um incidente semelhante foi descoberto em outra ferramenta de segurança do aplicativo: um GitHub Action para Checkmarx KICS, e também, para Checkmarx AST. Três horas depois, o código malicioso foi então removido do ambiente. O TeamPCP também conseguiu comprometer as extensões do OpenVSX compatíveis com Checkmarx: cx-dev-assist 1.7.0 e ast-results. Os relatórios que indicam quando ocorreu o momento da resolução dessa parte do incidente variam.

Em 24 de março, um projeto popular que usa a verificação de código do Trivy (o gateway LiteLLM AI, que nada mais é do que uma biblioteca universal para acesso a vários provedores de LLM) foi atacado. As versões 1.82.7 e 1.82.8, carregadas no repositório PyPI, foram comprometidas. Essas versões ficaram disponíveis publicamente por cerca de cinco horas.

Mas o fato do ataque ter durado apenas algumas horas não é motivo para desconsiderar o evento. Dada a popularidade dos projetos afetados, o código malicioso pode ter sido executado milhares de vezes, inclusive dentro da infraestrutura de empresas muito grandes.

Isso permitiu que os invasores não só implementassem backdoors persistentes em clusters do Kubernetes, mas também iniciassem o CanisterWorm autorreplicante no ecossistema npm do JavaScript.

O código dos invasores tem recursos destrutivos que eliminam um cluster Kubernetes, e todos os seus nós, se o fuso horário de Teerã ou o farsi for detectado como idioma principal no sistema comprometido. Em outras regiões, o malware simplesmente rouba dados com o uso do CanisterWorm.

De acordo com especialistas, mais de 20 mil repositórios são considerados suscetíveis a ataques. Os invasores alegam ter roubado centenas de gigabytes de dados e mais de 500 mil contas.

Como o Trivy foi atacado

Para comprometer o Trivy, os invasores usaram as credenciais roubadas em um incidente anterior. O comprometimento anterior do Trivy, ocorrido no final de fevereiro, provavelmente não foi contido de forma plena, e os invasores, ou seja, o mesmo grupo TeamPCP, retornaram com um novo ataque. A Aqua Security, por meio de sua equipe de desenvolvedores do Trivy, especula que, como as credenciais estavam sendo eliminadas gradualmente após o incidente anterior, os invasores conseguiram gerar novos tokens de acesso para si mesmos antes que os antigos comprometidos fossem revogados.

Com isso, os invasores do grupo TeamPCP conseguiram comprometer o GitHub Actions usado em pipelines de CI/CD. Com o uso de credenciais com privilégios de gravação de tags, os invasores forçaram a substituição de 76 das 77 tags de versão no aquasecurity/trivy-action, além de todas as 7 tags no aquasecurity/setup-trivy, e redirecionaram as versões confiáveis existentes para as versões maliciosas. Essa tática de ataque se assemelha com as táticas observadas na campanha Shai-Hulud 2.0. Com isso, os fluxos de trabalho em todo o pipeline começaram a executar o código dos invasores, porém, os metadados da versão não mostravam as alterações visíveis.

Paralelamente a isso, os invasores publicaram um binário Trivy infectado (v0.69.4) nos canais de distribuição oficiais, inclusive com versões do GitHub e registros de contêiner.

Comprometimento da ferramenta LiteLLM

O comprometimento da popular ferramenta de acesso ao modelo de linguagem LiteLLM pode desencadear, por si só, uma grande onda de ataques em toda a cadeia de projetos que utiliza o recurso. O ataque ocorreu em 24 de março de 2026, quando os invasores do TeamPCP publicaram diretamente as versões maliciosas da biblioteca (1.82.7 e 1.82.8) no PyPI. Entre 10:39 UTC e 16:00 UTC, esses pacotes comprometidos continham malware que roubava credenciais. Ele foi integrado no arquivo proxy_server.py, e a versão 1.82.8 também continha um arquivo litellm_init malicioso. Os dados roubados foram exfiltrados para o servidor models.litellm[.]cloud.

Os clientes que usam o LiteLLM Cloud ou a imagem oficial do LiteLLM Proxy Docker não foram afetados devido ao bloqueio estrito da versão, enquanto os desenvolvedores e os projetos de downstream que instalaram as versões não fixadas pelo pip, durante a janela de tempo especificada, foram comprometidos.

Em três horas, os pacotes maliciosos foram removidos do repositório PyPI, e a equipe do LiteLLM suspendeu as novas versões, atualizou as credenciais e envolveu um processo externo de resposta a incidentes. As equipes que usam o LiteLLM em seus projetos são aconselhadas a verificar imediatamente o indicador de comprometimento litellm_init.pth e atualizar rotineiramente todos os segredos que possam estar comprometidos.

Recursos do malware TeamPCP Cloud Stealer

Os invasores adicionaram uma nova lógica ao GitHub Actions, ao executável do Trivy e preservaram a funcionalidade original. Os resultados da verificação de vulnerabilidades por meio do Trivy pareciam normais, mas, ao mesmo tempo, dados valiosos estavam sendo pesquisados e extraídos. O código malicioso atuava da seguinte maneira:

• realizando reconhecimento (coletando dados de rede e variáveis de ambiente);
• procurando tokens e credenciais para acessar ambientes de nuvem AWS e GCP;
• verificando a memória (/proc/*/mem ) para extrair segredos armazenados na memória dos processos Runner.Worker e Runner.Listener;
• extraindo segredos do Kubernetes (/run/secrets/kubernetes.io/serviceaccount);
• coletando dados para conexão com servidores de banco de dados (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• coletando quaisquer outras chaves e segredos de API de arquivos de ambiente e arquivos de configuração de CI/CD (.env, .json, .yml);
• pesquisando webhooks para canais Slack e Discord;
• procurando dados relativos às carteiras de criptomoedas (variáveis relativas ao blockchain Solana, além de dados rpcuser e rpcpassword).

Os dados coletados foram criptografados e carregados em um servidor com um nome semelhante ao dos desenvolvedores do Trivy (scan.aquasecurtiy[.]org). Como se fosse um mecanismo de backup, os invasores forneceram um método para carregar os dados em um repositório denominado docs-tpcp.

O ataque ao CheckMarx e ao LiteLLM usou uma tática semelhante aos outros domínios de typosquatting: models.litellm[.]cloud e checkmarx[.]zone.

Uma análise técnica detalhada do malware, juntamente com indicadores de comprometimento, pode ser encontrada no artigo de nosso especialista no blog Securelist.

Estratégias de resposta e defesa ao CVE-2026-33634

As verificações baseadas em assinatura e as verificações de dependência existentes em registros públicos não são mais suficientes, pois o código malicioso foi injetado diretamente em ações confiáveis e assinadas, o que fez com que a detecção fosse burlada até que o monitoramento comportamental fosse aplicado. Os pipelines de CI/CD se tornaram o “novo perímetro” de segurança.

Ações imediatas. Verifique e confirme se todos os fluxos de trabalho usam versões seguras (Trivy binary 0.69.3, trivy-action 0.35.0 e setup-trivy 0.2.6).

Os administradores de pipeline de CI/CD e as equipes de segurança devem revisar imediatamente as dependências das soluções Checkmarx (kics-github-action e ast-github-action) e Trivy (setup-trivy e trivy-action). Se os fluxos de trabalho fizerem referência a uma tag de versão em vez de um hash SHA específico, revise cuidadosamente os logs de execução do fluxo de trabalho durante o ataque ativo contra a cadeia de suprimentos.

Também é necessário verificar os logs de rede quanto ao tráfego para os domínios scan.aquasecurtiy[.]org, checkmarx[.]zone e models.litellm[.]cloud. A presença desse tráfego indica que os dados confidenciais foram exfiltrados com êxito.

Se um repositório denominado docs-tpcp tiver aparecido no GitHub da organização, isso também poderá indicar uma violação bem-sucedida de dados.

Verifique os hosts e clusters quanto aos sinais de comprometimento, ou seja, a presença de arquivos ~/.config/sysmon/sysmon.py, isto é, pods suspeitos no Kubernetes.

Limpe o cache e realize um inventário dos módulos PyPI: verifique se há módulos maliciosos e reverta para versões limpas.

Em qualquer caso, uma identificação proativa de ameaças deve ser realizada, tendo em vista que os sistemas tenham sido comprometidos com êxito e que os invasores avançaram rapidamente dentro dos sistemas afetados.

É recomendável restaurar os ambientes afetados por meio de backups verificados.

Fixação de dependências e gerenciamento de segredos. Verifique e confirme se as versões de dependência exatas estão fixadas com o uso de hashes criptográficos em todos os pipelines e Dockerfiles. Aconselhamos fazer a transição de tokens de longa duração para credenciais de curta duração com o uso de uma ferramenta de gerenciamento de segredos e fazer a implementação de integrações OIDC onde houver compatibilidade. Minimize a injeção de segredos no ambiente de tempo de execução, faça isso apenas quando for absolutamente necessário. Verifique e confirme se os segredos não estão armazenados em disco ou em arquivos temporários, e se eles não estão sendo reutilizados em processos diferentes.

Atualize todas as credenciais que possam estar comprometidas, ou seja, chaves de API, variáveis de ambiente, chaves SSH, tokens de conta de serviço do Kubernetes e outros segredos.

Outras medidas de segurança. Permita apenas o uso do GitHub Actions originado por uma lista aprovada pela organização e bloqueie os processos novos e não verificados. Configure o GITHUB_TOKEN e outras chaves de acesso de acordo com o princípio do privilégio mínimo. Não conceda permissões de gravação, a menos que seja absolutamente necessário.

Para aumentar a segurança do GitHub Actions, há várias ferramentas de código aberto disponíveis:

• zizmor: uma ferramenta para análise estática e detecção de erros de configuração no GitHub Actions;
• gato e Gato-X: duas versões de uma ferramenta que ajuda a identificar pipelines estruturalmente vulneráveis;
• allstar: um aplicativo do GitHub, desenvolvido pelo OpenSSF, para configurar e aplicar políticas de segurança em organizações e repositórios do GitHub.

Se quiser saber mais detalhes sobre os ataques contra a cadeia de suprimentos, deixamos aqui o nosso convite para consultar o relatório analítico Reação da cadeia de suprimentos: proteção ao ecossistema digital global em uma era de interdependência. Ele é baseado em insights de especialistas técnicos e revela com que frequência as organizações enfrentam os riscos para a cadeia de suprimentos e de relacionamento confiável, onde permanecem as lacunas de proteção e quais são as estratégias que devem ser empregadas para melhorar a resiliência contra esses tipos de ameaças.