Pipeline de releases do LiteLLM sequestrada de novo: infostealer distribuído como v1.107.0 no PyPI e no Docker Hub
Na manhã de 21 de outubro de 2026, um release malicioso do LiteLLM chegou ao PyPI e às imagens oficiais de Docker do projeto. A versão 1.107.0 carregava um ladrão de credenciais e um carregador de código remoto no lugar do código escrito pelos mantenedores. Segundo o próprio aviso de segurança do LiteLLM, o pipeline de releases foi comprometido com credenciais de GitHub vazadas de contas de desenvolvedores do projeto. Os wheels maliciosos passaram menos de duas horas no PyPI, e as tags contaminadas do Docker sobreviveram à tarde inteira. Num ecossistema de builds automatizados e dependências fixadas, foi tempo mais que suficiente para causar estragos.
Tag limpa, build envenenado
A divulgação se lê como uma lista do quão frágil é a confiança em pacotes. O LiteLLM relata que o atacante obteve tokens OAuth do GitHub CLI de três contas de desenvolvedores, aparentemente capturados nos logs de um deploy interno do LiteLLM exposto à internet; uma das contas pertencia a um dono de organização no GitHub. Com essas credenciais, a proteção de branch foi sobreposta, uma mudança de workflow foi imposta por force-push e o pipeline foi apontado para um repositório sósia: Berri-AI/litellm, a um hífen do verdadeiro BerriAI/litellm. A tag oficial do git da v1.107.0 continuou limpa; os artefatos maliciosos foram compilados do repositório impostor."Esta versão continha malware compilado que rouba credenciais e carrega ferramentas de execução remota de código." — aviso de segurança do LiteLLM, 21 de outubro de 2026A detecção, ao menos, foi rápida. Como reporta o BleepingComputer, empresas de segurança, incluindo Socket e Endor Labs, sinalizaram o release em cerca de seis minutos, e o PyPI havia removido os wheels às 13:23 UTC, com o Docker Hub limpo na sequência, ainda naquela tarde. O LiteLLM diz que clientes do seu registro corporativo privado não foram afetados. Seis minutos ainda contam quando o pacote registra cerca de 92 milhões de downloads por mês e empresas como NVIDIA, Netflix e Okta constam entre seus usuários, segundo o BleepingComputer.
O que o stealer procura
A mecânica da carga explica o tom direto das orientações. Os wheels depositavam três arquivos — cook.pth, cook.py e sitecustomize.py — no diretório site-packages do Python. O Python executa esses tipos de arquivo a cada início do interpretador, então qualquer processo Python da máquina rodava o malware mesmo que o LiteLLM nunca fosse importado. A análise técnica da Datadog Security Labs acrescenta que desinstalar o pacote litellm não remove os arquivos; é preciso apagá-los manualmente. A análise do incidente pela Kodem documenta o que o stealer foi feito para coletar:- Credenciais de nuvem e infraestrutura: chaves da AWS, Azure e GCP, incluindo tokens de metadados de instância, além de segredos de Kubernetes, Docker e Terraform
- Material específico de IA: chaves de API de provedores de LLM, credenciais guardadas no banco do proxy LiteLLM e arquivos de sessão de ferramentas de programação com IA
- Tokens de desenvolvedor e de registros: credenciais de Git, tokens do GitHub, npm e PyPI, chaves SSH, GPG e TLS
- Segredos locais: arquivos .env, variáveis de ambiente, históricos de shell e de banco de dados
- Dados de navegador: senhas salvas, cookies e entradas de preenchimento automático
Segundo incidente de pipeline no ano
É o segundo release comprometido do LiteLLM em 2026. Em março, um ator rastreado como TeamPCP inseriu backdoor nas versões 1.82.7 e 1.82.8 depois de comprometer um scanner Trivy dentro do pipeline de CI/CD do projeto e roubar um token do PyPI. A Datadog liga as duas campanhas apenas pelo alvo: não há conexão estabelecida entre os atores. O padrão é o desconfortável — um gateway no centro de milhares de stacks de IA, que guarda chaves de provedores e credenciais de nuvem, teve o canal de distribuição corrompido duas vezes em oito meses.A primeira hora, conforme o runbook
A Kodem acompanhou seus indicadores com um runbook de resposta para a primeira hora, e o aviso do LiteLLM é igualmente direto. O núcleo comum:- Bloquear o litellm 1.107.0 no proxy de pacotes, parar de implantar tags flutuantes como latest e fixar o último release limpo, 1.106.2, por hash — imagens por digest
- Não executar python nem pip nos hosts afetados antes da limpeza, porque cada início do interpretador roda a carga novamente
- Isolar hosts e contêineres e depois apagar manualmente cook.pth, cook.py, sitecustomize.py e seus arquivos .pyc compilados
- Rotacionar a partir de uma máquina limpa: papéis de nuvem, chaves de provedores guardadas no banco do proxy, chaves master e virtuais do LiteLLM, a senha do banco de dados e tokens de registros e do GitHub
- Revisar logs de auditoria de nuvem em busca de chamadas GetCallerIdentity e uso de credenciais de infraestrutura inesperada desde 11:39 UTC de 21 de outubro