Um ataque ao LiteLLM comprometeu a cadeia de distribuição da popular ferramenta de integração de inteligência artificial, expondo desenvolvedores e empresas ao risco de roubo de credenciais e informações sensíveis. O incidente, identificado em 21 de outubro de 2026, envolveu a versão 1.107.0, distribuída pelo repositório Python Package Index (PyPI), além de imagens de contêiner associadas ao Docker Hub e ao GitHub Container Registry (GHCR).
A ameaça utilizou mecanismos legítimos de inicialização do Python para executar código malicioso automaticamente, sem exigir modificações diretas no código-fonte das aplicações. O objetivo era coletar informações como chaves de acesso à AWS, Google Cloud e Microsoft Azure, tokens do GitHub, credenciais SSH, variáveis de ambiente e outros segredos disponíveis nos sistemas comprometidos.
O incidente representa um alerta importante para administradores Linux, desenvolvedores Python e equipes DevOps. Como o LiteLLM é utilizado para conectar aplicações a diferentes modelos de inteligência artificial, uma versão adulterada pode alcançar ambientes corporativos, pipelines de integração contínua e servidores que processam informações confidenciais.
Como ocorreu o ataque à cadeia de suprimentos do LiteLLM
O comprometimento ocorreu no processo responsável pela construção e publicação dos artefatos oficiais do LiteLLM. Em vez de atacar diretamente cada organização que utiliza a ferramenta, os invasores exploraram a infraestrutura de distribuição para inserir componentes maliciosos em pacotes que seriam posteriormente instalados pelos próprios usuários.
Esse tipo de operação é conhecido como ataque à cadeia de suprimentos de software, ou software supply chain attack. A estratégia consiste em comprometer uma dependência, ferramenta de desenvolvimento ou processo de publicação para alcançar vários alvos por meio de um único ponto de entrada.
No caso do LiteLLM, os relatos do incidente apontam que o comprometimento envolveu credenciais de desenvolvedores e alterações no fluxo automatizado de publicação. Isso permitiu a distribuição de artefatos adulterados, apesar de o código-fonte oficial da versão correspondente não apresentar necessariamente os mesmos componentes maliciosos.
A diferença entre o código disponível no repositório e os arquivos efetivamente publicados é um dos aspectos mais preocupantes do episódio. Mesmo equipes que acompanham o desenvolvimento de um projeto podem instalar um pacote comprometido quando o processo de geração e distribuição não oferece garantias suficientes de integridade.
Pacotes PyPI e imagens Docker foram afetados
A versão LiteLLM 1.107.0 é o principal ponto de atenção para usuários que realizaram instalações ou atualizações durante a janela de exposição.
Segundo as informações divulgadas sobre o incidente, os pacotes wheel comprometidos permaneceram disponíveis no PyPI em 21 de outubro de 2026, entre 11h39 e 13h23 UTC. No Docker Hub, a janela de distribuição dos artefatos afetados teria ocorrido entre 11h46 e 14h20 UTC.
Esses horários são importantes para a investigação, mas não devem ser utilizados como único critério para descartar uma exposição. Pacotes podem permanecer armazenados em caches, registros privados, servidores de build e imagens de contêiner criadas durante o período do ataque.
No caso do GHCR, também é necessário verificar os artefatos utilizados pela organização e seus respectivos identificadores criptográficos. A simples presença de uma tag não comprova que determinada imagem contenha o código malicioso.
Outro problema envolve a utilização de versões sem fixação de integridade. Quando um ambiente instala automaticamente a versão mais recente de uma biblioteca, uma publicação comprometida pode ser incorporada ao sistema sem revisão humana.
Para equipes DevOps, o incidente reforça a necessidade de verificar não apenas os números de versão, mas também os hashes dos pacotes e os digests das imagens Docker.
Como o malware explorou a inicialização automática do Python
A técnica descrita no ataque chama a atenção porque aproveita recursos existentes no próprio interpretador Python. Os arquivos cook.pth, cook.py e sitecustomize.py aparecem entre os componentes associados ao comportamento malicioso.
O Python utiliza arquivos com extensão .pth para configurar caminhos de importação em determinados diretórios de instalação, especialmente dentro de site-packages.
Entretanto, esses arquivos também podem conter instruções de importação executadas durante a inicialização normal do interpretador.
Em uma instalação comprometida, um arquivo como cook.pth pode ser utilizado para acionar automaticamente outro módulo, como cook.py, iniciando a execução do código malicioso.
Isso significa que o usuário não precisa executar manualmente um programa suspeito. Dependendo da configuração, iniciar uma aplicação Python, um utilitário de linha de comando ou uma tarefa automatizada pode ser suficiente para acionar o componente instalado.
O arquivo sitecustomize.py representa outro mecanismo de execução. Quando está disponível no caminho de importação e o processamento do módulo site está habilitado, o Python tenta carregá-lo durante sua inicialização.
Esse comportamento é legítimo e permite personalizações do ambiente. Entretanto, quando explorado por invasores, transforma-se em um ponto de execução automática.
O resultado é especialmente perigoso em servidores e pipelines CI/CD, nos quais processos Python podem ser iniciados repetidamente com acesso a credenciais de infraestrutura.
Além disso, a execução do malware não depende necessariamente de uma chamada explícita ao LiteLLM pela aplicação, pois o código malicioso pode estar associado ao próprio ambiente Python.
Quais informações os invasores tentaram roubar
O objetivo central do código malicioso era coletar informações que permitissem acessar serviços, repositórios e infraestruturas conectadas aos ambientes comprometidos.
Entre os principais alvos estavam credenciais de provedores de computação em nuvem, incluindo AWS, Google Cloud e Microsoft Azure.
Essas informações podem permitir que invasores utilizem recursos computacionais, consultem serviços internos ou tentem ampliar seus privilégios, dependendo das permissões associadas às credenciais.
Outro alvo importante eram os tokens do GitHub, frequentemente utilizados por desenvolvedores e ferramentas de automação para acessar repositórios privados, executar operações de publicação e interagir com pipelines de integração contínua.
O malware também foi descrito como capaz de procurar chaves SSH e GPG, que podem ser utilizadas para autenticação remota e assinatura de artefatos.
Cookies de navegadores e variáveis de ambiente completam a relação de informações sensíveis potencialmente acessíveis.
As variáveis de ambiente merecem atenção especial porque são amplamente utilizadas para armazenar chaves de API, senhas de bancos de dados e segredos necessários à execução de aplicações.
Em plataformas de inteligência artificial, esses dados podem incluir credenciais utilizadas para acessar modelos comerciais, gateways internos e sistemas de monitoramento.
É importante destacar que a capacidade de coletar determinada informação não comprova que ela tenha sido efetivamente roubada. A confirmação depende da análise dos sistemas afetados, dos privilégios disponíveis e dos registros de comunicação externa.
Como funcionavam a exfiltração e a persistência do malware
A operação maliciosa também teria utilizado mecanismos criptográficos para proteger as informações coletadas antes de enviá-las à infraestrutura controlada pelos invasores.
O comportamento descrito envolve os algoritmos AES-256-CBC e RSA-4096, que podem ser combinados em um sistema de criptografia híbrida.
Nesse modelo, os dados são protegidos por uma chave simétrica, enquanto a criptografia assimétrica é utilizada para proteger a chave responsável pela operação.
Para os atacantes, essa abordagem oferece uma vantagem: dificulta a inspeção direta do conteúdo transmitido por soluções de monitoramento de rede.
Isso não impede a detecção de atividades suspeitas, mas pode dificultar a identificação exata das informações enviadas.
Outro componente associado ao ataque é um carregador remoto, projetado para consultar periodicamente um recurso hospedado no GitHub em busca de novas instruções.
O intervalo descrito para essas verificações era de aproximadamente uma hora.
Esse mecanismo permitiria modificar o comportamento da ameaça depois da instalação inicial, sem depender de uma nova atualização do pacote comprometido.
Também foi mencionado o arquivo /tmp/remote_code_loader.lock, associado ao controle da execução do carregador.
Sua presença pode funcionar como indicador durante uma investigação, embora sua ausência não seja suficiente para comprovar que o sistema esteja livre de comprometimento.
A combinação de execução automática, coleta de segredos, criptografia e carregamento remoto aumenta a complexidade da resposta ao incidente.
Mesmo após a remoção do pacote adulterado, credenciais anteriormente expostas podem continuar válidas e permitir novos acessos indevidos.
Como identificar sistemas comprometidos pelo LiteLLM
A primeira medida recomendada é verificar se a versão 1.107.0 foi instalada em servidores, estações de desenvolvimento, ambientes virtuais Python ou pipelines de automação.
Também é necessário identificar contêineres criados a partir das imagens afetadas, especialmente aqueles que utilizaram as tags latest, main-latest, main-stable e v1.107.0.
Um indicador importante é o digest da imagem comprometida:
sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339eOs administradores também devem procurar os seguintes arquivos nos diretórios de instalação do Python:
cook.pth
cook.py
sitecustomize.py
litellm-1.107.0.dist-infoA identificação desses componentes exige cuidado. Alguns nomes, como sitecustomize.py, podem aparecer em configurações legítimas. Por isso, é necessário verificar a origem e o conteúdo dos arquivos.
A ausência desses indicadores não garante que o ambiente esteja seguro, principalmente quando contêineres foram removidos, diretórios temporários foram limpos ou arquivos maliciosos foram apagados após a execução.
Por que não executar o pip imediatamente
Uma das recomendações mais importantes é evitar a execução de comandos Python dentro de um ambiente potencialmente comprometido antes da contenção.
Isso inclui comandos aparentemente inofensivos, como:
python -m pip show litellmO problema é que a inicialização do interpretador pode executar novamente os componentes maliciosos presentes nos diretórios site-packages.
Consequentemente, uma tentativa de verificar ou atualizar o pacote pode provocar uma nova execução do código responsável pela coleta de credenciais.
A investigação inicial deve priorizar ferramentas externas ao ambiente afetado, inspeção de arquivos, registros de implantação e análise de imagens a partir de sistemas confiáveis.
Como remover a versão maliciosa e recuperar os ambientes
A recomendação dos mantenedores é retornar à versão LiteLLM 1.106.2, identificada como uma versão anterior segura.
Entretanto, a simples instalação de uma versão antiga não é suficiente para garantir a recuperação.
O procedimento deve começar pelo isolamento do sistema e pela preservação das evidências necessárias à investigação.
Depois disso, os administradores precisam remover os arquivos maliciosos identificados, incluindo os componentes associados à inicialização automática do Python e suas cópias compiladas em diretórios __pycache__.
Também é necessário encerrar os processos maliciosos em segundo plano.
Para ambientes de produção, a alternativa mais segura é recriar os ambientes virtuais Python e reconstruir as imagens Docker a partir de artefatos confiáveis.
A versão deve permanecer fixada para impedir atualizações automáticas não verificadas.
Em um ambiente limpo, a instalação pode ser realizada com:
python -m pip install "litellm==1.106.2"Esse comando não deve ser executado dentro de um ambiente ainda comprometido.
A recuperação também precisa considerar caches de pacotes, imagens armazenadas em registros privados e sistemas automatizados que possam reutilizar artefatos contaminados.
Rotação de credenciais é uma etapa obrigatória
O risco mais grave do incidente não está apenas na execução inicial do malware, mas na possibilidade de os invasores continuarem utilizando credenciais roubadas depois da remoção do pacote.
Por isso, qualquer sistema que tenha executado a versão comprometida com acesso à internet deve ser tratado como potencialmente exposto.
As equipes de segurança precisam substituir as chaves de API dos provedores de inteligência artificial, credenciais de serviços em nuvem, tokens de automação, senhas de bancos de dados e segredos disponíveis nas variáveis de ambiente.
No caso do LiteLLM Proxy, a revisão deve incluir a chave principal, as chaves virtuais e as credenciais dos provedores armazenadas no banco de dados.
Também é importante verificar permissões de identidades de serviço e tokens utilizados por ferramentas CI/CD.
Em ambientes AWS, os registros do CloudTrail podem ajudar a identificar atividades incomuns, incluindo chamadas à operação GetCallerIdentity próximas ao momento da instalação comprometida.
A investigação deve procurar acessos provenientes de endereços IP inesperados, utilização anormal de credenciais e operações incompatíveis com o comportamento habitual das aplicações.
O que o incidente revela sobre a segurança de projetos open source
O ataque ao LiteLLM demonstra que um repositório legítimo pode continuar apresentando código aparentemente seguro enquanto os arquivos distribuídos aos usuários são adulterados.
Esse cenário evidencia a importância de proteger todo o processo de desenvolvimento, desde a autenticação dos mantenedores até a geração, assinatura e publicação dos artefatos.
A utilização de credenciais comprometidas de desenvolvedores, combinada com alterações no pipeline de publicação, permitiu que uma versão maliciosa fosse distribuída por canais normalmente considerados confiáveis.
Para organizações que dependem de ferramentas open source, a principal lição é que a segurança não pode se limitar à análise do código-fonte.
Também é necessário verificar a procedência dos pacotes, controlar permissões de publicação e acompanhar alterações em dependências críticas.
Práticas como fixação de versões, validação de hashes, utilização de digests imutáveis, autenticação reforçada e revisão independente de pipelines ajudam a reduzir a superfície de ataque.
O caso também evidencia a importância de limitar o acesso das aplicações aos segredos de infraestrutura. Quanto menores forem os privilégios de um processo comprometido, menor tende a ser o impacto potencial da invasão.
Ataque ao LiteLLM reforça alerta para desenvolvedores e empresas
O comprometimento da versão 1.107.0 do LiteLLM representa um exemplo concreto de como ataques à cadeia de suprimentos podem transformar uma ferramenta legítima em um mecanismo de distribuição de malware.
Embora os pacotes adulterados tenham sido retirados dos registros oficiais e o incidente de publicação tenha sido contido, sistemas que executaram os artefatos comprometidos ainda exigem investigação.
Para desenvolvedores Python, administradores Linux e equipes DevOps, a prioridade é identificar instalações afetadas, reconstruir ambientes confiáveis e substituir todas as credenciais potencialmente expostas.
A remoção do pacote malicioso não encerra o incidente se os invasores ainda puderem utilizar os segredos coletados.
O episódio reforça a necessidade de tratar dependências de software, pipelines CI/CD e credenciais de serviços de inteligência artificial como componentes essenciais da segurança corporativa.
