LiteLLM 1.107.0 distribuiu um ladrão de credenciais (outubro de 2026): versão afetada no PyPI e imagens Docker, e o que os usuários devem fazer

A empresa lista os seguintes artefatos afetados. Todos os horários são de 21 de outubro de 2026.

A empresa diz que você foi afetado se instalou o LiteLLM com pip sem fixar a versão durante a janela, ou se iniciou um contêiner a partir de uma dessas tags durante a janela. Se o CI executa pip install litellm a cada build, ou se o seu Dockerfile usa FROM com a tag latest, a versão afetada pode ter sido instalada sem que ninguém fizesse nada.

• Se um ambiente puder estar afetado, não inicie o Python nem o pip para verificar sua versão. Isole-o primeiro e depois revise os registros de implantação ou os digests das imagens a partir de uma máquina limpa separada. Se não puder descartar a exposição, trate-o como afetado e passe para a reconstrução e a rotação de credenciais abaixo (observação deste site). O comando de verificação de versão da empresa também inicia o Python, portanto não o execute antes da limpeza
• A empresa publicou os nomes de arquivo a procurar e os digests das imagens. Encontrá-los confirma a exposição, mas não encontrá-los não prova que o ambiente esteja limpo
• Se você tinha fixado explicitamente a 1.106.2 ou anterior, ou a 1.107.0rc1 ou rc2, você não foi afetado (a empresa diz que as versões anteriores estão fora deste comprometimento)
• Os clientes que baixam do registro empresarial privado não foram afetados (a empresa)

Segundo a análise do pesquisador citada no aviso da empresa, o malware é instalado como arquivos que o Python carrega automaticamente toda vez que inicia. Ele é executado de novo em qualquer processo Python, inclusive nos que nunca importam o litellm e no próprio pip.

A ordem de limpeza indicada pela empresa é a seguinte (nomes de arquivo e locais estão na página do aviso):

• Sem iniciar o Python, exclua pelo shell os arquivos maliciosos indicados pela empresa (e seus arquivos de cache) de todos os diretórios site-packages afetados
• Pare o processo Python que ficou em execução em segundo plano
• Só então reinstale fixando em litellm==1.106.2. A empresa diz que reconstruir do zero as imagens e os ambientes virtuais é melhor

Se você executou em contêineres, o caminho mais rápido costuma ser parar os contêineres criados a partir da imagem afetada e recriá-los a partir de uma imagem fixada em uma versão limpa (observação deste site).

Na primeira publicação, a empresa pediu que os usuários fixassem 1.106.2 ou qualquer versão explícita publicada antes deste incidente. Em 24 de outubro (UTC), publicou então as versões 1.103.8, 1.104.6, 1.105.4 e 1.106.3. A versão mais recente no PyPI é a 1.106.3, e a 1.107.0 continua removida. Segundo as notas de versão, essas versões removem a autoridade certificadora raiz eMudhra de todos os pacotes de certificados em que o SDK, o proxy e as imagens Docker confiam. O assunto eMudhra é tratado em o que os usuários de Python precisam fazer sobre as chaves da CA intermediária eMudhra.

No Docker, faça referência às imagens por uma tag de versão, ou melhor, por digest (um valor calculado a partir do conteúdo da imagem), e não por tags como latest ou main-stable, cujo conteúdo muda. Assim, uma mudança no que a tag aponta não chega até você.

Segundo as notas de versão, a partir dos lançamentos de 24 de outubro as imagens Docker e os Helm charts são assinados com uma nova chave cosign (cosign é uma ferramenta para assinar e verificar imagens de contêiner), e a verificação com a chave anterior falha. Se você fixa o cosign.pub antigo em scripts de cosign verify, verificações de CI ou políticas do Kubernetes que checam assinaturas (como o Kyverno), substitua-o pela nova chave do commit citado nas notas de versão. As notas de versão também listam o SHA-256 da nova chave; compare a chave que você baixar com ele antes de trocar (observação deste site).

A empresa diz que, se a 1.107.0 chegou a ser instalada em um host com acesso de saída à internet, você deve presumir que os dados roubados foram enviados com sucesso. Ela cita em especial:

• A função de nuvem associada ao servidor ou ao contêiner (como uma função IAM de instância ou de tarefa da AWS)
• Todas as chaves de provedores de LLM guardadas no banco de dados do proxy LiteLLM
• A chave mestra do proxy e todas as chaves virtuais que você emitiu
• A senha na string de conexão do banco de dados (DATABASE_URL)
• Todos os segredos que estavam no ambiente de qualquer processo em execução no host

Na análise do pesquisador, o malware também foi feito para coletar chaves SSH, credenciais de Git e de publicação de pacotes, tokens do Kubernetes, senhas salvas em navegadores e as configurações de assistentes de programação com IA. Se você executou a 1.107.0 em um notebook de desenvolvedor, as credenciais desse notebook também precisam ser rotacionadas.

Emita uma nova chave no painel de cada serviço e revogue a antiga (observação deste site: defina primeiro a nova chave e depois revogue a antiga, para evitar uma interrupção). O tratamento de chaves de API é tratado em o que torna arquivos .env e chaves de API arriscados.

A empresa pede que você verifique, no log de auditoria da AWS (CloudTrail), uma chamada de verificação de identidade (GetCallerIdentity) feita com a função da instância na época da instalação e, depois, qualquer uso das credenciais dessa função a partir de fora da sua própria infraestrutura.

Como observação deste site, verifique também nos painéis dos seus provedores de LLM se houve algum aumento inesperado de uso ou de cobranças desde as 11:39 UTC de 21 de outubro (a noite no Japão). Quando uma chave de LLM roubada é usada, isso pode aparecer no uso e na cobrança. O que acontece com chaves roubadas é tratado em como chaves de API roubadas levam ao banimento de contas.

Os ambientes afetados foram os que instalaram com pip sem versão fixa, ou usaram tags como latest, main-latest e main-stable, cujo conteúdo muda. Os ambientes que fixaram a 1.106.2 e referenciaram as imagens Docker por digest não foram afetados, mesmo que tenham sido reconstruídos durante a janela.

Como primeiro passo, fixe as dependências usadas em produção e no CI com um arquivo de lock que inclua hashes (pip install --require-hashes, ou arquivos de lock do uv ou do Poetry). Uma configuração que evita versões publicadas muito recentemente (como o exclude-newer do uv, que ignora tudo o que foi publicado depois de um determinado momento) também ajuda contra lançamentos retirados em poucas horas. A abordagem é tratada em auditoria de dependências com o OSV-Scanner.

O banco de dados do proxy guarda as chaves de todos os provedores que você conecta. Quando você precisa rotacioná-las, como agora, não saber qual chave pertence a qual ambiente deixa você entre esquecer algumas ou desligar tudo.

Usar chaves de provedor separadas para desenvolvimento, testes e produção, e definir limites de gastos e alertas no lado do provedor, torna a rotação menor e ajuda a perceber o uso indevido mais cedo. O que fazer quando uma chave vaza é tratado em uma chave de API que vazou de código escrito por IA.

Segundo a análise de causa raiz, o ponto de partida foi uma chave mestra enviada por engano a um repositório público em maio. O commit foi rapidamente sobrescrito e as chaves expostas foram identificadas como precisando de revogação, mas a chave mestra não foi revogada, e foi usada cerca de quatro meses e meio depois. A empresa diz que o incidente é uma forte ilustração do risco de não rotacionar uma chave potencialmente exposta.

Se você enviar um segredo a um repositório público, revogue e substitua a chave antes de se preocupar com o histórico. Depois de rotacionar, confira a lista das chaves que você substituiu para garantir que nenhuma foi esquecida (observação deste site). O problema é tratado em credenciais vazadas que continuam válidas.

Segundo a análise, o primeiro token levado estava configurado na plataforma de agentes para que ela pudesse abrir pull requests. Ele não estava ligado a uma conta de serviço e não tinha escopo reduzido: era o token pessoal do GitHub CLI de um proprietário da organização. A empresa observa que os tokens do GitHub CLI são emitidos após a autenticação em dois fatores e não estão sujeitos à nova autenticação que o GitHub pede antes de ações sensíveis.

Dê a agentes e bots um token dedicado, com escopo apenas para a sua função (um GitHub App ou um token de granularidade fina), e mantenha os direitos de proprietário separados das contas usadas no dia a dia (observação deste site). Disponibilizar os segredos de CI apenas aos workflows e ambientes que precisam deles também limita até onde um token roubado pode chegar (observação deste site). A proteção de uma conta do GitHub é tratada em como configurar a autenticação em dois fatores do GitHub.

Isso acabou não sendo a causa, mas a primeira publicação da empresa observou que, em situações específicas, um assistente de programação com IA pode incluir o token do GitHub CLI de um usuário no corpo de uma resposta e, onde os corpos de resposta são registrados em log, esses tokens podem aparecer nos logs do LiteLLM.

Para um gateway que você mesmo executa, verifique três coisas: a interface de administração e a API não são acessíveis diretamente pela internet, as configurações de log que guardam corpos de resposta foram revisadas e, se você os guarda, o período de retenção é curto. A proteção de uma conta do GitHub é tratada em como configurar a autenticação em dois fatores do GitHub.