Reportagens e análises de segurança indicam que o LiteLLM 1.107.0 foi uma versão maliciosa distribuída em 21 de outubro de 2026 pelo PyPI e por determinadas tags oficiais de contêineres. A versão apontada como segura para reversão é a 1.106.2. Para quem instalou ou executou os artefatos afetados, a resposta necessária vai além de uma atualização comum: isolar o ambiente, reconstruí-lo a partir de uma base limpa e rotacionar as credenciais acessíveis.

Quais artefatos do LiteLLM teriam sido comprometidos

As informações disponíveis apontam o LiteLLM 1.107.0 como a versão comprometida, com exposição tanto no pacote do PyPI quanto nas imagens oficiais de contêiner. O alerta fornecido cita pacotes PyPI e imagens Docker, incluindo latest e main-stable, enquanto análises de segurança da Wiz e da Aikido também mencionam v1.107.0 e main-latest.

Esse alcance é relevante porque alguns usuários afetados podem não ter selecionado diretamente a versão 1.107.0. Equipes que dependiam de tags móveis de imagem podem ter baixado uma compilação contaminada em seus processos normais de implantação, sem uma atualização explícita de versão.

Dentro do escopo reportado, os principais fatos disponíveis são:

Os relatos disponíveis não coincidem quanto ao momento da limpeza nos diferentes canais. Um trecho de issue no GitHub vinculado a BerriAI/litellm afirmou que o PyPI já havia sido limpo, enquanto as tags flutuantes do Docker ainda estavam infectadas em determinado momento de 21 de outubro; posteriormente, a Wiz descreveu que essas tags foram removidas. Isso sustenta o quadro geral do incidente, sem permitir definir um único horário final para a limpeza.

Por que a carga maliciosa reportada era especialmente arriscada

Segundo a JFrog, o wheel malicioso do LiteLLM utilizava um gancho de inicialização do Python, permitindo que a carga fosse executada quando o Python fosse iniciado em um ambiente afetado, sem aguardar que uma aplicação importasse diretamente o LiteLLM. No trecho disponível, a JFrog atribui esse comportamento a um arquivo cook.pth, processado durante a inicialização normal do site pelo Python.

Se esse mecanismo estava presente, o perímetro de exposição se torna mais amplo do que uma chamada a uma biblioteca comprometida. Iniciar o Python no ambiente afetado poderia acionar a lógica de roubo de credenciais, o que ajuda a explicar por que as orientações priorizam contenção e rotação de segredos, em vez de apenas substituir uma versão do pacote.

O alerta fornecido afirma que os dados sensíveis em risco incluíam credenciais de nuvem, chaves de API de IA e chaves privadas SSH. Uma reportagem separada, de março de 2026, resumiu uma publicação de Andrej Karpathy sobre um ataque mais amplo ao LiteLLM no PyPI, que teria roubado chaves SSH, credenciais de nuvem, configurações do Kubernetes, credenciais Git, variáveis de ambiente, chaves de CI/CD e senhas de bancos de dados. Esse relato anterior, porém, não estabeleceu o alcance das tags Docker nem a lista exata de artefatos 1.107.0 do evento de outubro.

O que os usuários afetados devem fazer agora

A resposta reportada é interromper o uso da versão 1.107.0, reverter ou fixar a versão 1.106.2, isolar qualquer host ou contêiner que tenha instalado ou executado o artefato afetado, reconstruir o ambiente a partir de uma base limpa e rotacionar as credenciais às quais esse ambiente tinha acesso. Tanto a Aikido quanto a JFrog enquadram o problema em torno de saber se o pacote ou a imagem maliciosa foi instalado ou executado, e não se ele continua disponível agora.

Essa distinção é importante. Uma atualização no próprio ambiente pode remover a versão maliciosa daqui em diante, mas não responde se segredos já foram expostos enquanto o wheel ou a imagem contaminada estava ativo.

Para operadores, o gatilho prático para agir é amplo: quem instalou litellm==1.107.0, baixou uma tag flutuante reportada como afetada ou iniciou o Python em um ambiente exposto deve tratar o host ou o contêiner como potencialmente comprometido. Os relatos disponíveis recomendam reconstruir a partir de imagens ou ambientes limpos e rotacionar quaisquer credenciais de nuvem, API, SSH, banco de dados ou similares acessíveis a partir desse runtime.