LiteLLM comprometido: o log do gateway de LLM também guarda segredo

O que aconteceu

Na manhã de 21 de outubro, a versão 1.107.0 do LiteLLM foi publicada no PyPI e nas imagens Docker com malware. O pacote ficou no ar de 11h39 a 13h23 UTC (8h39 a 10h23 em Brasília), e as tags v1.107.0, latest, main-latest e main-stable apontaram para a imagem comprometida até 14h20 UTC no Docker Hub. A última versão segura é a 1.106.2.

O malware deixava cook.pth e sitecustomize.py no site-packages, então rodava em qualquer start do Python, inclusive num pip install. Ele coletava credenciais de nuvem, chaves SSH, cookies de navegador e chaves de provedores de LLM, e ainda fazia um SELECT direto na tabela onde o proxy guarda as credenciais dos provedores. Segundo a Wiz, umas 4,5 horas depois o atacante já validava credenciais AWS roubadas de runners de CI e nós de Kubernetes, seguido de bedrock:ListFoundationModels, o padrão de LLMjacking.

A parte que me pegou

Depois de um incidente em março, o LiteLLM tinha endurecido o pipeline: release a partir de repo privado, tags Docker imutáveis, imagem assinada e publicação só a partir de uma conta presa a um notebook específico. Mesmo assim caiu, e a origem provável é desconfortável pra quem opera gateway de LLM.

Segundo o próprio time, existem situações em que o Claude Code coloca o token OAuth do GitHub CLI do usuário no corpo da resposta. Se o gateway loga o corpo, o token vai junto pro log. Eles acharam uma conta com nome inofensivo numa instância interna do LiteLLM exposta na internet, e a suspeita é que o atacante tirou dali os tokens de três desenvolvedores. Com eles, derrubou a proteção de branch, apontou o workflow de release para um repo quase igual (Berri-AI/litellm em vez de BerriAI/litellm) e passou no gate de aprovação com uma segunda conta.

A gente loga prompt e resposta no gateway por bons motivos: custo, debug, auditoria. Só que agente de código lê arquivo, roda comando e devolve a saída. Tudo que aparece no terminal dele pode acabar no log do gateway.

O que eu revisaria hoje

1. Mascarar segredo antes de gravar. Prefixos conhecidos (gho_, ghp_, sk-, AKIA) no corpo de request e response devem sair do log antes de persistir. E vale perguntar se você precisa mesmo guardar o corpo inteiro.
2. Tratar a instância do gateway como banco de produção. Ela tem as chaves de todos os provedores e, pelo visto, o que os seus agentes viram. Nada de painel exposto e conta que ninguém reconhece.
3. Fixar o artefato exato. Tag pode ser repontada, digest não. Em Python, pip install --require-hashes faz o mesmo papel.
4. Permissão temporária com data pra acabar. O ataque aproveitou uma permissão de release ampliada dois dias antes, para backports.

# versão e digest fixos, conferidos antes de subir
FROM ghcr.io/berriai/litellm:v1.106.2@sha256:<digest-que-voce-verificou>

Se a 1.107.0 rodou em algum lugar seu, siga o roteiro do LiteLLM: não comece com pip install (o próprio pip dispara o malware), apague os arquivos, mate o processo em background, recrie o ambiente do zero e rotacione tudo que o host alcançava, incluindo as chaves de provedor guardadas no banco do proxy.

Fontes

• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised, LiteLLM, 21 de outubro de 2026
• LiteLLM Compromised, Wiz Research, 21 de outubro de 2026
• LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Release, The Hacker News, 22 de outubro de 2026
• Issue #47826 no repositório do LiteLLM, GitHub