A Cadeia de Suprimentos É a Superfície de Ataque

Em 19 de março de 2026, um grupo de ameaças chamado TeamPCP executou um force-push em 76 das 77 tags de versão do repositório trivy-action da Aqua Security no GitHub. O Trivy é o scanner de vulnerabilidades open-source mais amplamente implantado do setor. As novas tags apontavam para commits maliciosos contendo um ladrão de credenciais. Como a maioria dos pipelines de CI/CD referencia GitHub Actions por tags de versão mutáveis em vez de SHAs de commit fixados, toda organização que executava o Trivy em seu pipeline de build começou a executar o código comprometido imediatamente. Os scans ainda aparentavam ter sucesso. O scanner ainda reportava vulnerabilidades. Ele também coletava silenciosamente cada segredo no ambiente do runner.¹

Cinco dias depois, em 24 de março, o TeamPCP usou um token de publicação do PyPI roubado de um desses ambientes de CI para publicar duas versões com backdoor do LiteLLM, uma popular biblioteca de proxy de IA presente em 36% dos ambientes de nuvem.² A versão 1.82.8 incluía um arquivo .pth que executa automaticamente em qualquer inicialização do Python, antes de qualquer import, antes de qualquer sandbox em nível de aplicação. O payload varreu chaves SSH, credenciais de nuvem, senhas de banco de dados, carteiras de criptomoeda e segredos de CI/CD, criptografou-os com uma chave pública RSA embutida no código e exfiltrou o arquivo para um domínio controlado pelo atacante, registrado no dia anterior.³

O PyPI colocou ambas as versões em quarentena após 46 minutos. Nessa janela, 46.996 instalações ocorreram.⁴ O mantenedor do LiteLLM deletou sua conta no GitHub, rotacionou todas as chaves e contratou a Mandiant.⁵

O scanner de segurança escaneou. O pipeline de build fez o build. O gerenciador de pacotes instalou. Cada componente fez exatamente o que se confiava que ele fizesse.

TL;DR

• A cadeia: Trivy (scanner de segurança) comprometido em 19 de março via sequestro de tags do GitHub Actions. LiteLLM (proxy de IA) comprometido em 24 de março via token do PyPI roubado de um ambiente de CI infectado pelo Trivy. 46.996 downloads em 46 minutos.⁴
• A técnica: A versão 1.82.8 abusa do mecanismo .pth do Python para executar um ladrão de credenciais em qualquer invocação de python3 no sistema infectado, sem importar o LiteLLM.³
• O raio de impacto: 2.337 pacotes do PyPI dependem do LiteLLM. 88% tinham especificações de versão que permitiam as versões comprometidas. Impacto downstream confirmado em Google ADK, Stanford DSPy, MLflow, Guardrails AI e Cisco AI Defense SDK.⁴
• A campanha: O TeamPCP atingiu cinco ecossistemas em uma semana: GitHub Actions, Docker Hub, npm (CanisterWorm, 28+ pacotes), Open VSX (Checkmarx KICS) e PyPI (LiteLLM).⁶
• A lição estrutural: Cada elo na cadeia operou dentro de seu escopo autorizado. A composição de operações autorizadas produziu comportamento não autorizado. Esta é a mesma lacuna de composição que permite silent egress no nível do agente e Clinejection no nível de CI/CD. Ataques à cadeia de suprimentos são ataques de composição.
• O que você pode fazer: Fixe dependências em referências imutáveis. Isole credenciais de publicação dos runners de CI. Monitore requisições de rede de saída no nível do SO. Trate pip install como execução de código, porque é isso que ele é.

Um scanner de segurança entra no seu pipeline de build

O ataque começou com uma configuração incorreta no ambiente GitHub Actions do Trivy no final de fevereiro de 2026. Um atacante explorou um workflow pull_request_target vulnerável para exfiltrar o personal access token aqua-bot da Aqua Security. A Aqua rotacionou algumas credenciais em 1º de março, mas a rotação foi incompleta. O TeamPCP manteve tokens válidos.¹

Em 19 de março, eles usaram esses tokens para fazer force-push em 76 das 77 tags de versão no repositório trivy-action e em todas as 7 tags do setup-trivy, redirecionando toda referência de tag mutável para commits maliciosos. Eles também acionaram a automação de release para publicar um binário malicioso do Trivy como v0.69.4.¹

O payload era um ladrão de credenciais que despejava a memória do processo Runner.Worker, coletava chaves SSH, credenciais de nuvem, segredos do Kubernetes, configs do Docker, credenciais do Git e arquivos .env. Os dados foram criptografados com AES-256 e uma chave RSA de 4096 bits, e então exfiltrados para servidores controlados pelo atacante. O código malicioso executava ao lado da funcionalidade legítima do Trivy. Os scans tinham sucesso. As vulnerabilidades eram reportadas. O ladrão executava em segundo plano.⁷

Entre 19 e 23 de março, imagens do Docker Hub com as tags trivy:0.69.4, trivy:0.69.5, trivy:0.69.6 e trivy:latest foram comprometidas. CrowdStrike, Microsoft, Wiz e Palo Alto publicaram análises técnicas em questão de dias.⁷⁸⁹

A ironia é estrutural: as organizações mais conscientes em relação à segurança eram as mais expostas. Se você executava o Trivy no CI porque se importa com escaneamento de vulnerabilidades, o seu pipeline de build era aquele que coletava credenciais.

Do scanner ao ladrão ao proxy de IA

O pipeline de CI do LiteLLM executava o Trivy. Especificamente, ci_cd/security_scans.sh instalava o Trivy via apt do repositório da Aqua sem fixar a versão.¹⁰ Durante a janela de comprometimento, uma execução de CI instalou o binário Trivy envenenado, que coletou a PYPI_PUBLISH_PASSWORD do ambiente GitHub Actions.

Em 23 de março, o atacante registrou litellm.cloud. Em 24 de março às 10:39 UTC, eles publicaram litellm==1.82.7 no PyPI usando as credenciais roubadas. A versão 1.82.8 seguiu às 10:52 UTC.⁴

As duas versões usaram técnicas de ataque diferentes. A versão 1.82.7 embutiu o payload em proxy_server.py, que é acionado em import litellm.proxy. A versão 1.82.8 adicionou um arquivo .pth ao site-packages/, que é acionado em qualquer inicialização do interpretador Python. O mecanismo .pth é um recurso legítimo do Python para configuração de caminhos. Qualquer arquivo terminando em .pth colocado em site-packages/ é executado automaticamente pelo site.py do Python durante a inicialização do interpretador. A maioria dos desenvolvedores Python não sabe que esse recurso existe.³

O payload em ambas as versões coletou variáveis de ambiente, chaves SSH, credenciais AWS/GCP/Azure, configs do Kubernetes, senhas de banco de dados, carteiras de criptomoeda e segredos de CI/CD. Ele criptografou a coleção com AES-256-CBC usando uma chave de sessão aleatória, envolveu a chave de sessão com uma chave pública RSA de 4096 bits embutida no código e exfiltrou o arquivo via HTTPS POST. Apenas o atacante pode descriptografar os dados roubados.³

Um bug no malware da 1.82.8 o tornou visível. O arquivo .pth gera um processo Python filho, que re-aciona o arquivo .pth, criando uma fork bomb exponencial. Andrej Karpathy notou o bug no X. Sem a fork bomb, o ladrão teria executado silenciosamente em cada invocação do Python em cada sistema infectado, potencialmente por semanas antes da detecção.⁴

O PyPI colocou ambas as versões em quarentena às 11:25 UTC. Exposição total: 46 minutos. Downloads totais: 46.996.⁴

O raio de impacto

O LiteLLM é baixado aproximadamente 3,4 milhões de vezes por dia. A Wiz reporta que ele está presente em 36% dos ambientes de nuvem.² A janela de exposição de 46 minutos foi suficiente.

A FutureSearch analisou os logs de download do BigQuery do PyPI e descobriu que, durante a janela de ataque, a versão 1.82.8 foi baixada 6x mais do que qualquer versão segura. Os downloads se inclinaram fortemente para pip (que resolve para a versão mais recente) em vez de uv (que usa lock files). Dos 46.996 downloads, 23.142 foram instalações pip da v1.82.8, cada uma das quais executou o payload durante a própria instalação, porque o arquivo .pth dispara durante o próprio processo Python do pip.⁴

2.337 pacotes no PyPI dependem do LiteLLM. 88% (2.054 pacotes) tinham especificações de versão que permitiam a instalação das versões comprometidas. A exposição downstream inclui:⁴

Os usuários do LiteLLM Cloud e do proxy Docker não foram afetados porque suas dependências estavam fixadas em requirements.txt. A distinção entre “fixado” e “não fixado” foi a diferença entre comprometido e seguro.⁵

Cinco ecossistemas em uma semana

O TeamPCP não parou no PyPI. A campanha atingiu cinco ecossistemas de pacotes em rápida sucessão:⁶

GitHub Actions (19 de março): 76 tags do trivy-action e todas as 7 tags do setup-trivy sequestradas. Binários maliciosos do Trivy v0.69.4 a v0.69.6 publicados.

Docker Hub (19-22 de março): Imagens comprometidas do Trivy publicadas como aquasec/trivy:latest e tags específicas de versão. Propagadas para mirror.gcr.io.

Open VSX (23 de março): GitHub Action do Checkmarx KICS comprometida. 35 tags sequestradas entre 12:58 e 16:50 UTC.²

npm (23-24 de março): CanisterWorm, um worm autopropagável, implantado em mais de 28 pacotes npm.

PyPI (24 de março): LiteLLM versões 1.82.7 e 1.82.8 publicadas com payloads de roubo de credenciais.

Cada comprometimento de ecossistema usou credenciais coletadas do anterior. A campanha foi um grafo direcionado de exploração de confiança, em que cada nó comprometido fornecia as chaves para o próximo.

Ataques à cadeia de suprimentos são ataques de composição

O padrão estrutural na campanha do TeamPCP é o mesmo padrão que descrevi no contexto de segurança de agentes e silent egress: componentes individualmente autorizados se compondo em comportamento não autorizado.

O Trivy estava autorizado a executar no CI. O CI estava autorizado a manter credenciais de publicação. O gerenciador de pacotes estava autorizado a instalar pacotes. Cada arquivo .pth estava autorizado a configurar caminhos do Python. Cada elo na cadeia operou dentro de seu escopo definido. A composição dessas operações autorizadas produziu exfiltração de credenciais em escala.

O ataque Clinejection demonstrou o mesmo padrão no nível de CI/CD: um título de issue injetou texto adversário no pipeline automatizado do Cline, que executou um script de npm preinstall, que envenenou o cache de build, que contaminou artefatos entre workflows. Cada etapa estava individualmente autorizada.¹¹

O benchmark MCPTox demonstrou isso no nível do agente: instruções maliciosas embutidas em descrições de ferramentas redirecionam agentes para exfiltrar credenciais usando ferramentas legítimas já presentes no servidor. O agente nunca executa a ferramenta envenenada em si. Ele lê a descrição envenenada e usa suas próprias ferramentas autorizadas para realizar o ataque.¹²

O silent egress demonstra isso no nível de runtime: instruções adversárias em metadados de páginas web induzem um agente a exfiltrar contexto de runtime por meio de uma requisição HTTP de saída que o agente está autorizado a fazer.¹³

A superfície de ataque não é um único componente vulnerável. A superfície de ataque é a composição de componentes confiáveis. Proteger elos individuais não protege a cadeia. O Trivy não era a vulnerabilidade. O LiteLLM não era a vulnerabilidade. A vulnerabilidade era a relação de confiança entre eles, mediada por tags de versão mutáveis e dependências não fixadas.

O que realmente ajuda

As defesas que teriam prevenido cada estágio desse ataque são chatas. Também são aquelas que a maioria das organizações pula.

Fixe em referências imutáveis. O LiteLLM instalou o Trivy via apt sem fixar a versão. Se security_scans.sh tivesse sido fixado em uma versão específica ou em um SHA de commit, o binário envenenado v0.69.4 nunca teria sido executado. GitHub Actions deveriam referenciar SHAs de commit, não tags mutáveis. A diferença entre uses: aquasecurity/[email protected] (comprometido) e uses: aquasecurity/trivy-action@57a97c7 (seguro) é a diferença entre perder suas credenciais de publicação e não perder.¹

Isole credenciais de publicação dos runners de CI. A PYPI_PUBLISH_PASSWORD estava acessível como variável de ambiente no runner do GitHub Actions onde o Trivy executava. Se as credenciais de publicação estivessem isoladas em um workflow separado sem dependências de actions de terceiros, o comprometimento do Trivy não teria resultado em acesso ao PyPI. Os Trusted Publishers do PyPI (OIDC) eliminam tokens armazenados por completo.⁵

Monitore requisições de rede de saída. O ladrão de credenciais exfiltrou dados via HTTPS POST para models.litellm.cloud, um domínio registrado 24 horas antes do ataque. Monitoramento de egresso que sinaliza requisições para domínios recém-registrados teria capturado isso. Meu próprio sistema de hooks bloqueia requisições de saída para domínios que não estão em uma allowlist, o mesmo padrão que teria interceptado essa exfiltração.¹⁴

Aprendi a mesma lição em produção do jeito difícil. Um caminho confiável de purge de cache do Cloudflare disparou uma chamada API autorizada e ainda assim produziu o resultado errado porque as guardrails ao redor estavam frouxas demais. Essa falha me empurrou para adicionar aprovações de ações destrutivas e hooks de preflight em torno de operações de alto impacto, não apenas allowlists de domínio.

Trate pip install como execução de código. Um arquivo .pth em site-packages/ executa em cada inicialização do Python. Não há opt-out. Não há sandbox. Se você executa pip install em um ambiente de CI com acesso a credenciais, você está concedendo execução arbitrária de código a toda dependência transitiva no pacote. A mitigação é executar pip install em um ambiente sem acesso a credenciais e depois copiar os pacotes instalados para o ambiente que precisa deles.

Use lock files. A análise da FutureSearch descobriu que downloads via uv (que usa lock files) tinham muito menos probabilidade de instalar a versão comprometida do que downloads via pip (que resolve para a versão mais recente). Lock files não são uma defesa completa, mas previnem a exposição mais comum: uma restrição de versão >= não fixada sendo silenciosamente atualizada para um release comprometido.⁴

A implicação desconfortável

A campanha do TeamPCP demonstra que segurança de cadeia de suprimentos não é uma preocupação secundária que fica atrás de segurança de aplicação, segurança de rede e proteção de endpoint. Para organizações que executam agentes de IA com acesso a ferramentas, a cadeia de suprimentos é a superfície de ataque primária.

Um agente de IA que chama pip install em um ambiente de CI, busca URLs ou instala servidores MCP está compondo relações de confiança em runtime. Cada operação é autorizada. A composição pode não ser. O paradoxo deploy-and-defend acelera isso: organizações implantam agentes mais rápido do que auditam as cadeias de confiança que esses agentes compõem.

O bug da fork bomb no LiteLLM 1.82.8 foi a única razão pela qual esse ataque foi detectado rapidamente. Sem esse erro de implementação, o ladrão de credenciais teria executado silenciosamente em cada invocação do Python em cada sistema infectado. 46.996 instalações em 46 minutos. 36% dos ambientes de nuvem. 2.337 pacotes downstream. O atacante cometeu um erro. Na próxima vez, talvez não cometa.

Atualização — 31 de março de 2026: um vetor diferente, o mesmo resultado

Seis dias após a publicação deste post, o npm teve seu próximo incidente. Em 31 de março, o mantenedor do axios, Jason Saayman, divulgou que seu computador pessoal havia sido comprometido por meio de uma campanha de engenharia social direcionada seguida por malware do tipo trojan de acesso remoto. Os atacantes usaram suas credenciais do npm para publicar axios 1.14.1 e 0.30.4, ambas injetando uma nova dependência chamada [email protected] que instalava um RAT multiplataforma em macOS, Windows e Linux. As versões maliciosas ficaram no ar por aproximadamente três horas antes que contribuidores da comunidade fizessem a triagem do incidente e o npm as removesse.¹⁶

O vetor do axios foi diferente do TeamPCP. Não houve runner de CI comprometido, nenhuma credencial coletada de um scanner de segurança de terceiros, nenhum worm multi-ecossistema. A campanha contra Saayman durou aproximadamente duas semanas antes da publicação, e o comprometimento viajou pelo dispositivo pessoal do mantenedor diretamente para o pipeline de publicação do npm. A remediação exigiu uma limpeza completa de todos os seus dispositivos e a rotação de toda credencial em cada plataforma que ele já havia usado, pessoal ou não. A infraestrutura de C2 era sfrclak[.]com em 142.11.206.73:8000.¹⁶

A lição estrutural é a mesma. A cadeia de confiança agora inclui a atenção e a vigilância do mantenedor como elos — operações individualmente autorizadas se compondo em comportamento não autorizado quando um humano na cadeia é manipulado. As mitigações que a equipe do axios está adotando (publicação OIDC, releases imutáveis, isolamento de dispositivos)¹⁶ abordam a mesma lacuna de composição que a exposição Trivy-para-LiteLLM revelou: credenciais de publicação armazenadas onde podem ser alcançadas por adversários que já comprometeram algo adjacente a elas.

Três horas. 46 minutos. Essas são as janelas em que os ataques modernos de cadeia de suprimentos operam agora. Pinning e lockfiles continuam sendo a defesa primária — usuários do axios que tinham instalações recentes fora da janela de 00:21-03:15 UTC de 31 de março não foram afetados.¹⁶

FAQ

Como verifico se fui afetado?

Pesquise nos logs do seu CI e nos ambientes locais por versões do LiteLLM 1.82.7 ou 1.82.8 instaladas entre 10:39 e 11:25 UTC em 24 de março de 2026. Se qualquer das versões foi instalada, rotacione todas as credenciais que estavam acessíveis como variáveis de ambiente, chaves SSH ou arquivos de configuração naquele sistema. A orientação oficial do LiteLLM recomenda tratar qualquer sistema que executou as versões comprometidas como totalmente comprometido.⁵

Qual identificador de aviso devo rastrear?

Rastreie PYSEC-2026-2 no OSV e no banco de dados de avisos do PyPA. O OSV também registra o incidente com o alias MAL-2026-2144. Em 25 de março de 2026, a página pública de aviso do OSV não lista um alias CVE para os releases maliciosos do LiteLLM, então equipes de resposta a incidentes devem se basear primeiro nas versões afetadas, na janela de instalação e em PYSEC-2026-2.¹⁵

Os usuários do LiteLLM Cloud ou do proxy Docker foram afetados?

Não. O LiteLLM Cloud e a imagem oficial do proxy Docker fixam dependências em requirements.txt, prevenindo resolução automática para as versões comprometidas. Apenas usuários que instalaram o LiteLLM via pip install litellm (não fixado) durante a janela de 46 minutos foram afetados.⁵

O que é um arquivo .pth e por que ele é perigoso?

Um arquivo .pth é um recurso do Python para configurar caminhos de busca de módulos. Qualquer arquivo terminando em .pth colocado no diretório site-packages/ é lido e executado pelo módulo site.py do Python durante a inicialização do interpretador. Isso acontece antes de qualquer declaração de import, antes de qualquer código de aplicação e antes de qualquer sandbox em nível de Python. O mecanismo é documentado na biblioteca padrão do Python, mas não é amplamente conhecido entre desenvolvedores de aplicações. É um recurso legítimo sendo usado como vetor de ataque.³

Isso está relacionado ao ataque à cadeia de suprimentos do Trivy?

Sim. O comprometimento do LiteLLM foi uma consequência direta do comprometimento do Trivy. O TeamPCP comprometeu o GitHub Actions do Trivy em 19 de março, o que coletou credenciais de CI/CD de organizações que executavam o Trivy em seus pipelines de build. Uma dessas credenciais foi o token de publicação do PyPI do LiteLLM. O atacante usou esse token para publicar as versões maliciosas do LiteLLM cinco dias depois.¹⁰

O que é o TeamPCP?

TeamPCP (também rastreado como DeadCatx3, PCPcat, ShellForce, CipherForce) é um grupo de ameaças que conduziu uma campanha multi-ecossistema à cadeia de suprimentos em março de 2026, comprometendo pacotes em GitHub Actions, Docker Hub, npm, Open VSX e PyPI. O grupo usou técnicas de coleta de credenciais, sequestro de tags e worm autopropagável em cinco ecossistemas de pacotes em aproximadamente uma semana.⁶

Como isso se relaciona à segurança de agentes de IA?

Agentes de IA que instalam pacotes, buscam URLs ou se conectam a servidores MCP compõem relações de confiança em runtime. Cada operação é individualmente autorizada. A composição dessas operações pode produzir comportamento não autorizado, como demonstrado por silent egress (nível do agente), Clinejection (nível de CI/CD) e este ataque (nível de cadeia de suprimentos). Monitoramento comportamental em runtime, allowlisting de domínios e isolamento de credenciais abordam a lacuna de composição em diferentes camadas da stack.¹⁴

Fontes