Milh\u00f5es de pipelines de desenvolvimento de software automatizados dependem de ferramentas de seguran\u00e7a, como Trivy e Checkmarx AST, integradas ao processo de compila\u00e7\u00e3o. E foram essas solu\u00e7\u00f5es confi\u00e1veis que recentemente se tornaram o ponto de entrada para um dos maiores e mais perigosos ataques <\/u>contra a cadeia de suprimentos da hist\u00f3ria moderna. Nesta postagem, discutiremos como auditar os fluxos de trabalho automatizados e como proteger a infraestrutura de nuvem corporativa.<\/p>\nLinha do tempo do ataque e as consequ\u00eancias conhecidas<\/h2>\n
Em 19 de mar\u00e7o, um ataque direcionado e bem-sucedido contra a cadeia de suprimentos foi realizado por meio do Trivy, uma ferramenta de verifica\u00e7\u00e3o de vulnerabilidades de c\u00f3digo 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\u00e7\u00e3o automatizada de pipeline feita acionou um malware que roubou chaves SSH, tokens de acesso \u00e0 nuvem, carteiras de criptomoedas e outros dados valiosos dos sistemas comprometidos. Dada a natureza cr\u00edtica do incidente, o identificador CVE-2026-33634<\/a> foi atribu\u00eddo a ele, com uma pontua\u00e7\u00e3o CVSS4B, praticamente m\u00e1xima, de 9,4.<\/p>\n Mais tarde, naquele mesmo dia, a equipe do Trivy detectou o ataque, removeu os artefatos maliciosos dos canais de distribui\u00e7\u00e3o e interrompeu aquela fase do ataque. No entanto, os invasores j\u00e1 tinham conseguido acessar os ambientes de muitos usu\u00e1rios do Trivy.<\/p>\n Em 23 de mar\u00e7o, um incidente semelhante<\/a> foi descoberto em outra ferramenta de seguran\u00e7a do aplicativo: um GitHub Action para Checkmarx KICS, e tamb\u00e9m, para Checkmarx AST. Tr\u00eas horas depois, o c\u00f3digo malicioso foi ent\u00e3o removido do ambiente. O TeamPCP tamb\u00e9m conseguiu comprometer as extens\u00f5es do OpenVSX<\/a> compat\u00edveis com Checkmarx: cx-dev-assist<\/em> 1.7.0 e ast-results<\/em>. Os relat\u00f3rios que indicam quando ocorreu o momento da resolu\u00e7\u00e3o dessa parte do incidente variam.<\/p>\n Em 24 de mar\u00e7o, um projeto popular que usa a verifica\u00e7\u00e3o de c\u00f3digo do Trivy (o gateway LiteLLM AI, que nada mais \u00e9 do que uma biblioteca universal para acesso a v\u00e1rios provedores de LLM) foi atacado. As vers\u00f5es 1.82.7 e 1.82.8, carregadas no reposit\u00f3rio PyPI, foram comprometidas. Essas vers\u00f5es ficaram dispon\u00edveis publicamente por cerca de cinco horas.<\/p>\n Mas o fato do ataque ter durado apenas algumas horas n\u00e3o \u00e9 motivo para desconsiderar o evento. Dada a popularidade dos projetos afetados, o c\u00f3digo malicioso pode ter sido executado milhares de vezes, inclusive dentro da infraestrutura de empresas muito grandes.<\/p>\n Isso permitiu que os invasores n\u00e3o s\u00f3 implementassem backdoors persistentes em clusters do Kubernetes, mas tamb\u00e9m iniciassem o CanisterWorm<\/a> autorreplicante no ecossistema npm do JavaScript.<\/p>\n O c\u00f3digo dos invasores tem recursos destrutivos<\/a> que eliminam um cluster Kubernetes, e todos os seus n\u00f3s, se o fuso hor\u00e1rio de Teer\u00e3 ou o farsi for detectado como idioma principal no sistema comprometido. Em outras regi\u00f5es, o malware simplesmente rouba dados com o uso do CanisterWorm.<\/p>\n De acordo com especialistas, mais de 20 mil reposit\u00f3rios s\u00e3o considerados suscet\u00edveis a ataques. Os invasores alegam ter roubado centenas de gigabytes de dados e mais de 500 mil contas<\/a>.<\/p>\n Para comprometer o Trivy, os invasores usaram as credenciais roubadas em um incidente anterior. O comprometimento anterior do Trivy<\/a>, ocorrido no final de fevereiro, provavelmente n\u00e3o 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<\/a> que, como as credenciais estavam sendo eliminadas gradualmente ap\u00f3s o incidente anterior, os invasores conseguiram gerar novos tokens de acesso para si mesmos antes que os antigos comprometidos fossem revogados.<\/p>\n 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\u00e9gios de grava\u00e7\u00e3o de tags, os invasores for\u00e7aram a substitui\u00e7\u00e3o de 76 das 77 tags de vers\u00e3o no aquasecurity\/trivy-action, al\u00e9m de todas as 7 tags no aquasecurity\/setup-trivy, e redirecionaram as vers\u00f5es confi\u00e1veis existentes para as vers\u00f5es maliciosas. Essa t\u00e1tica de ataque se assemelha com as t\u00e1ticas observadas na campanha Shai-Hulud 2.0<\/a>. Com isso, os fluxos de trabalho em todo o pipeline come\u00e7aram a executar o c\u00f3digo dos invasores, por\u00e9m, os metadados da vers\u00e3o n\u00e3o mostravam as altera\u00e7\u00f5es vis\u00edveis.<\/p>\n Paralelamente a isso, os invasores publicaram um bin\u00e1rio Trivy infectado (v0.69.4) nos canais de distribui\u00e7\u00e3o oficiais, inclusive com vers\u00f5es do GitHub e registros de cont\u00eainer.<\/p>\n O comprometimento da popular ferramenta de acesso ao modelo de linguagem LiteLLM pode desencadear, por si s\u00f3, uma grande onda de ataques em toda a cadeia de projetos que utiliza o recurso. O ataque ocorreu em 24 de mar\u00e7o de 2026, quando os invasores do TeamPCP publicaram diretamente as vers\u00f5es 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<\/em>, e a vers\u00e3o 1.82.8 tamb\u00e9m continha um arquivo litellm_init<\/em> malicioso. Os dados roubados foram exfiltrados para o servidor models.litellm[.]cloud<\/em>.<\/p>\n Os clientes que usam o LiteLLM Cloud ou a imagem oficial do LiteLLM Proxy Docker n\u00e3o foram afetados devido ao bloqueio estrito da vers\u00e3o, enquanto os desenvolvedores e os projetos de downstream que instalaram as vers\u00f5es n\u00e3o fixadas pelo pip, durante a janela de tempo especificada, foram comprometidos.<\/p>\n Em tr\u00eas horas, os pacotes maliciosos foram removidos do reposit\u00f3rio PyPI, e a equipe do LiteLLM suspendeu as novas vers\u00f5es, atualizou as credenciais e envolveu um processo externo de resposta a incidentes. As equipes que usam o LiteLLM em seus projetos s\u00e3o aconselhadas a verificar imediatamente o indicador de comprometimento litellm_init.pth<\/em> e atualizar rotineiramente todos os segredos que possam estar comprometidos.<\/p>\n Os invasores adicionaram uma nova l\u00f3gica ao GitHub Actions, ao execut\u00e1vel do Trivy e preservaram a funcionalidade original. Os resultados da verifica\u00e7\u00e3o de vulnerabilidades por meio do Trivy pareciam normais, mas, ao mesmo tempo, dados valiosos estavam sendo pesquisados e extra\u00eddos. O c\u00f3digo malicioso atuava da seguinte maneira:<\/p>\n Os dados coletados foram criptografados e carregados em um servidor com um nome semelhante ao dos desenvolvedores do Trivy (scan.aquasecurtiy[.]org<\/em>). Como se fosse um mecanismo de backup, os invasores forneceram um m\u00e9todo para carregar os dados em um reposit\u00f3rio denominado docs-tpcp<\/em>.<\/p>\n O ataque ao CheckMarx e ao LiteLLM usou uma t\u00e1tica semelhante aos outros dom\u00ednios de typosquatting: models.litellm[.]cloud<\/em> e checkmarx[.]zone<\/em>.<\/p>\n Uma an\u00e1lise t\u00e9cnica detalhada do malware, juntamente com indicadores de comprometimento, pode ser encontrada no artigo de nosso especialista no blog Securelist<\/a>.<\/p>\n As verifica\u00e7\u00f5es baseadas em assinatura e as verifica\u00e7\u00f5es de depend\u00eancia existentes em registros p\u00fablicos n\u00e3o s\u00e3o mais suficientes, pois o c\u00f3digo malicioso foi injetado diretamente em a\u00e7\u00f5es confi\u00e1veis e assinadas, o que fez com que a detec\u00e7\u00e3o fosse burlada at\u00e9 que o monitoramento comportamental fosse aplicado. Os pipelines de CI\/CD se tornaram o \u201cnovo per\u00edmetro\u201d de seguran\u00e7a.<\/p>\n A\u00e7\u00f5es imediatas. <\/strong>Verifique e confirme se todos os fluxos de trabalho usam vers\u00f5es seguras (Trivy binary 0.69.3, trivy-action 0.35.0 e setup-trivy 0.2.6).<\/p>\n Os administradores de pipeline de CI\/CD e as equipes de seguran\u00e7a devem revisar imediatamente as depend\u00eancias das solu\u00e7\u00f5es Checkmarx (kics-github-action e ast-github-action) e Trivy (setup-trivy e trivy-action). Se os fluxos de trabalho fizerem refer\u00eancia a uma tag de vers\u00e3o em vez de um hash SHA espec\u00edfico, revise cuidadosamente os logs de execu\u00e7\u00e3o do fluxo de trabalho durante o ataque ativo contra a cadeia de suprimentos.<\/p>\n Tamb\u00e9m \u00e9 necess\u00e1rio verificar os logs de rede quanto ao tr\u00e1fego para os dom\u00ednios scan.aquasecurtiy[.]org<\/em>, checkmarx[.]zone<\/em> e models.litellm[.]cloud<\/em>. A presen\u00e7a desse tr\u00e1fego indica que os dados confidenciais foram exfiltrados com \u00eaxito.<\/p>\n Se um reposit\u00f3rio denominado docs-tpcp tiver aparecido no GitHub da organiza\u00e7\u00e3o, isso tamb\u00e9m poder\u00e1 indicar uma viola\u00e7\u00e3o bem-sucedida de dados.<\/p>\n Verifique os hosts e clusters quanto aos sinais de comprometimento, ou seja, a presen\u00e7a de arquivos ~\/.config\/sysmon\/sysmon.py, isto \u00e9, pods suspeitos no Kubernetes.<\/p>\n Limpe o cache e realize um invent\u00e1rio dos m\u00f3dulos PyPI: verifique se h\u00e1 m\u00f3dulos maliciosos e reverta para vers\u00f5es limpas.<\/p>\nComo o Trivy foi atacado<\/h2>\n
Comprometimento da ferramenta LiteLLM<\/h2>\n
Recursos do malware TeamPCP Cloud Stealer<\/h2>\n
\n
Estrat\u00e9gias de resposta e defesa ao CVE-2026-33634<\/h2>\n