- Diário de resposta minuto a minuto que detectou e analisou em tempo real a infecção pelo pacote malicioso LiteLLM 1.82.8, distribuído via PyPI
- A infecção ocorreu durante a atualização automática do Cursor IDE, quando o arquivo
litellm_init.pth foi executado e causou roubo de credenciais e comprometimento do sistema
- O código malicioso realizou ações combinadas como coleta de chaves SSH e credenciais de nuvem, tentativa de propagação em Kubernetes e criação de fork bomb
- O caso foi reportado imediatamente à equipe de segurança do PyPI e aos mantenedores do LiteLLM, levando ao isolamento do pacote e registro de CVE
- Ferramentas de análise de código com IA, como o Claude Code, tiveram papel central na detecção do ataque e expuseram a necessidade de reforçar a segurança da cadeia de suprimentos no ecossistema de IA
Registro da resposta ao ataque à cadeia de suprimentos do LiteLLM
- A versão LiteLLM 1.82.8 foi confirmada como um pacote malicioso distribuído via PyPI, e o texto registra minuto a minuto o processo desde a detecção da infecção até o isolamento
- A infecção ocorreu durante a atualização automática do Cursor IDE, e entre as dependências instaladas por meio do Claude Code e do gerenciador de pacotes uv, o arquivo
litellm_init.pth foi executado e comprometeu o sistema
- O ataque foi composto por ações combinadas, incluindo roubo de credenciais, instalação de persistência no sistema, tentativa de propagação em Kubernetes e fork bomb
- O caso foi reportado imediatamente à equipe de segurança do PyPI e aos mantenedores do LiteLLM, levando ao isolamento do pacote e emissão de CVE
- Ferramentas de análise de código baseadas em IA tiveram papel central na detecção e análise em tempo real de atividades maliciosas
Detecção inicial e sinais de anomalia no sistema
- Por volta de 11:13 UTC, mais de 11.000 processos Python foram criados em um notebook macOS, fazendo o sistema entrar em estado de travamento
- Comandos no formato
exec(base64.b64decode('...')) eram executados repetidamente, saturando CPU e memória
- Após encerramento forçado e reinicialização, não foram encontrados vestígios relacionados à persistência
- Inicialmente, o caso foi interpretado como um loop não malicioso causado por um loop interno do Claude Code ou por erro em script
uv run
- Depois, por meio de captura de tela do
htop e logs, foi confirmado que um script Python codificado em base64 estava sendo executado repetidamente
Identificação da causa da infecção
- Por volta de 11:40, foi encontrado o arquivo
litellm_init.pth em ferramentas Python instaladas, confirmando o comportamento malicioso
- Arquivos
.pth são executados automaticamente na inicialização do Python e rodam em todos os processos Python
- Coletavam chaves SSH, credenciais de nuvem, senhas de banco de dados, variáveis de ambiente e histórico do shell
- Os dados coletados eram criptografados com RSA e enviados para
https://models.litellm.cloud/
- Houve tentativa de instalar persistência em
~/.config/sysmon/sysmon.py, mas ela foi interrompida por reinicialização forçada
- A infecção ocorreu durante a atualização automática do Cursor IDE (10:58 UTC)
- A extensão
futuresearch-mcp-legacy baixou o litellm 1.82.8 via uvx
- Essa versão existe apenas no PyPI e não tem tag de release no GitHub
- O horário de upload no PyPI foi 10:52 UTC, indicando distribuição imediatamente antes da infecção
Estrutura do código malicioso
- Etapa 1 (
litellm_init.pth): executada automaticamente na inicialização do Python, decodifica e executa a carga útil codificada em base64
- Etapa 2: inclui a chave pública RSA usada para criptografar os dados roubados
- Etapa 3 (
B64_SCRIPT): realiza a coleta e o envio efetivos das credenciais
- Instalação de persistência: tentativa de registrar
sysmon.py como serviço systemd
- Código de propagação em Kubernetes: tentativa de criar pods privilegiados em cada nó usando a imagem
alpine:latest
- Causa da fork bomb: a chamada
subprocess.Popen([sys.executable, "-c", ...]) reexecutava o .pth também nos processos-filho, gerando loop infinito
Escopo do impacto e medidas de resposta
-
Credenciais expostas
- Chaves SSH, credenciais de GCloud e Kubernetes, chaves de API em arquivos
.env, senhas de Supabase, ClickHouse e Grafana etc.
- Medidas imediatas recomendadas
- Rotacionar todas as credenciais SSH e de nuvem
- Reemitir as chaves secretas em
.env e .mcp.json
- Apagar o cache
~/.cache/uv
- Reportar à equipe de segurança do PyPI (
security@pypi.org) e aos mantenedores do LiteLLM
-
Resultado da inspeção do cluster Kubernetes
- Nenhum pod malicioso (
node-setup-*, sysmon) foi encontrado
- Como o código foi executado em ambiente macOS, a propagação dentro do cluster falhou
- Ainda assim, devido à possível exposição de
~/.kube/config, é necessário rotacionar as credenciais
Resposta pública e no PyPI
- Às 11:58 UTC, o litellm 1.82.8 foi baixado do PyPI em ambiente Docker isolado, e a presença do arquivo
.pth malicioso foi confirmada novamente
- O caso foi reportado imediatamente à equipe de segurança do PyPI e ao repositório BerriAI/litellm
- Depois, foi registrado como PYSEC-2026-2 (CVE)
- Às 12:01 UTC, foi redigido e publicado no blog da FutureSearch um post público sobre o ataque à cadeia de suprimentos
- Um PR foi criado e mesclado em 3 minutos
- Às 12:04 UTC, foi proposta a divulgação nas comunidades r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning e r/devops
- Isso induziu resposta rápida das comunidades Python e de segurança
Significado do incidente
- A ferramenta de análise de código com IA Claude Code identificou o comportamento malicioso em tempo real e gerou alertas antes da intervenção de pesquisadores de segurança
- O caso mostra um ataque à cadeia de suprimentos mirando diretamente o ecossistema de desenvolvedores de IA, destacando a necessidade de reforçar a segurança de contas do PyPI e a verificação de atualizações automáticas
- Também demonstra que ferramentas de IA podem ir além do apoio ao desenvolvimento e ser usadas na automação da detecção e resposta a ameaças cibernéticas
1 comentários
Comentários do Hacker News
Eu sou o desenvolvedor que descobriu e reportou primeiro a vulnerabilidade do litellm
Compartilhei um registro de conversa de análise em tempo real documentando exatamente o que aconteceu
O Claude orientou passo a passo quem eu deveria contatar e em que ordem agir, então foi uma experiência muito útil até para quem não é especialista em segurança
Fiquei curioso se esse tipo de descoberta e reporte de vulnerabilidades por não especialistas ajuda a comunidade de segurança ou se acaba gerando confusão
Dito isso, a parte de “assim que reabri o Cursor, o pacote malicioso foi executado” parece bem arriscada
Assim que surgiu a suspeita, o correto teria sido isolar o dispositivo e contatar a equipe de segurança primeiro
Se o arquivo .pth não tivesse funcionado como uma fork bomb, talvez a descoberta tivesse demorado muito mais
Perguntar ao Claude qual era o caminho de contato foi uma boa decisão
Como eu não sabia com quem falar no PyPI, mandei e-mail para o mantenedor e também postei no Hacker News
Acho que, mesmo sem fazer parte da comunidade de segurança, qualquer pessoa deveria poder reportar vulnerabilidades graves como essa
A maior parte dos problemas vem de gente tentando ganhar dinheiro alegando que qualquer coisa é vulnerabilidade
Mas o seu relatório tinha alta qualidade, e algo assim sobe direto para prioridade de correção
Se desse para resolver sem interromper o negócio, a ação era imediata; se fosse grave, eu reportava direto ao CISO ou ao CTO
Graças ao seu reporte, um incidente maior acabou sendo evitado
Nós também organizamos o assunto em duas postagens no blog
post no blog da grith.ai
Mesmo assim, este caso me parece um bom exemplo de como a ajuda da IA acelerou bastante a análise da causa e o reporte
É a primeira vez que vejo dados do meu tool claude-code-transcripts incorporados em um post de blog
Normalmente eu compartilhava pela página HTML do Gist, então esse uso foi interessante
Tentamos adaptar ao estilo do blog e falhamos, mas isso me fez perceber de novo a importância da experiência padrão
O Claude sai raspando logs como se escaneasse meu computador inteiro, então senti falta de um sistema automático de redação de logs
Isso é especialmente incômodo ao colaborar com a equipe durante uma depuração urgente
Pedidos como “dá para exibir o conteúdo do script malicioso sem executá-lo?” são perigosos
Agentes LLM não têm noção de responsabilidade, então, se por engano emitirem um comando de execução, isso pode causar um incidente sério
Ao baixar arquivos do PyPI, isso deve ser feito obrigatoriamente em um ambiente sandbox
Quando dizem “não faça isso”, eu tendo a ficar ainda mais obcecado por aquilo
Ouvi dizer que o PyPI oferece suporte a atestado digital (digital attestation), então fiquei curioso se esse pacote estava assinado
documentação do PyPI Trusted Publishers
Acho que registries de pacotes como GitHub, npm e PyPI deveriam oferecer um fluxo de eventos em tempo real (firehose) para análise de segurança
Esse tipo de ataque poderia ter sido capturado imediatamente por scanners automáticos
Parceiros de segurança escaneiam os pacotes e podem reportar via API baseada em convite
Veja o post do blog do PyPI
texto relacionado
O objetivo é dar tempo para scanners automáticos detectarem sinais anômalos como arquivos .pth
O dano econômico pode ser grande demais, e só os infectados pelo litellm já passam de 47 mil
A parte “post no blog, PR e merge em menos de 3 minutos” foi a mais chocante
É mais rápido do que o tempo de leitura, o que dá uma sensação de ansiedade
Se não fosse pela fork bomb de 11 mil processos, esse ataque talvez tivesse ficado escondido por muito mais tempo
Se eles tivessem reduzido a velocidade da bomba, o dano teria sido muito maior
Grandes empresas têm duas formas de executar código open source não confiável
Na prática, (1) é o mais seguro
Para pequenas e médias empresas ou pessoas físicas, fixação de dependências (pinning) e um tempo de espera suficiente são a melhor defesa
Com Bazel dá para chegar mais perto de (1), mas a maioria inevitavelmente depende de fontes externas
O fato de o PyPI ter colocado o pacote em quarentena 30 minutos após o reporte foi uma resposta realmente rápida
Uma das melhores coisas sobre IA/LLM é a democratização da engenharia reversa
Antes era uma habilidade difícil de aprender e com pouco retorno, mas agora a IA dá direção
O padrão
exec(base64.b64decode(...))é usado com frequência por ferramentas Python ao transmitir código,mas, em princípio, código executado a partir de /tmp, /var/tmp ou /dev/shm deve ser visto com muita suspeita
Se houvesse uma ferramenta de monitoramento de rede como Lulu ou LittleSnitch, o tráfego anômalo teria sido bloqueado
Só que enviar o binário para o Claude analisar também é outro risco