As ferramentas de análise de segurança de aplicações (AppSec), pensadas para reforçar o código e proteger a cadeia de fornecimento de software, podem transformar-se numa porta de entrada para ataques quando processam conteúdo não confiável sem isolamento. É esse o alerta central de uma nova investigação da empresa ZeroPath, que examinou como scanners de segurança embebidos nos pipelines de desenvolvimento podem ser manipulados para executar código malicioso — uma preocupação que ganhou peso depois da vaga de ataques do grupo TeamPCP, que em março de 2026 comprometeu ferramentas como o Trivy e o Checkmarx KICS.
Resposta rápida: Investigadores mostram que scanners de segurança que analisam repositórios podem ser levados a executar código controlado pelo atacante, servindo de trampolim para ataques em profundidade. O caso não é teórico: em março de 2026, o grupo TeamPCP comprometeu o Trivy e o Checkmarx KICS (CVE-2026-33634, CVSS 9.4). As organizações que usam scanners em pipelines devem isolar a análise de conteúdo não confiável, fixar versões por commit (SHA) e rotacionar credenciais expostas.
Quando o guarda passa a ser o cúmplice
A premissa da investigação parte de uma ideia contraintuitiva: a análise de um repositório nem sempre é uma operação apenas de leitura. Segundo a Dark Reading, que noticiou o trabalho, muitos scanners executam código e examinam ficheiros que podem ser usados para forçar a execução de código, dependendo da forma como processam esses ficheiros, o que remete para o problema clássico de AppSec de executar conteúdo não confiável. Se a ferramenta processa esse conteúdo sem o isolar devidamente, um atacante pode apresentar conteúdo inesperado que leva o scanner não só a ler um ficheiro, mas também a correr código malicioso.
O exemplo dado é ilustrativo. Se uma ferramenta analisa ficheiros de configuração de cloud e pode ser apontada para uma pasta de regras personalizadas, um atacante que controle o repositório em análise pode plantar uma “regra” que, na verdade, é um programa malicioso — e, quando o scanner a carrega, executa-o. É um vetor tanto mais perigoso quanto os scanners de segurança, por conceção, precisam de acesso amplo aos ambientes que analisam.
A equipa de investigação da ZeroPath chegou a este tema por via de um incidente real. Em dezembro de 2025, terá detetado um atacante a sondar a sua infraestrutura de análise com payloads desenhados para serem trocados entre vários fornecedores em escala, sem visar especificamente a empresa — estavam a industrializar o ataque. A partir daí, a equipa construiu uma ferramenta experimental para testar as mesmas superfícies de processamento que o atacante parecia querer explorar e, depois, ajustou-a para avaliar quão suscetíveis eram os scanners de outros fornecedores de segurança.
Os resultados serão apresentados na conferência Black Hat USA 2026, em Las Vegas, numa sessão intitulada, em tradução livre, “A analisar os analisadores: transformar fornecedores de segurança em armas de cadeia de fornecimento”. A apresentação aborda o que a equipa encontrou ao testar o resto da indústria da forma como o atacante o teria feito, a classe sistémica de vulnerabilidade por detrás dos resultados e o processo de divulgação responsável seguido.
O caso TeamPCP: da teoria ao ataque real
O que torna esta investigação urgente é que o cenário já se materializou. Em 19 de março de 2026, o Trivy — o scanner de vulnerabilidades open source mais adotado no ecossistema cloud-native da Aqua Security — foi comprometido num sofisticado ataque à cadeia de fornecimento focado em CI/CD; os atacantes aproveitaram acesso de um incidente anterior não totalmente remediado para injetar malware de roubo de credenciais nas versões oficiais, comprometendo simultaneamente o binário do scanner e as GitHub Actions trivy-action e setup-trivy.
Entre finais de fevereiro e março de 2026, o grupo TeamPCP conduziu uma sequência calculada e crescente de ataques à cadeia de fornecimento, comprometendo sistematicamente ferramentas de segurança open source de confiança, incluindo os scanners Trivy e KICS e o popular gateway de IA LiteLLM. O encadeamento operou como uma cascata: credenciais roubadas do pipeline de CI/CD de uma vítima tornavam-se o vetor de acesso ao alvo seguinte, demonstrando a posição de confiança extraordinária que as ferramentas de segurança ocupam nos pipelines modernos.
A gravidade destes alvos é bem explicada pelos investigadores. O Trivy está embebido em milhares de pipelines de CI/CD, corre como GitHub Action em cada pull request, cada merge e cada deploy, e opera com acesso a segredos do pipeline por conceção — comprometê-lo dá ao atacante não apenas código, mas credenciais de cloud, chaves SSH, tokens de Kubernetes e tudo o resto a que o pipeline toca.
Cronologia do ataque TeamPCP
| Data (2026) | Evento |
|---|---|
| 19 de março | Compromisso do Trivy (v0.69.4), trivy-action e setup-trivy; injeção de stealer de credenciais. |
| 21–23 de março | Uso de tokens/PATs roubados para atacar o Checkmarx KICS; force-push de commits maliciosos às tags das GitHub Actions. |
| 22 de março (20:31–20:32 UTC) | Imagens Docker Hub maliciosas publicadas como Trivy v0.69.5 e v0.69.6, sem releases correspondentes no GitHub. |
| 24 de março | Campanha atinge o LiteLLM, com versões maliciosas 1.82.7 e 1.82.8 publicadas no PyPI. |
| 26 de março | CVE-2026-33634 adicionada ao catálogo KEV da CISA (vulnerabilidades exploradas conhecidas). |
Sobre a janela do KICS, a Wiz reportou que a GitHub Action da Checkmarx foi comprometida depois de os atacantes fazerem force-push de várias tags para commits maliciosos, levando os fluxos de trabalho fixados nessas tags a executar um payload setup.sh malicioso. Os atacantes forçaram commits maliciosos a todas as 35 tags de versão do checkmarx/kics-github-action e envenenaram a versão 2.3.28 do checkmarx/ast-github-action, injetando um payload em três fases denominado “TeamPCP cloud stealer”.
O que o malware procurava
O objetivo era claro: recolher o máximo de segredos com acesso legítimo. Os três instrumentos comprometidos entregaram um payload desenhado para colher credenciais de fornecedores de cloud (AWS, GCP, Azure), tokens de Kubernetes, chaves SSH e segredos de ficheiros .env. Investigadores observaram ainda técnicas de propagação tipo verme (worm) que exploravam chaves SSH expostas e APIs inseguras de Docker e Kubernetes, além de mecanismos de persistência em fluxos de CI que criavam o risco de o código malicioso ser reintroduzido mesmo após a remediação inicial.
O impacto atingiu organizações de grande dimensão. De acordo com uma nota de investigação da Cloud Security Alliance, o uso da versão comprometida do Trivy pela Comissão Europeia terá levado à exfiltração de credenciais de gestão AWS, a uma violação de dados que afetou 42 clientes internos e pelo menos 29 entidades adicionais da UE, e ao roubo de cerca de 340 GB de dados não comprimidos.
Medidas de mitigação
Para organizações que operam scanners de segurança nos seus pipelines, os investigadores e fornecedores recomendam ação imediata e mudanças estruturais:
- Rotacionar credenciais. As organizações que executaram o Trivy, o KICS ou o LiteLLM durante as janelas de exposição devem tratar todo o repositório de credenciais como comprometido e rotacionar todos os segredos de imediato.
- Fixar versões por commit (SHA). Em vez de tags flutuantes, referenciar as GitHub Actions por hash de commit verificado, reduzindo o risco de substituição por versões maliciosas.
- Isolar o processamento de conteúdo não confiável. Executar scanners em ambientes com privilégios mínimos e sandboxing, evitando que a análise de um repositório possa aceder a segredos sensíveis.
- Rever configurações de CI/CD. Corrigir gatilhos como
pull_request_targetmal configurados, um vetor conhecido de execução de pipelines envenenados. - Monitorizar indicadores. Tratar qualquer referência à release v0.70.0 do Trivy nos logs como suspeita, já que o atacante tentou publicar essa versão maliciosa.
Porque é que isto importa em Portugal
Este caso ilustra uma tendência estrutural: os atacantes deixaram de visar apenas as aplicações finais e passaram a atacar as ferramentas em que as equipas depositam mais confiança. Para as PME e organizações portuguesas que dependem de pipelines de desenvolvimento com ferramentas open source, a lição é direta — um scanner de segurança é, ele próprio, um componente da cadeia de fornecimento que exige verificação de proveniência e vigilância.
No plano regulatório, o novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2) reforça as obrigações de gestão de risco da cadeia de fornecimento e de notificação de incidentes para as entidades abrangidas, um domínio em que o CNCS e o CERT.PT desempenham papel central na coordenação nacional. Sempre que dados pessoais sejam expostos num incidente como este, aplicam-se ainda os deveres de notificação previstos no RGPD, com prazos apertados perante a autoridade de controlo. Rever fornecedores, fixar dependências e reduzir a superfície de exposição das ferramentas de segurança deixou de ser uma boa prática opcional para passar a ser um requisito de resiliência.
Perguntas frequentes
O que é um scanner de AppSec e porque pode ser um alvo?
É uma ferramenta que analisa código, contentores ou configurações à procura de vulnerabilidades. Torna-se um alvo apetecível porque, por conceção, precisa de acesso amplo aos ambientes que analisa, incluindo variáveis de ambiente e segredos, pelo que um scanner comprometido se transforma numa plataforma de recolha de credenciais com acesso legítimo.
O que foi o ataque TeamPCP?
Foi uma campanha de cadeia de fornecimento em cascata, em março de 2026, que comprometeu sequencialmente o Trivy da Aqua Security, o Checkmarx KICS e o LiteLLM, usando credenciais roubadas de um alvo para atacar o seguinte. Está associada à CVE-2026-33634 (CVSS 9.4), incluída no catálogo KEV da CISA.
A minha organização usou o Trivy ou o KICS. O que devo fazer?
Se executou estas ferramentas durante as janelas de exposição de março de 2026, deve tratar as credenciais como comprometidas e rotacioná-las, verificar logs em busca de indicadores como a release falsa v0.70.0 e rever mecanismos de persistência em fluxos de CI que possam reintroduzir código malicioso.
Como reduzir o risco destas ferramentas no futuro?
Fixar as GitHub Actions por hash de commit em vez de tags flutuantes, isolar o processamento de conteúdo não confiável em ambientes de privilégios mínimos, restringir os segredos disponíveis no pipeline e corrigir configurações de risco como o pull_request_target.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela ZeroPath, Aqua Security, Checkmarx, Wiz, Microsoft, Unit 42 (Palo Alto Networks), Arctic Wolf, Kudelski Security, Cloud Security Alliance e Dark Reading.