LiteLLM: uma imagem assinada também pode carregar o ataque

A versão 1.107.0 do LiteLLM foi distribuída com mecanismos de roubo de credenciais e acesso remoto após o comprometimento da esteira em 21 de outubro de 2026.[2] O impacto descrito inclui PyPI e imagens Docker Hub e GHCR com as identificações v1.107.0, latest, main-latest e main-stable.[2]

O que muda para quem desenvolve

A própria esteira legítima assinou e publicou os artefatos adulterados depois que o atacante obteve credenciais e alterou controles de publicação.[2] Minha leitura: assinatura comprova uma relação com o processo de emissão, mas não substitui a proteção desse processo. Se a autoridade de publicação foi capturada, conferir a assinatura resolve apenas parte da pergunta.

O componente malicioso explorava inicialização do Python por arquivos .pth e sitecustomize.py, sem depender de uma chamada explícita da aplicação a uma função do LiteLLM.[2] Procurar apenas importações suspeitas no código de negócio seria uma investigação estreita demais.

A hipótese sobre a origem dos tokens envolve respostas do Claude Code registradas em logs de uma instalação interna do LiteLLM acessível pela internet; o modo exato de entrada permanecia incerto.[2] Isso é hipótese de investigação, não uma vulnerabilidade específica comprovadamente responsável.

Como aplicar

Primeiro, identifique o artefato realmente instalado e a data de obtenção. A reportagem delimita downloads pip sem versão fixa entre 11:39 e 13:23 UTC e uso das imagens indicadas entre 11:46 e 14:20 UTC no dia do incidente.[2] Use essas referências para orientar a triagem, sem assumir que uma tag atual descreve o que rodou anteriormente.

Se houver exposição, priorize isolamento, preservação de evidências, revogação dos segredos alcançáveis e reconstrução do ambiente, em vez de reinstalação por cima. Essa orientação acompanha o risco de persistência descrito na notícia.[2]

Para melhorar a esteira, proponho um exercício sem malware: em um projeto descartável, documente quais identidades conseguem alterar o workflow, aprovar uma release e assinar uma imagem. Verifique se uma única credencial concentra essas capacidades e se permissões temporárias realmente expiram.

Cuidados e limites

A Wiz relatou abuso de credenciais depois da exfiltração, inclusive em recursos cloud, e a remoção do repositório usado para descoberta do comando e controle não desfaz o roubo.[2] Bloquear o destino conhecido não encerra a resposta.

Fixar versões e digests ajuda a controlar mudanças, mas também exige uma rotina de revisão e atualização. Não há vantagem em congelar indefinidamente um artefato comprometido. O objetivo é publicar mudanças rastreáveis com autoridade limitada, não apenas acrescentar um selo ao mesmo processo frágil.

Fonte

[2] Fonte: The Hacker News