Um simples pip install foi suficiente para entregar chaves de API, senhas e acessos de nuvem a um invasor. A versão 1.107.0 do LiteLLM, publicada no PyPI em 21 de outubro de 2026, vinha com um ladrão de credenciais e uma porta dos fundos.
O LiteLLM é uma biblioteca Python muito usada para conversar com vários provedores de IA pela mesma interface. Por isso o LiteLLM comprometido atinge justamente quem trabalha com agentes e aplicações de IA.
Neste artigo você entende o que o código malicioso fazia, como ele entrou na versão oficial e o que fazer agora se você instalou o pacote. As informações vêm da análise da empresa de segurança SafeDep e do relatório de incidente do próprio LiteLLM.
O que aconteceu com o LiteLLM 1.107.0
Segundo a análise da SafeDep, os sete pacotes da versão 1.107.0 (para Linux, macOS e Windows) instalavam três arquivos extras na pasta de bibliotecas do Python.
O detalhe mais grave: dois deles rodavam sempre que qualquer processo Python iniciava na máquina, mesmo um que nunca importasse o LiteLLM. O código-fonte público no GitHub não continha esses arquivos.
O PyPI removeu a versão às 13h23 UTC (10h23 em Brasília) do mesmo dia. Imagens Docker do projeto no Docker Hub e no GHCR também carregaram o código malicioso entre 11h46 e 14h20 UTC.
| Versão ou artefato | Situação |
|---|---|
| LiteLLM 1.107.0 (PyPI) | Comprometida, removida |
| Imagens Docker publicadas entre 11h46 e 14h20 UTC de 21/10 | Comprometidas |
| LiteLLM 1.106.2 | Limpa |
| 1.107.0rc1 e 1.107.0rc2 | Limpas |
| Pacotes auxiliares fixados pela 1.107.0 | Limpos |
O que o ladrão de credenciais coletava
O primeiro módulo malicioso era um coletor de credenciais. Pela lista da SafeDep, ele buscava:
- Chaves SSH, credenciais de nuvem (AWS, Azure e outras) e segredos de CI/CD.
- Senhas salvas em navegadores baseados no Chromium e no Firefox, além do histórico.
- Tokens de ferramentas de IA para programação, como Claude Code, Cursor, Copilot, Gemini CLI e Codex.
- As chaves de API de provedores de IA guardadas no banco de dados de um proxy LiteLLM.
- Credenciais da instância na AWS, consultando o serviço de metadados da máquina.
Os dados eram criptografados (AES-256 com a chave protegida por RSA) e enviados ao servidor do atacante.
A porta dos fundos que rodava a cada hora
O segundo arquivo iniciava um processo escondido em segundo plano. A cada hora, ele lia o endereço de um servidor em um arquivo no GitHub do atacante, rodava o ladrão de credenciais de novo e baixava e executava código desse servidor.
Às 13h40 UTC, a conta do atacante no GitHub saiu do ar. Desde então a porta dos fundos não encontra servidor e não faz nada. Mas máquinas que rodaram o processo antes disso podem ter recebido e executado um segundo estágio de código.
Como o código malicioso entrou na versão oficial
De acordo com o relatório do LiteLLM citado pela SafeDep, o atacante tinha as credenciais do GitHub CLI de três desenvolvedores. A suspeita é que elas vazaram dos logs de uma instalação interna do LiteLLM exposta na internet.
Com o token de um dono da organização, o atacante driblou a proteção de branch e apontou o fluxo de publicação para um repositório falso parecido com o original. Depois, aprovou a etapa de revisão com a credencial de outro desenvolvedor.
Foi assim que o LiteLLM comprometido chegou ao PyPI com aparência de versão legítima. O resultado é o pior cenário de ataque à cadeia de suprimentos: o pipeline oficial montou, assinou e publicou os pacotes. Já falamos de outro caso parecido no artigo sobre o alerta de malware no Zod, no NPM.
O que fazer agora se você usa LiteLLM
Rode
pip show litellm em cada máquina, servidor e container. Verifique também se alguma imagem Docker do LiteLLM foi baixada entre 11h46 e 14h20 UTC de 21/10.Se a 1.107.0 rodou, desconecte a máquina de redes sensíveis antes de começar a limpeza.
Revogue e recrie chaves SSH, chaves de nuvem, tokens de CI/CD, tokens de ferramentas de IA e as chaves de provedores de IA guardadas no proxy. Troque também senhas salvas no navegador daquela máquina.
Fixe uma versão confirmada como limpa, como a 1.106.2, ou uma versão posterior indicada pelo próprio projeto.
O relatório de incidente do LiteLLM traz os passos de correção recomendados. Use-o como referência principal para a limpeza.
Perguntas frequentes
Instalei o LiteLLM, mas não usei. Estou em risco?
Sim, se a versão foi a 1.107.0. O código malicioso rodava ao iniciar qualquer processo Python na máquina, mesmo sem importar o LiteLLM.
Quais versões são seguras?
Segundo a SafeDep, a 1.106.2 e as versões de teste 1.107.0rc1 e rc2 estão limpas. Apenas a 1.107.0 final foi comprometida.
A porta dos fundos ainda funciona?
Desde que a conta do atacante no GitHub saiu do ar, ela não encontra servidor. Mas quem rodou antes disso pode ter recebido código adicional.
Por que um pacote oficial veio com malware?
Porque o atacante usou credenciais roubadas de desenvolvedores para controlar o próprio fluxo de publicação do projeto.
Conclusão
O caso do LiteLLM comprometido mostra que até um pacote oficial, assinado e publicado pelo pipeline do projeto, pode carregar malware. Se a versão 1.107.0 passou pelo seu ambiente, troque todas as credenciais sem esperar.
Quer reduzir o estrago caso uma chave de API vaze? Veja por que vale configurar um limite de gastos em APIs e agentes de IA.