LiteLLM comprometido de novo: versão 1.107.0 roubava credenciais de nuvem e de ferramentas de IA

O LiteLLM, pacote Python que reúne mais de 100 provedores de LLM em uma única API compatível com a da OpenAI, foi alvo de um ataque à cadeia de suprimentos (supply chain) em 21 de outubro de 2026. A versão 1.107.0, publicada no PyPI e nas imagens Docker oficiais, trazia um ladrão de credenciais e um backdoor (The Hacker News). É a segunda vez no ano: em março, as versões 1.82.7 e 1.82.8 já tinham sido comprometidas (StepSecurity).

O que aconteceu

Segundo Oliver Jensen, diretor de segurança do LiteLLM, o atacante usou as contas GitHub de três engenheiros, aparentemente por meio de tokens OAuth do GitHub CLI roubados: uma conta disparou a publicação da versão e outra a aprovou (The Hacker News). A StepSecurity descobriu que a versão foi gerada a partir de um repositório falso de nome parecido, Berri-AI/litellm (com hífen), enquanto o código no repositório oficial continua limpo (StepSecurity).

O PyPI colocou o pacote em quarentena, as imagens Docker maliciosas foram removidas e os tokens usados no ataque foram revogados. A investigação sobre como o atacante obteve os tokens continua (The Hacker News).

Por que é tão grave

Roda sem você usar o LiteLLM: um arquivo cook.pth faz o malware executar em qualquer inicialização do Python no ambiente, mesmo sem importar o pacote (StepSecurity).
Leva quase tudo: credenciais de nuvem (AWS, Azure e GCP), chaves SSH e GPG, senhas de navegador, segredos de CI/CD, variáveis de ambiente de todos os processos e credenciais de mais de 20 ferramentas de IA, como Claude Code, Cursor e Copilot (StepSecurity).
Mira os gateways de IA: em proxies LiteLLM com banco de dados, extrai as chaves de API dos provedores (OpenAI, Anthropic, Azure e outros) guardadas no próprio proxy (StepSecurity).
Deixa uma porta aberta: um processo em segundo plano consulta um repositório no GitHub a cada hora e executa o código Python que o atacante enviar. O repositório foi apagado, mas as máquinas infectadas continuam consultando o mesmo endereço (StepSecurity).

Quem foi afetado

Quem instalou litellm==1.107.0 pelo pip. Muitos projetos usam versão aberta (litellm>=), então qualquer instalação ou atualização de lockfile naquele período pode ter puxado a versão maliciosa (StepSecurity).
Quem baixou as imagens Docker v1.107.0, ou as tags latest, main-latest e main-stable, entre cerca de 11h48 e 14h32 UTC de 21/10 (8h48 e 11h32 de Brasília) (StepSecurity).
As versões 1.106.x e anteriores estão limpas (StepSecurity).

Recomendações de segurança

Se a versão 1.107.0 rodou em algum lugar, trate a máquina ou o contêiner como totalmente comprometido (StepSecurity):

Encerrar o processo que mantém o arquivo /tmp/remote_code_loader.lock.
Apagar cook.pth, cook.py e sitecustomize.py do site-packages.
Reinstalar litellm==1.106.2 e, em contêineres, recriar a partir da imagem v1.106.2 fixada por digest.
Trocar, a partir de um ambiente limpo, todas as credenciais que a máquina alcançava, incluindo as chaves de provedores salvas no proxy e a master key do LiteLLM (The Hacker News).
Bloquear o domínio litellm.dev, para onde os dados roubados eram enviados.
Revisar lockfiles, requirements e Dockerfiles que usem versão ou tag flutuante do LiteLLM.

Referências

Conclusão: o caso do LiteLLM mostra que ferramentas de IA viraram alvo prioritário, porque concentram exatamente as chaves mais valiosas de uma empresa. Se a versão 1.107.0 passou pelo seu ambiente, não basta remover o pacote: troque as credenciais hoje. E fixe versões e imagens por digest, em vez de confiar em tags e versões flutuantes.