LiteLLM Comprometido: O Primeiro Ataque Dirigido a Middleware de IA

O LiteLLM é um proxy universal de LLM. Ele roteia chamadas entre OpenAI, Anthropic, Cohere e dezenas de outros provedores. São 3,4 milhões de downloads diários no PyPI. É a camada de abstração que permite trocar de modelo sem reescrever código.

Na última semana, um pacote malicioso publicado no PyPI comprometeu essa cadeia. O ataque não mirou o modelo. Mirou o middleware, a infraestrutura invisível que conecta aplicações aos modelos. E funcionou.

O que aconteceu

O atacante publicou um pacote com nome similar ao LiteLLM no PyPI. Dentro dele, um arquivo .pth chamado litellm_init.pth. Arquivos .pth são executados automaticamente por qualquer processo Python no ambiente. Não precisam ser importados. Não pedem permissão. Existem e executam.

Em 72 minutos, o código malicioso gerou 11.000 processos. Cada processo fez a mesma coisa: varreu o sistema atrás de credenciais. Chaves SSH, tokens do Kubernetes, credenciais da AWS, autenticação do Google Cloud, senhas de banco de dados, carteiras de criptomoedas. Tudo exfiltrado para um servidor externo.

O pacote ficou disponível no PyPI por aproximadamente três horas durante o período de divulgação. Com 3,4 milhões de downloads diários, a janela de exposição não foi pequena.

A cadeia de infecção

O caminho de contaminação é o detalhe que importa. Não foi um desenvolvedor instalando um pacote suspeito por descuido. A cadeia documentada seguiu esta sequência: Trivy, o scanner de segurança, processou uma análise. O Checkmarx detectou a anomalia. E a investigação revelou que o vetor de entrada, em pelo menos um caso, passou por um servidor MCP rodando dentro do Cursor IDE.

Releia essa sequência. Um IDE com agente de IA chamou um servidor MCP. O servidor MCP dependia do LiteLLM. A dependência não tinha versão fixada. O pacote malicioso entrou por essa porta.

Como documentamos em Clinejection, a cadeia de suprimentos de IA não é linear. São camadas de ferramentas que dependem umas das outras, cada uma adicionando superfície de ataque. O Clinejection mostrou que um título de issue no GitHub pode se transformar em malware. O caso do LiteLLM mostra que a infraestrutura de middleware, aquela camada que “só roteia chamadas”, é tão vulnerável quanto o modelo em si.

Por que middleware de IA é o alvo perfeito

Pense na posição que o middleware ocupa na arquitetura. Ele fica entre a aplicação e o provedor de modelo. Toda requisição passa por ele. Toda chave de API está configurada nele. Todo token de autenticação é acessível a ele.

Um middleware comprometido não precisa quebrar o modelo. Não precisa enganar o usuário. Ele já está no caminho dos dados, por design. A posição privilegiada que torna o middleware útil é exatamente o que torna o comprometimento devastador.

Essa é uma variação do problema que analisamos em AI Governance IS Cybersecurity: a superfície de ataque não está onde a maioria das organizações está olhando. Equipes de segurança auditam modelos, monitoram prompts, controlam outputs. Enquanto isso, a camada de infraestrutura que conecta tudo opera com dependências sem versão fixada, sem verificação de integridade, sem monitoramento de comportamento anômalo.

O problema do `.pth`

O mecanismo do ataque merece atenção específica. Arquivos .pth no Python são projetados para estender o caminho de importação do interpretador. Mas podem conter código arbitrário que executa no início de qualquer processo Python.

O litellm_init.pth explorou isso. Não era uma biblioteca importada explicitamente. Era um arquivo que existia no ambiente e executava silenciosamente. O desenvolvedor não precisava chamá-lo. Bastava rodar qualquer script Python no mesmo ambiente.

Onze mil processos em 72 minutos. Cada um varrendo o sistema de arquivos local, variáveis de ambiente e configurações de credenciais. A coleta foi abrangente: SSH, AWS, GCloud, Kubernetes, bancos de dados, carteiras crypto. Se existia uma credencial no sistema, o malware a encontrava.

O que isso muda para governança de IA

Três lições concretas.

Dependências de middleware precisam do mesmo rigor que dependências de código. A maioria das organizações audita bibliotecas de código. Poucas auditam as dependências de infraestrutura de IA com a mesma disciplina. Se o seu proxy de LLM é um componente crítico (e se você roteia chamadas de modelo por ele, é crítico), ele precisa de versão fixada, hash verificado e monitoramento de integridade.

Servidores MCP são superfície de ataque. O caminho de infecção documentado passou por um servidor MCP no Cursor IDE. Servidores MCP que instalam dependências sem verificação transformam o IDE do desenvolvedor em vetor de entrada. Governança de ferramentas de desenvolvimento não é paranoia. É higiene.

Velocidade de resposta define o dano. O pacote ficou no PyPI por três horas. A resposta ao incidente usou Claude Code para acelerar a análise forense. Três horas com 3,4 milhões de downloads diários: a aritmética é simples e desconfortável. Resposta em velocidade humana contra ataque em velocidade de máquina é uma equação que não fecha.

A pergunta para sua organização

Quantas camadas de middleware existem entre sua aplicação e o modelo de IA que ela usa? Quais delas têm dependências fixadas? Quais são monitoradas? Quais foram auditadas nos últimos 90 dias?

Se a resposta a qualquer dessas perguntas for “não sei”, o vetor que comprometeu o LiteLLM está disponível. A técnica é pública. O playbook é documentado. O próximo alvo é quem não verificou a própria cadeia.

Fontes

Checkmarx. “Malicious PyPI Package Targets LiteLLM Proxy.” Março 2026.
LiteLLM. “Security Incident Response Report.” Março 2026.
Trivy Security Advisory. “Supply Chain Compromise via .pth Files.” Março 2026.

Victorino Group ajuda organizações a governar a cadeia de suprimentos de IA antes que ela se torne vetor de ataque: contato@victorino.com.br | www.victorino.com.br