Versão do LiteLLM no PyPI foi invadida e roubava chaves de IA

A versão 1.107.0 do LiteLLM, biblioteca muito usada para conectar aplicativos a vários modelos de inteligência artificial, foi publicada no PyPI, o repositório oficial de pacotes Python, com um programa que rouba credenciais e abre uma porta dos fundos no computador. A análise foi publicada pela empresa de segurança SafeDep, que afirma que o próprio LiteLLM confirmou o comprometimento em um relatório de incidente. O código-fonte no GitHub do projeto, segundo a análise, não continha o trecho malicioso: ele só estava nos arquivos distribuídos.

O que aconteceu e quais versões foram afetadas

De acordo com a SafeDep, a versão afetada é a litellm 1.107.0 no PyPI, além das imagens Docker com as tags v1.107.0, latest, main-latest e main-stable. As imagens carregaram o código malicioso entre 11h46 e 14h20 no horário UTC de 21 de outubro de 2026, ou seja, entre 8h46 e 11h20 em Brasília. A análise lista como limpas as versões 1.106.2, 1.107.0rc1 e 1.107.0rc2, e também os pacotes auxiliares litellm-proxy-extras e litellm-enterprise nas versões que a 1.107.0 usa.

Pela linha do tempo da SafeDep, os sete arquivos de instalação (para Linux, macOS e Windows) foram enviados ao PyPI por volta das 11h40 UTC, e o PyPI removeu a versão às 13h23 UTC. Ou seja, a versão ficou disponível por cerca de uma hora e quarenta minutos. Quem instalou ou atualizou o LiteLLM nesse intervalo, ou baixou as imagens Docker citadas, pode estar afetado.

Como o invasor chegou até a publicação

O relato atribuído ao LiteLLM, reproduzido pela SafeDep, diz que o invasor tinha as credenciais da linha de comando do GitHub de três desenvolvedores, que provavelmente foram obtidas dos registros de uma instalação interna do LiteLLM exposta à internet. Com o token de um dono da organização, o atacante teria driblado a proteção da branch principal e apontado o processo privado de publicação para um repositório de nome parecido. Uma segunda credencial passou pela etapa de aprovação, e o processo oficial construiu, assinou e publicou os arquivos adulterados.

Esse detalhe importa por um motivo simples: a assinatura e o canal oficial não garantiram que o conteúdo era seguro. O ataque usou as próprias engrenagens de publicação do projeto, e não um pacote falso com nome parecido, que é o golpe mais conhecido.

O que o código malicioso fazia

Segundo a SafeDep, a versão instalava três arquivos extras na pasta de pacotes do Python: cook.pth, cook.py e sitecustomize.py. Como o Python carrega esses arquivos sempre que um programa é iniciado, o código rodava mesmo em processos que nunca usaram o LiteLLM, como o próprio pip, editores de código e rotinas de integração contínua.

O primeiro componente é um ladrão de credenciais. A análise afirma que ele procura, entre outras coisas:

• senhas salvas em navegadores e histórico de navegação;
• chaves SSH, histórico de comandos e arquivos de chaves e certificados na pasta do usuário;
• credenciais de nuvem (AWS, Azure e Google Cloud), configurações de Kubernetes e Docker e tokens do GitHub;
• segredos de ferramentas de automação, como Jenkins, GitLab e Terraform;
• tokens e configurações de ferramentas de IA para programar, entre elas Claude Code, Cursor, Windsurf, Copilot, Gemini CLI, Codex e Aider;
• variáveis de ambiente e, no caso do servidor proxy do LiteLLM, as chaves de provedores de IA guardadas no banco de dados.

Os dados são criptografados e enviados a um endereço controlado pelo invasor. O segundo componente é uma porta dos fundos: segundo a SafeDep, um processo escondido acorda a cada hora, consulta um repositório do atacante no GitHub para descobrir um endereço, roda de novo o ladrão e baixa e executa um código adicional. A conta no GitHub usada para isso já tinha sido apagada às 13h40 UTC, então o processo, hoje, não encontra mais para onde se conectar. Mas a SafeDep ressalva que máquinas que rodaram o processo antes disso podem ter recebido e executado código extra, e que não foi possível recuperar o que esse código fazia.

O que fazer se você usa o LiteLLM

A análise da SafeDep não traz uma lista própria de providências e remete ao relatório de incidente do LiteLLM. Pelos indícios que ela descreve, o caminho lógico é este:

1. Verificar qual versão está instalada com pip show litellm e confirmar se alguma máquina, contêiner ou rotina de CI baixou a 1.107.0 ou as imagens Docker citadas.
2. Procurar os três arquivos citados na pasta de pacotes do Python e o arquivo-marcador mencionado pela SafeDep em /tmp.
3. Tratar como comprometida toda máquina em que o ladrão rodou: trocar chaves SSH, senhas, tokens do GitHub, credenciais de nuvem e chaves de API de provedores de IA.
4. Voltar para uma versão apontada como limpa (1.106.2, por exemplo) ou para uma versão posterior que o LiteLLM confirme como segura.

O Portal da AI não conseguiu abrir o relatório do próprio LiteLLM, e o que está aqui se apoia na análise da SafeDep. Se o seu projeto usa a biblioteca, vale conferir o aviso oficial do projeto antes de agir em produção.

Contexto: ferramentas de IA concentram segredos

O LiteLLM costuma ficar no meio do caminho entre aplicativos e modelos de vários fornecedores, e por isso concentra chaves valiosas. Esse perfil já tinha chamado atenção no Pwn2Own Irlanda, quando pesquisadores demonstraram falhas inéditas nele, como contamos na notícia sobre os 32 zero-days do evento. Alguns dias antes, o OpenCode também pediu que usuários trocassem chaves após uma invasão, assunto da notícia sobre o vazamento de chaves de API no OpenCode. O padrão se repete: quanto mais chaves de IA ficam juntas em uma ferramenta, mais atraente ela é para quem ataca.

Por que isso importa para você

Mesmo quem não programa pode ser tocado por esse tipo de incidente. Muitos aplicativos, automações e agentes que você contrata ou monta dependem de bibliotecas como essa, e uma chave de IA roubada vira conta de cobrança no seu cartão ou acesso a dados de clientes. Se você usa ou vende automações com IA, ou trabalha com vibe coding, algumas práticas reduzem o risco: fixar a versão das dependências em vez de aceitar sempre a mais nova, esperar algumas horas antes de atualizar uma biblioteca crítica, guardar chaves de API com limite de gasto e rotacioná-las com frequência, e não manter segredos em registros ou painéis expostos.

Para escolher ferramentas com mais critério, veja o checklist para escolher ferramenta de IA com segurança. Quem está começando a criar software com IA encontra os riscos principais em vibe coding para não programadores, e quem conecta agentes a ferramentas externas deve entender o MCP e como ele conecta agentes de IA, porque cada conexão é também uma porta de acesso.

O que ainda não se sabe

A SafeDep não conseguiu recuperar o endereço do servidor do invasor, então não se sabe quantas máquinas receberam o código adicional nem o que ele fez. Também não há, na análise, número de downloads da versão adulterada. Em incidentes desse tipo, o estrago costuma aparecer só depois, quando as credenciais roubadas começam a ser usadas. Por isso, a recomendação mais segura é trocar as credenciais agora, e não esperar sinais de uso indevido.