LiteLLM 1.107.0 foi publicado com ladrão de credenciais: quem foi afetado e o que fazer agora

Fala aí, beleza? O incidente de 21/10/2026 com o LiteLLM atingiu artefatos usados para rotear chamadas entre provedores de LLM. Este texto considera também a investigação posterior publicada pelo projeto em 23/10.

Em 21/10/2026, uma release do LiteLLM foi publicada no PyPI com malware compilado que rouba credenciais e carrega ferramentas de execução remota de código, segundo o comunicado do incidente. Esse comunicado preserva hipóteses iniciais e aponta a investigação posterior de 23/10 como registro canônico da cadeia do ataque

O pacote ficou no ar das 11:39 às 13:23 UTC e depois foi retirado. O risco recai sobre projetos Python e proxies de LLM que instalaram ou atualizaram nessa janela, principalmente sem dependência fixada, e sobre quem puxou as imagens Docker oficiais da mesma versão

O que aconteceu com o LiteLLM 1.107.0

Uma versão maliciosa foi publicada pelo próprio pipeline de release do projeto, ficou disponível por pouco tempo e contaminou tanto o PyPI quanto as imagens Docker

A linha do tempo confirmada fica assim:

• 21/10/2026, 11:39 UTC: a litellm==1.107.0 aparece no PyPI
• 21/10/2026, 13:23 UTC: o pacote sai do PyPI (cerca de 2 horas no ar)
• 21/10/2026, 11:46 às 14:20 UTC: as tags do Docker Hub ficam comprometidas, segundo o comunicado do LiteLLM
• 21/10/2026, 11:46 às 13:51 UTC: as mesmas tags no GHCR ficam comprometidas, até se tornarem indisponíveis, também segundo o LiteLLM

No PyPI, só a 1.107.0 foi afetada: o malware estava presente nos sete wheels publicados dessa versão, segundo o LiteLLM e a StepSecurity. O sdist teve o arquivo de build adulterado (com a linha data = "cook"), mas sem o payload malicioso

A StepSecurity inspecionou os wheels das versões 1.107.0rc1, rc2, 1.106.x, 1.105.x, 1.104.x e 1.103.x e os considerou limpos; as pré-releases 1.107.0.dev1 a dev3 não foram inspecionadas por ela. O LiteLLM, de forma mais geral, afirma que todas as versões anteriores à 1.107.0 são seguras e orienta fixar a 1.106.2 ou qualquer versão explícita publicada antes do incidente

No Docker a coisa foi mais ampla, e aqui que mora o perigo pra muita gente

No GHCR e no Docker Hub, as tags v1.107.0, latest, main-latest e main-stable apontavam para a imagem maliciosa, e as variantes litellm-database e litellm-non_root no GHCR também foram afetadas

A imagem v1.107.0 foi removida e as demais tags foram reapontadas para artefatos limpos verificados, segundo o LiteLLM. A Wiz e a Datadog chamam a 1.106.2 de versão segura mais recente

Como o invasor conseguiu publicar a versão?

A investigação de 23/10 apresenta uma explicação diferente das hipóteses iniciais: uma chave administrativa de uma implantação interna da LiteLLM Agent Platform foi exposta em um repositório público em maio e permaneceu válida após a remoção do arquivo.

Segundo o projeto, o invasor usou essa chave em outubro para acessar a implantação e extrair um token OAuth do GitHub CLI associado a um proprietário da organização. Depois obteve tokens de outros dois engenheiros.

O acesso de proprietário permitiu sobrepor a proteção de branch e alterar o workflow para compilar a partir de um repositório controlado pelo invasor. Tokens de identidades distintas foram usados para disparar e aprovar a release. Essa investigação é a referência para a cadeia de acesso; a hipótese anterior sobre uma vulnerabilidade não deve ser apresentada como conclusão.

E não é a primeira vez: é o segundo comprometimento da cadeia de suprimentos do LiteLLM em 2026, segundo a Datadog Security Labs. O primeiro, em março, afetou as versões 1.82.7 e 1.82.8, e até a publicação deste texto não havia ligação estabelecida entre os dois casos

Quanto ao alcance, a Wiz estima, com dados do ClickPy, cerca de 49 mil downloads da versão maliciosa

O que o malware fazia e o que ele roubava

Ele se instalava de um jeito que roda sozinho, sem você precisar importar o LiteLLM, e tinha como alvo praticamente todo segredo que estivesse na máquina

O pacote deixava três arquivos na raiz do site-packages: cook.pth, cook.py e sitecustomize.py, segundo a Wiz

Que hook .pth? É um arquivo que o Python lê na inicialização, e no caso dele isso significa que o ladrão de credenciais roda toda vez que o Python inicia, mesmo que o litellm nunca seja importado. Apagar só a pasta do pacote litellm não remove esses arquivos, e rodar o python ou o pip do ambiente dispara o malware de novo

Já o sitecustomize.py iniciava um daemon em segundo plano que consultava de hora em hora um dead drop no GitHub e executava o código Python que o invasor servisse, de acordo com a StepSecurity e com a Wiz. Segundo a Wiz, esse carregador só rodava em Linux e macOS, o arquivo de controle só teve valores de teste e nenhum segundo estágio foi observado em ataques reais, conforme a Datadog também confirma. O GitHub já derrubou o repositório usado como dead drop, por volta das 13:30 UTC

Ou seja: além de roubar o que encontrava, deixava uma porta aberta pra rodar o que o invasor quisesse depois

O que ele coletava, segundo a Datadog:

• senhas e cookies de navegador
• chaves SSH e GPG, além de certificados TLS
• credenciais de nuvem (AWS, GCP, Azure)
• segredos de Kubernetes, Docker, Vault e Terraform
• tokens Git, npm e PyPI, além de arquivos .env
• configurações de mais de 20 ferramentas de IA pra programação, segundo a StepSecurity
• chaves de provedores de LLM e sessões de ferramentas de IA
• credenciais guardadas no banco de dados do proxy LiteLLM

Por que pesa mais pra quem usa o LiteLLM como proxy?

Porque o proxy guarda as chaves de API upstream num banco PostgreSQL (na tabela LiteLLM_CredentialsTable), e o ladrão consultava esse banco direto pra extrair as credenciais de provedores configuradas, segundo a Wiz

Então um único host comprometido pode entregar de uma vez as chaves de todos os provedores que você roteia por ali, e não só uma

Quem foi afetado pelo LiteLLM comprometido

Em resumo: quem recebeu a 1.107.0 de alguma forma nesse 21/10, seja por instalação direta, build automático ou imagem Docker

Se liga nos cenários de risco:

• quem instalou ou atualizou o litellm via pip, sem fixação de versão, entre 11:39 e 13:23 UTC de 21/10/2026
• ambientes sem versão fixada ou com faixa aberta de versão, que podem ter puxado a release nova sozinhos
• pipelines de CI que reconstruíram imagens ou ambientes nesse período
• quem puxou imagens Docker pelas tags latest, main-latest, main-stable ou v1.107.0 antes da correção, no Docker Hub até as 14:20 UTC e no GHCR até as 13:51 UTC

O comunicado inicial orientou usar a 1.106.2 ou outra versão explícita anterior ao incidente e informou que o registro privado Enterprise não foi afetado. Para avaliar uma instalação concreta, confira os artefatos efetivamente instalados ou executados; a presença de um lockfile, isoladamente, não é prova de ausência de exposição.

Tome cuidado com um detalhe: como o hook roda no início do Python, basta a instalação pra máquina ser afetada. Não importa se o seu código chegou a usar a biblioteca ou não

Como verificar se você instalou a versão maliciosa e o que fazer

O caminho é: descobrir se a versão passou por ali, procurar os arquivos deixados, olhar a rede e, se der positivo, reconstruir e rotacionar tudo

1. Confira lockfiles, manifestos e tags de imagem. Procure litellm na versão 1.107.0 nos arquivos de dependência dos projetos e veja quais tags de imagem os seus deploys usaram em 21/10. O erro comum aqui é olhar só o manifesto com faixa de versão e esquecer o que foi realmente resolvido no build daquele dia

2. Procure os arquivos que o malware deixa no sistema. O LiteLLM orienta procurar por litellm-1.107.0.dist-info, cook.pth e sitecustomize.py no sistema de arquivos, dentro dos diretórios site-packages de cada ambiente Python que você mantém em produção

Encontrar qualquer um desses itens confirma a exposição. Mas atenção: o próprio LiteLLM avisa que não encontrar nada não prova que o ambiente está limpo, então não trate a ausência de resultado como atestado de segurança. A documentação do módulo site do Python também prevê um módulo sitecustomize para personalizações locais. Por isso o nome do arquivo, isoladamente, precisa ser interpretado junto com sua origem e o contexto da instalação; não remova arquivos legítimos indiscriminadamente.

3. Cheque os logs de rede. Procure requisições de saída para www.litellm.dev/healthcheck, indicador de rede publicado pela Wiz, e para raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt, indicador publicado pela Datadog Security Labs

4. Reconstrua do zero, em vez de só desinstalar. A recomendação do LiteLLM é reinstalar fixando litellm==1.106.2 e, de preferência, reconstruir imagens e venvs do zero. A StepSecurity e a Endor Labs (citada pelo The Hacker News) vão além e recomendam fixar as imagens de contêiner por digest, não por tag. O erro comum é remover o pacote e seguir a vida: os arquivos ficam na raiz do site-packages e o carregador busca código remoto, então o ambiente inteiro não é mais confiável

5. Rotacione todas as credenciais acessíveis no host. O LiteLLM recomenda rotacionar tudo o que o host alcançava: o papel IAM da instância ou task, todas as chaves de provedores guardadas no banco do proxy (mais master keys e virtual keys), a senha do DATABASE_URL e qualquer segredo no ambiente de qualquer processo do host. A StepSecurity inclui ainda chaves SSH e GPG, senhas de navegador, tokens de ferramentas de IA e segredos de CI e Vault. Rotacionar só a chave da OpenAI ou da Anthropic e esquecer o resto é meio caminho andado, e o malware não escolhia alvo. Se o host tinha internet de saída, assuma que a exfiltração aconteceu

6. Revise os logs de auditoria da nuvem. O LiteLLM orienta procurar no CloudTrail chamadas GetCallerIdentity feitas pelo papel da instância perto do horário da instalação e, depois, uso das credenciais desse papel fora da sua infraestrutura

Conteúdo complementar do canal

Confira também o conteúdo de programação do canal Hora de Codar.

Próximo passo: fixar dependências antes do próximo incidente

Depois de verificar e rotacionar, reduzir atualizações não avaliadas no build é uma das medidas para diminuir a exposição a novas releases comprometidas

No contexto da resposta ao incidente, o comunicado recomendou litellm==1.106.2 ou outra versão explícita anterior. Para uma implantação atual, confira os avisos e recomendações oficiais mais recentes; não trate uma versão histórica citada aqui como garantia permanente de segurança. Fixar imagens por digest ajuda a identificar o artefato escolhido.

O controle de atualização ajuda na rastreabilidade, mas não substitui a avaliação da origem do artefato, a proteção das credenciais e a investigação de incidentes.

E fique de olho na página de incidente do LiteLLM, que é onde o projeto publica as atualizações oficiais sobre o caso

até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.