Um ataque à cadeia de suprimentos envolvendo o LiteLLM transformou uma janela de aproximadamente 40 minutos em um dos incidentes mais preocupantes recentes contra o ecossistema de pacotes Python. Nesse intervalo, versões maliciosas do projeto foram disponibilizadas no PyPI, colocando potencialmente milhares de ambientes corporativos em risco e permitindo a coleta de credenciais de nuvem, chaves SSH, tokens de Kubernetes, chaves de API e segredos de CI/CD.
O incidente, porém, não começou diretamente no LiteLLM. A investigação revelou uma conexão com o comprometimento do Trivy, conhecido scanner de vulnerabilidades mantido pela Aqua Security. A invasão de componentes relacionados ao projeto permitiu aos atacantes obter credenciais usadas em processos automatizados de desenvolvimento e publicação de software, criando uma ponte para atingir outros projetos da cadeia de fornecimento open source.
Neste artigo, vamos entender como o ataque aconteceu, por que as versões 1.82.7 e 1.82.8 do LiteLLM eram perigosas, qual foi o papel do arquivo litellm_init.pth, como o grupo TeamPCP, também associado ao identificador UNC6780, explorou a cadeia de confiança e quais medidas administradores Linux, equipes DevOps e profissionais de segurança devem adotar.
Como aconteceu o ataque à cadeia de suprimentos do LiteLLM
O LiteLLM é um projeto open source utilizado como camada de integração para diferentes modelos e provedores de inteligência artificial. A ferramenta pode funcionar como gateway entre aplicações e serviços de IA, centralizando chamadas para diferentes APIs.
Essa posição faz com que o projeto seja especialmente interessante para ambientes corporativos. Uma instalação do LiteLLM pode ter acesso a chaves de API, variáveis de ambiente, credenciais de nuvem, tokens internos e configurações de infraestrutura.
Em 24 de março de 2026, duas versões comprometidas foram publicadas no PyPI: 1.82.7 e 1.82.8.
A primeira versão continha alterações maliciosas incorporadas ao código do projeto. Já a segunda introduziu um mecanismo ainda mais perigoso por meio do arquivo litellm_init.pth, permitindo que o código fosse executado automaticamente durante a inicialização do interpretador Python.
O detalhe é fundamental.
Arquivos .pth são mecanismos legítimos do Python utilizados para modificar caminhos de importação e executar determinadas operações durante a inicialização do ambiente. O atacante aproveitou esse comportamento para transformar um recurso legítimo da plataforma em um mecanismo de execução de malware.
Isso significa que a simples instalação da versão comprometida poderia ser suficiente para iniciar a execução do código malicioso, sem que o desenvolvedor precisasse importar explicitamente uma função suspeita do LiteLLM.
O que o malware procurava nos computadores infectados
Depois de executado, o malware procurava informações sensíveis disponíveis no ambiente.
Entre os principais alvos estavam:
Chaves de API de serviços de inteligência artificial, incluindo credenciais associadas a provedores como OpenAI e Anthropic.
Credenciais de serviços de nuvem, potencialmente permitindo acesso a recursos hospedados em AWS, Google Cloud e Microsoft Azure.
Chaves privadas SSH, arquivos de configuração e outros elementos utilizados para autenticação remota.
Tokens e configurações de Kubernetes, que poderiam fornecer acesso adicional a clusters e workloads.
Variáveis de ambiente e arquivos de configuração, incluindo .env e outros locais tradicionalmente utilizados para armazenar segredos.
O risco, portanto, ultrapassava completamente o computador que instalou o pacote.
Uma chave de acesso à nuvem roubada de um runner de CI/CD, por exemplo, poderia ser utilizada posteriormente para acessar infraestrutura corporativa. Uma chave SSH poderia permitir movimentação lateral. Um token de publicação poderia abrir caminho para novos ataques à cadeia de software.
É justamente essa capacidade de transformar uma infecção localizada em um problema de infraestrutura que torna o episódio tão relevante.
O comprometimento do Trivy abriu caminho para o LiteLLM
A ligação entre os dois incidentes é provavelmente o aspecto mais importante de toda a campanha.
O Trivy é um scanner de segurança amplamente utilizado por desenvolvedores e equipes DevOps para identificar vulnerabilidades em imagens de contêineres, sistemas de arquivos, dependências e ambientes de infraestrutura.
Por ser executado dentro de pipelines de CI/CD, o Trivy normalmente opera em ambientes que possuem acesso privilegiado a diferentes recursos.
O problema surgiu quando componentes relacionados ao projeto foram comprometidos.
Os atacantes conseguiram executar código dentro de ambientes de CI/CD e, com isso, coletaram credenciais disponíveis nesses processos automatizados. Entre os dados obtidos estavam credenciais que posteriormente permitiram interferir no processo de publicação de pacotes.
O resultado foi uma cadeia de comprometimento:
Trivy comprometido → credenciais de CI/CD roubadas → acesso à publicação de pacotes → versões maliciosas do LiteLLM → roubo de credenciais das vítimas.
Esse modelo é especialmente perigoso porque cada etapa utiliza a confiança estabelecida pela anterior.
O usuário confia no scanner de segurança.
O pipeline confia no scanner.
O PyPI confia nas credenciais do mantenedor.
O desenvolvedor confia no pacote publicado.
E, finalmente, a empresa confia que todas essas etapas anteriores são legítimas.
O atacante explorou justamente essa sequência de confiança.
CVE-2026-33634 formaliza o comprometimento
O incidente envolvendo o Trivy foi registrado como CVE-2026-33634.
A vulnerabilidade está relacionada ao comprometimento da cadeia de desenvolvimento e distribuição do Trivy, incluindo versões específicas do projeto e componentes como trivy-action e setup-trivy.
O caso ganhou ainda mais importância depois de ser incluído no catálogo de vulnerabilidades exploradas conhecidas da CISA, sinalizando que organizações devem tratar o problema como uma ameaça real e não apenas como uma vulnerabilidade teórica.
A investigação também revelou impactos em organizações relevantes.
A Comissão Europeia, por exemplo, confirmou que sua infraestrutura foi afetada pelo comprometimento da cadeia de fornecimento relacionada ao Trivy. A investigação apontou para acesso indevido a recursos de nuvem e exfiltração significativa de dados.
A Mercor também confirmou que foi atingida pela campanha associada ao comprometimento do LiteLLM.
A Checkmarx apareceu igualmente entre as organizações relacionadas à campanha, demonstrando que os atacantes estavam explorando diferentes pontos do ecossistema de ferramentas utilizadas no desenvolvimento e na segurança de software.
O padrão é importante: o objetivo não era necessariamente invadir cada empresa individualmente. Bastava comprometer ferramentas utilizadas por centenas ou milhares delas.
Por que as dependências transitivas tornam o problema maior
Um dos maiores desafios para identificar esse tipo de ataque está nas chamadas dependências transitivas.
Uma organização pode não ter instalado conscientemente o LiteLLM.
Um projeto Python pode depender de uma biblioteca intermediária que, por sua vez, depende do LiteLLM. O gerenciador de pacotes resolve automaticamente essa árvore e instala os componentes necessários.
Para o administrador, isso significa que o pacote pode aparecer no ambiente sem jamais ter sido declarado diretamente no projeto principal.
Por isso, verificar apenas arquivos como requirements.txt não é suficiente.
É necessário analisar o grafo completo de dependências, os arquivos efetivamente instalados, os hashes dos pacotes e os artefatos utilizados nos processos de build.
Esse problema se torna ainda mais crítico em ambientes de inteligência artificial, onde projetos frequentemente dependem de dezenas ou centenas de bibliotecas Python.
O perigo das credenciais permanentes
O incidente também evidencia outra fragilidade recorrente nos ambientes de CI/CD: segredos com permissões excessivas e validade prolongada.
Quando uma ferramenta comprometida consegue acessar credenciais de publicação, tokens de nuvem ou chaves de outros serviços, o impacto pode se multiplicar rapidamente.
A abordagem mais segura é reduzir a quantidade de privilégios disponíveis para cada etapa do pipeline.
Em vez de utilizar uma chave permanente com acesso amplo, organizações devem priorizar:
- tokens temporários;
- identidade federada;
- permissões de menor privilégio;
- credenciais específicas por pipeline;
- isolamento entre ambientes;
- rotação automática de segredos.
O princípio é simples: se uma ferramenta for comprometida, ela não deveria conseguir levar todo o ambiente consigo.
Como verificar se sua infraestrutura foi afetada
Organizações que utilizam LiteLLM, Trivy ou componentes relacionados devem realizar uma investigação própria, mesmo que não tenham identificado sinais evidentes de invasão.
1. Verifique as versões e a janela de exposição
Comece procurando pelas versões LiteLLM 1.82.7 e 1.82.8.
Revise logs de instalação, caches de pacotes, imagens de contêiner, runners de CI/CD e ambientes virtuais Python.
A investigação deve considerar especialmente a janela em que os pacotes maliciosos permaneceram disponíveis no PyPI.
Também é importante procurar pelo arquivo litellm_init.pth em diretórios site-packages.
No caso do Trivy, verifique instalações da versão comprometida e revise o uso de trivy-action e setup-trivy durante o período afetado.
2. Considere comprometidos os segredos acessíveis
Se uma versão maliciosa foi executada, não é suficiente simplesmente removê-la.
As credenciais disponíveis naquele ambiente devem ser consideradas potencialmente comprometidas.
Isso inclui:
- credenciais AWS, Azure e Google Cloud;
- tokens do PyPI e GitHub;
- chaves SSH;
- tokens Kubernetes;
- chaves de APIs de IA;
- credenciais de bancos de dados;
- segredos armazenados em variáveis de ambiente.
A rotação deve ser feita de maneira coordenada, priorizando primeiro as credenciais com maior privilégio.
3. Procure sinais de movimentação lateral
A investigação não deve terminar depois da atualização do pacote.
Analise logs de autenticação, atividades no GitHub, eventos de Kubernetes, acessos a serviços de nuvem e alterações realizadas durante o período de exposição.
Também é importante procurar artefatos e repositórios suspeitos relacionados à campanha, incluindo referências a tpcp-docs.
No caso do Trivy, outra recomendação importante é deixar de depender exclusivamente de tags mutáveis em GitHub Actions. Sempre que possível, ações críticas devem ser fixadas em commits SHA imutáveis.
O que o ataque ensina sobre a segurança do ecossistema open source
O caso LiteLLM mostra que a segurança de uma organização não termina no seu próprio código.
Ela começa muito antes.
Uma aplicação pode estar corretamente desenvolvida, utilizar autenticação forte e possuir bons controles de acesso, mas ainda assim ser comprometida por uma dependência contaminada.
Esse é o verdadeiro desafio dos ataques à cadeia de suprimentos de software.
O atacante não precisa necessariamente encontrar uma vulnerabilidade no produto final. Ele pode atacar o desenvolvedor, o pipeline, o sistema de publicação ou uma ferramenta utilizada durante o processo de desenvolvimento.
O comprometimento do Trivy demonstra exatamente isso.
Uma ferramenta criada para aumentar a segurança acabou sendo utilizada como ponto de entrada para uma campanha maior.
O incidente também mostra por que práticas como SBOM, pinagem de dependências, verificação de hashes, assinatura de artefatos, isolamento de runners, privilégios mínimos e credenciais temporárias precisam fazer parte da rotina de segurança de ambientes modernos.
Para equipes que trabalham com Python, PyPI, Docker, Kubernetes, GitHub Actions e inteligência artificial, a pergunta também precisa mudar.
Não basta perguntar:
“Essa biblioteca é confiável?”
É necessário perguntar:
“O que essa biblioteca consegue acessar se for comprometida?”
Essa diferença de perspectiva pode determinar o tamanho do impacto de um futuro incidente.
O ataque ao LiteLLM é um lembrete de que uma janela de poucos minutos em um repositório público pode produzir consequências que permanecem por meses, especialmente quando credenciais roubadas continuam válidas e podem ser reutilizadas em outros ambientes.
Por isso, administradores Linux, desenvolvedores Python, engenheiros DevOps e profissionais de segurança devem tratar o caso como um alerta para revisar não apenas as dependências, mas toda a cadeia de confiança responsável por construir, publicar e distribuir software.
Se sua organização utiliza LiteLLM, Trivy ou pipelines Python, vale revisar os ambientes afetados e verificar se credenciais, tokens e artefatos foram devidamente auditados.