O LiteLLM 1.107.0, versão distribuída com malware em 21 de outubro de 2026, ganhou um relatório de causa raiz. A conclusão é direta: não foi preciso explorar nenhuma vulnerabilidade de software. Uma chave-mestra vazada em um repositório público em maio nunca foi revogada e, cinco meses depois, abriu o caminho para que um atacante assumisse o processo de lançamento do projeto e publicasse pacotes oficiais com malware.
O LiteLLM publicou o relatório de causa raiz do incidente que envenenou a versão 1.107.0 do seu pacote em 21 de outubro de 2026. A conclusão é direta: não foi preciso explorar nenhuma vulnerabilidade de software. Uma chave-mestra vazada em um repositório público em maio nunca foi revogada e, cinco meses depois, abriu o caminho para que um atacante assumisse o processo de lançamento do projeto e publicasse pacotes oficiais com malware.
O pacote malicioso LiteLLM 1.107.0 (litellm==1.107.0) ficou disponível no PyPI por cerca de duas horas, entre 11h39 e 13h23 UTC, e as imagens Docker com as tags v1.107.0, latest, main-latest e main-stable ficaram comprometidas até 14h20 UTC no Docker Hub e até 13h51 UTC no GitHub Container Registry. O código roubava credenciais e carregava ferramentas de execução remota de código, e era executado assim que o Python iniciava no computador — mesmo que ninguém usasse o LiteLLM. Estimativas da Wiz, com base em dados da ClickPy, apontam cerca de 49 mil downloads da versão comprometida na janela de exposição. O LiteLLM tem cerca de 23 milhões de downloads semanais.
Como aconteceu
Em 27 de maio de 2026, um arquivo de configuração chamado opencode.json, com a chave-mestra de um sistema interno do LiteLLM (a Agent Platform), foi enviado a um repositório público no GitHub. O arquivo foi apagado cerca de três horas depois, mas o commit permaneceu no histórico público até 22 de outubro e, nas palavras do próprio LiteLLM, a revogação da chave não aconteceu.
Em 10 de outubro, o atacante usou essa chave e encontrou, nas respostas da plataforma, um token de login do GitHub pertencente a um dos donos da organização do LiteLLM no GitHub. Com esse token, ele roubou os tokens de outros dois engenheiros e, em 21 de outubro, usou os três para redirecionar o processo de lançamento para um repositório parecido (Berri-AI/litellm, em vez do legítimo BerriAI/litellm), aprovar a publicação e apagar os registros. Na mesma semana, o LiteLLM havia relaxado temporariamente a regra de aprovação de lançamentos, que passou a permitir que dois engenheiros publicassem correções diárias — e o atacante explorou exatamente essa brecha.
Quem foi afetado e o que fazer
Quem instalou o LiteLLM 1.107.0 (litellm==1.107.0) do PyPI ou executou uma das imagens afetadas em 21 de outubro deve considerar o ambiente comprometido. O LiteLLM recomenda reconstruir ambientes e imagens do zero, fixando a versão 1.106.2 ou outra versão explícita anterior ao incidente, de preferência implantando por digest da imagem, e não por tag. Também é preciso girar, a partir de uma máquina limpa, todas as credenciais que o computador afetado podia alcançar: chaves de provedores de IA guardadas no banco do proxy, chaves-mestras e virtuais do LiteLLM, senha do banco de dados, tokens de Git, SSH e de registros de pacotes, além de papéis de nuvem. A Microsoft publicou orientações detalhadas de detecção no mesmo dia 23 de outubro, com o identificador de exposição TVM-2026-0003 e detecções chamadas Trojan:PyPI/LiteLlmSupplyChain.
Um detalhe importante: as imagens maliciosas carregam uma assinatura válida da chave de assinatura antiga do LiteLLM. Por isso, uma assinatura válida dessa chave não prova nada sobre as imagens da versão 1.107.0. As versões a partir da 1.106.3, publicadas em 24 de outubro, já usam uma nova chave cosign. Clientes Enterprise que usam o registro privado do LiteLLM não foram afetados pelo incidente.
O que o LiteLLM vai mudar
Em 30 de outubro, o LiteLLM publicou a lista de mudanças: a aprovação de lançamentos voltou a ficar com uma única conta dedicada, vinculada a um dispositivo físico no escritório; contas de donos não poderão mais autorizar aplicativos OAuth nem ser operadas por tokens; alertas de varredura de segredos só serão encerrados após a confirmação da revogação; os logs de auditoria do GitHub passarão a alimentar alertas; e um verificador externo comparará os artefatos publicados no PyPI e no Docker com o código-fonte marcado, podendo retirar divergências automaticamente. Parte das medidas já foi concluída e parte tem prazo entre 15 de novembro de 2026 e 31 de janeiro de 2027.
Separadamente, em 27 de outubro o LiteLLM divulgou uma falha crítica distinta, que afeta apenas proxies com licença Enterprise (GHSA-w4c7-34wj-hqm8, com nota CVSS 10.0 e sem CVE), corrigida nas versões 1.103.10, 1.104.8, 1.105.6 e 1.106.5. Instalações de código aberto sem licença não são afetadas por ela.
O que ainda não se sabe
Ninguém atribuiu o ataque a um autor até agora, e não há confirmação pública de quantas instalações ocorreram nem de que as credenciais roubadas tenham sido usadas. O LiteLLM afirma acreditar que rastreou todos os tokens ao alcance do atacante.
Imagem de destaque: arte oficial do LiteLLM, via litellm.ai.
Fontes: relatório oficial do incidente do LiteLLM; AI Cyber Brief — LiteLLM explains its poisoned release; DEV Community — Deleting the File Didn't Revoke the Key.
Transparência: esta matéria foi produzida com auxílio de inteligência artificial, a partir do cruzamento de publicações públicas e de fontes da internet citadas ao longo do texto. Recomendamos consultar as fontes originais para confirmar as informações.
Por Muse
