Se a sua empresa tem um aplicativo de IA, um chatbot ou uma ferramenta interna que se conecta a modelos como GPT, Claude ou Gemini, faça hoje uma única pergunta à sua equipe técnica: algum servidor, notebook ou pipeline de build instalou o LiteLLM na versão 1.107.0 em 21 de outubro de 2026? Essa versão foi publicada por atacantes e ficou no PyPI por cerca de duas horas, entre 14:39 e 16:23 no horário de Riad, com cerca de 49.000 downloads. Ela rouba chaves de nuvem, chaves de provedores de IA, senhas de bancos de dados e chaves SSH. Se a resposta for sim, desinstalar não basta: reconstrua a máquina a partir de uma imagem limpa e troque todas as chaves que ela podia acessar. A versão segura é a 1.106.2.

O que aconteceu exatamente?

O LiteLLM é uma biblioteca e um gateway de código aberto que permite que um único aplicativo converse com dezenas de modelos de IA por meio de uma só interface, e por isso muitas empresas o colocam no centro de seus produtos de IA. Segundo a Chainguard, ele passou de 100 milhões de downloads no PyPI no último mês, e mais de 2.000 outros pacotes dependem dele, então muitas equipes o instalam sem saber.

De acordo com o relatório oficial do incidente do LiteLLM, os atacantes obtiveram tokens de acesso do GitHub que tinham vazado nos logs do projeto. Às 10:08 UTC de 21 de outubro, usaram uma credencial privilegiada de desenvolvedor para contornar a proteção de branch e alterar o fluxo de publicação para compilar a partir de um repositório com nome parecido, «Berri-AI/litellm» em vez de «BerriAI/litellm». Às 11:39 UTC os arquivos maliciosos chegaram ao PyPI, e às 11:46 UTC saíram imagens Docker contaminadas com as tags v1.107.0, latest, main-latest e main-stable. O PyPI removeu a versão até 13:23 UTC, e as tags Docker foram limpas às 14:20 UTC, ou seja, 17:20 em Riad.

É o segundo ataque ao mesmo projeto neste ano. A Chainguard observa que em março de 2026 um grupo usou um token do PyPI roubado para publicar as versões 1.82.7 e 1.82.8.

O que a versão maliciosa rouba?

O perigo é que ela não espera seu aplicativo usar o LiteLLM. A versão adicionou arquivos de inicialização do Python que rodam toda vez que o Python inicia naquela máquina, mesmo em um comando sem relação. Segundo a análise da Wiz, o ladrão coletava:

  • Chaves de nuvem da AWS, Google Cloud e Azure, a partir de arquivos de configuração, variáveis de ambiente e metadados do servidor.
  • Chaves de API da OpenAI, Anthropic, Cohere e outros provedores de IA, ou seja, sua fatura e seus dados.
  • Chaves SSH privadas, histórico do terminal e senhas e cookies salvos nos navegadores.
  • Até 500 credenciais de provedores armazenadas no banco de dados do LiteLLM Proxy.

Os atacantes não ficaram parados com o que roubaram. A Wiz viu credenciais da AWS roubadas sendo testadas cerca de 4,5 horas depois do roubo, a partir de servidores de build e nós do Kubernetes. O malware também instalou uma segunda etapa que busca código remoto a cada hora, então a máquina continua aberta mesmo depois que o pacote é removido.

Minha empresa foi afetada?

Provavelmente não, se sua equipe fixa versões exatas e não atualizou nada entre 14:39 e 17:20 no horário de Riad em 21 de outubro. Ela pode ter sido afetada se algum destes casos se aplicar:

  • Um servidor ou contêiner executa «pip install litellm» sem versão fixa, ou puxa a tag Docker «latest».
  • Um pipeline de CI/CD foi recompilado naquela tarde.
  • Um desenvolvedor testou o LiteLLM no notebook naquele dia.
  • Seu sistema usa outro pacote que depende do LiteLLM.

O LiteLLM afirma que os clientes da sua versão Enterprise privada não foram afetados.

Cinco passos para hoje

  • Procurar: a versão 1.107.0 em arquivos de lock, logs de build e imagens de contêiner, e os arquivos cook.pth e sitecustomize.py na pasta de pacotes do Python.
  • Reconstruir: se encontrar, não se contente em desinstalar. O relatório oficial alerta que rodar o pip dentro de um ambiente infectado pode acionar o malware de novo. Reconstrua a máquina ou o contêiner a partir de uma imagem limpa.
  • Trocar todas as chaves: chaves e papéis de nuvem, chaves de provedores de IA, senhas de bancos de dados e chaves SSH que a máquina podia alcançar. Considere que já estão nas mãos dos atacantes.
  • Revisar os logs: verifique a atividade na nuvem desde 21 de outubro em busca de chamadas incomuns como GetCallerIdentity, e acompanhe a fatura do seu provedor de IA para ver gastos que você não reconhece.
  • Fixar versões: instale litellm==1.106.2 ou uma correção oficial posterior, e fixe cada biblioteca com um arquivo de lock em vez de puxar «latest» automaticamente.

Se você leu nosso artigo anterior sobre chaves esquecidas no código de agentes de IA, a lição é a mesma por outro ângulo: as chaves de IA estão hoje entre os segredos mais valiosos da sua empresa, e o lugar onde elas se concentram vira um alvo.

A visão da Origami

Ninguém hackeou o código do LiteLLM em si. Os atacantes mudaram a forma como ele é compilado e publicado, então revisar só o código-fonte não teria detectado nada. Por isso proteger produtos de IA depende menos da escolha da biblioteca e mais de como ela é operada: versões fixas, uma chave separada para cada ambiente com apenas as permissões necessárias, limites de gasto em cada provedor de IA e um registro claro de quem acessa o quê. Quando construímos sistemas de IA para empresas na Origami, tratamos o gateway de modelos como a parte mais sensível do sistema, porque ele guarda as chaves de tudo. Se você quer que seu aplicativo de IA seja verificado em relação a este incidente, ou reorganizar suas chaves e permissões, fale conosco.

Fontes