Hackers comprometem pipeline do LiteLLM e espalham malware via PyPI e Docker
Versão 1.107.0 do LiteLLM no PyPI e imagens Docker maliciosas roubavam credenciais; empresas detectaram o ataque em seis minutos.
Foto: Wolfgang Weiser (Pexels)
Hackers comprometeram o pipeline de release do LiteLLM e publicaram, em 21 de outubro, a versão 1.107.0 no PyPI e imagens Docker adulteradas com malware capaz de roubar credenciais, segredos e variáveis de ambiente. O diagnóstico foi divulgado nesta quinta-feira (22) pelo BleepingComputer, com base no post-mortem dos mantenedores.
O LiteLLM é um kit de desenvolvimento de software (SDK) em Python de código aberto e um gateway de inteligência artificial (IA) que permite a aplicações acessar modelos de diferentes provedores por uma API comum. Com cerca de 61,8 mil estrelas no GitHub e 92 milhões de downloads mensais no PyPI, o projeto é usado por empresas como NVIDIA, Netflix, AT&T e Okta — o que amplia o alcance potencial de qualquer falha na cadeia de suprimentos.
O que aconteceu
Segundo o BleepingComputer, o ator da ameaça empurrou a versão 1.107.0 para o registro Docker e para o PyPI após o comprometimento do pipeline. Todos os sete pacotes wheel (.whl) dessa versão no PyPI foram afetados e ficaram disponíveis de 11h39min51s a 13h23 UTC, com impacto em sistemas Windows, Linux e macOS. O mantenedor afirmou que a versão continha malware compilado que rouba credenciais e carrega ferramentas de execução remota de código; clientes da oferta privada enterprise não teriam sido atingidos.
No Docker Hub, as tags v1.107.0, latest, main-latest e main-stable apontaram para o índice de imagem comprometido sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e entre 11h46min56s e 14h20 UTC. No GitHub Container Registry (GHCR), as mesmas tags para litellm, litellm-database e litellm-non_root apontaram para índices comprometidos a partir de 11h46min56s UTC e foram tornadas indisponíveis até 13h51 UTC. Várias empresas de segurança de aplicações detectaram o ataque em até seis minutos após a publicação da versão maliciosa e passaram a analisar o incidente.
Na prática, quem instalou litellm==1.107.0 pelo PyPI ou puxou as tags Docker/GHCR no intervalo indicado pode ter exposto tokens de API, chaves de nuvem e outros segredos presentes no ambiente de execução. O vetor clássico de supply-chain — confiar no canal oficial de distribuição — foi o fio condutor do episódio, sem necessidade de explorar vulnerabilidades no código “limpo” do projeto.
O que isso pode mudar
O caso pode acelerar, nas equipes de engenharia e segurança, a revisão de pinagem de versões, a verificação de hashes de pacotes e a restrição de tags flutuantes como latest em pipelines de produção. Em organizações que usam o LiteLLM como porta de entrada para múltiplos provedores de IA, um único artefato contaminado pode irradiar risco por dezenas de serviços e ambientes — da estação do desenvolvedor ao cluster em nuvem.
Também é plausível que gestores de risco e compliance cobrem inventário rápido de dependências Python e imagens de contêiner, além de rodadas de rotação de credenciais onde houver indício de instalação da 1.107.0. Fornecedores de segurança de aplicações, ao detectarem o pacote em minutos, reforçam o argumento de monitoramento contínuo de registries públicos; ainda assim, a janela de quase duas horas no PyPI e um pouco mais no Docker Hub mostra que a velocidade da resposta humana e automatizada continua desigual.
Para o ecossistema de IA aberta, o episódio pode endurecer controles em pipelines de release — assinatura de artefatos, segregação de chaves de publicação e revisão humana em tags críticas — sem alterar, por si só, a utilidade do LiteLLM como gateway. O que muda é a percepção de que popularidade e downloads massivos tornam o projeto alvo privilegiado: quanto maior a confiança no canal oficial, maior o prêmio para quem o compromete.
Fontes: BleepingComputer
Leia mais em: www.mundodosnegocio.com.br