Incidente de comprometimento dos pacotes PyPI do LiteLLM 1.82.7 e 1.82.8

• Duas versões (1.82.7, 1.82.8) do pacote PyPI da amplamente usada biblioteca de integração de LLM LiteLLM foram distribuídas com payload malicioso inserido, e a instalação desencadeava um ataque para roubar credenciais do sistema
• A causa do ataque teve origem em um comprometimento da cadeia de suprimentos do Trivy, ferramenta de varredura de segurança de CI/CD, o que levou ao vazamento de credenciais do CircleCI e ao roubo do token de publicação no PyPI e de um GitHub PAT
• Usuários da imagem oficial Proxy Docker do LiteLLM não foram afetados porque o requirements.txt fixa a versão, mas ambientes que executaram pip install diretamente a partir do PyPI precisam de verificação imediata
• Centenas de comentários de spam de bots inundaram a thread da issue no GitHub e atrapalharam a discussão real, o que foi confirmado como uma tentativa deliberada do atacante de confundir a comunicação de resposta
• O impacto também se propagou para muitos projetos que usam LiteLLM como dependência, como DSPy e CrewAI, destacando mais uma vez a fragilidade fundamental da segurança da cadeia de suprimentos de software

---

Visão geral do incidente e como foi descoberto

• Durante a configuração de um novo projeto, o sistema começou a se comportar de forma anormal, com esgotamento de RAM e execução de processos em formato de fork bomb
• A investigação mostrou que um blob malicioso codificado em base64 havia sido adicionado a proxy_server.py; ele era decodificado, gravado em um arquivo separado e então executado
• A versão 1.82.7 incluía o payload em litellm/proxy/proxy_server.py, sendo executado ao fazer import litellm.proxy
• A versão 1.82.8 incluía adicionalmente o arquivo litellm_init.pth, de modo que apenas instalar o pacote já fazia com que o malware fosse executado automaticamente na inicialização do Python
  • Arquivos .pth são um mecanismo executado automaticamente pelo módulo site do Python na inicialização e podem executar código arbitrário após a palavra-chave import
  • Esse mecanismo existe desde o Python 2.1 e foi introduzido sem um PEP separado
• A equipe da FutureSearch relatou a primeira infecção: o uvx instalou automaticamente a versão mais recente do litellm (sem fixação de versão), e então o Cursor carregou automaticamente um servidor MCP local, causando a infecção

Caminho do ataque e ligação com o TeamPCP

• Foi confirmado que o ataque foi realizado pelo mesmo grupo TeamPCP responsável pelo comprometimento recente do Trivy
• Caminho da invasão: hack do Trivy → vazamento completo das credenciais do CircleCI → roubo do token de publicação no PyPI + GitHub PAT → distribuição do pacote malicioso
• A conta GitHub do CEO/CTO do LiteLLM também foi totalmente comprometida, com as descrições dos repositórios pessoais alteradas para "teampcp owns BerriAI" e issues sendo fechadas, entre outras ações
• O token PYPI_PUBLISH estava armazenado como variável de ambiente no projeto GitHub, e foi exposto por meio do Trivy
  • A conta tinha 2FA ativado, mas isso foi contornado porque o próprio token foi roubado
• O atacante publicou repetidamente a mesma frase em issues do GitHub usando centenas de contas de bots, dificultando a discussão real
  • O mesmo padrão foi visto no repositório do Trivy, com mais de 700 comentários de spam
  • Algumas das contas de spam pertenciam a usuários reais do GitHub com histórico de contribuição; foi confirmado que, desde fevereiro, haviam feito commits como "Update workflow configuration" para inserir um coletor de credenciais no workflow de CI
• O comprometimento do Trivy ocorreu há pelo menos 5 dias, e como o aviso de ataque mais recente só saiu no dia anterior, é possível que os mantenedores tenham sido afetados sem perceber
• O atacante também usou Internet Computer Protocol (ICP) Canisters para entregar payloads, tornando insuficiente a defesa baseada apenas em bloqueio por DNS

Como o payload malicioso funciona

• Cria um processo Python em segundo plano e decodifica/executa estágios embutidos
• Um coletor de credenciais é executado e, quando a coleta tem sucesso, a chave AES é criptografada com a chave pública RSA do atacante, e os dados roubados são enviados para um host remoto
• URLs encontradas no malware: checkmarx.zone/raw e models.litellm.cloud
• O alvo principal eram chaves SSH em ~/.git-credentials e informações de carteiras cripto
• Como a carga realizava tarefas intensivas de CPU, o sistema ficava sobrecarregado, o que acabou facilitando a detecção; houve até relatos de descoberta pelo barulho das ventoinhas
• O mesmo sintoma apareceu durante a instalação do Harbor: um processo grep -r rpcuser\rpcpassword era executado em forma de fork bomb na tentativa de procurar carteiras cripto

Resposta da equipe do LiteLLM

• As versões afetadas (v1.82.7, v1.82.8) já foram removidas do PyPI
• Senhas alteradas para todas as contas de mantenedores, e todas as chaves do GitHub/Docker/CircleCI/pip foram revogadas e substituídas
• As novas contas de mantenedor passaram a ser @krrish-berri-2 e @ishaan-berri
• O pacote inteiro foi temporariamente colocado em quarentena no PyPI e depois liberado após a remoção das versões infectadas
• Todos os novos releases foram suspensos, com o envio congelado até a conclusão de uma revisão completa da cadeia de suprimentos
• A equipe está trabalhando com o time de segurança Mandiant, do Google, na investigação e recuperação
• O Trivy foi fixado na última versão segura, v0.35.0 (mudando da fixação inicial em v0.69.3 após feedback da comunidade)
• Também estão sendo avaliadas melhorias de segurança, como migração para Trusted Publishing (OIDC com token JWT) e uso de uma conta separada no PyPI
• O primeiro horário de publicação da versão maliciosa foi por volta de UTC 8:30, e a quarentena no PyPI ocorreu por volta de UTC 11:25

Escopo do impacto e projetos downstream

• O LiteLLM é a única biblioteca de chamada de provedor LLM usada pelo DSPy, e o CrewAI também o utiliza como fallback
• Airflow, Dagster, Unsloth.ai, Polar, nanobot e outros também dependem de LiteLLM
• Segundo busca no GitHub, há mais de 628 projetos com LiteLLM no requirements.txt sem fixação de versão
• Usuários que utilizam o caminho oficial de distribuição do Proxy Docker não foram impactados, pois o requirements.txt já está com a versão fixada
• No caso de deploys com Docker, o acesso ao sistema de arquivos do host e a variáveis de ambiente é mais restrito, o que oferece alguma proteção; ainda assim, credenciais montadas continuam em risco
  • O principal alvo do atacante eram chaves SSH pessoais; o acesso a chaves de LLM era secundário
• Usuários de ferramentas como Harbor e browser-use, que instalam LiteLLM automaticamente como dependência, também relataram impacto indireto
• O CrewAI fixou o litellm em 1.82.6 (última versão segura), mas a mensagem de commit não mencionava o comprometimento
• O DSPy está reagindo publicamente por meio de uma issue
• O LangChain possui sua própria camada de chamadas a provedores LLM e, por isso, não foi afetado diretamente por este comprometimento da cadeia de suprimentos (exceto no uso opcional do pacote langchain-litellm)

Discussão da comunidade: segurança da cadeia de suprimentos e sandboxing

• Dependências e ambientes de desenvolvimento não podem mais ser confiados cegamente, e são necessárias defesas em múltiplas camadas (defense in depth) como isolamento por VM + primitivas de contêiner + allowlist + filtro de egress + seccomp + gVisor
• Há a percepção de que 50 anos de conveniência em detrimento da segurança estão cobrando seu preço, e que é preciso redesenhar o modelo de segurança como um todo
• Houve opiniões defendendo sandboxing no nível da linguagem de programação, por módulo
  • O Java já tinha esse recurso desde a v1.2 nos anos 1990, mas ele foi abandonado por problemas de usabilidade
  • Alguns argumentam que este é o momento ideal para linguagens baseadas em capabilities
  • O runtime workerd, da Cloudflare, foi citado como solução existente capaz de isolar módulos
• Ferramentas de isolamento em nível de sistema operacional como pledge/unveil do OpenBSD, chroot/namespace/cgroup no Linux e Capsicum no FreeBSD já existem
• O Guix pode criar contêineres isolados em segundos, permitindo instalar dependências sem acessar $HOME
• Foi defendido o uso mais ativo de ferramentas de isolamento em espaço de usuário como Firejail e bwrap
• O modelo de sandboxing + permissões (Intents) dos apps móveis já existe, mas em desktops há forte resistência a limitar computação geral
  • Em resposta, foi argumentado que o fechamento de app stores de Apple/Meta e o sandboxing de segurança são questões separadas, e que é possível criar ferramentas que preservem o controle do usuário sem abrir mão da segurança
• Foi compartilhada uma ferramenta de canary/honeypot para macOS (github.com/dweinstein/canary): ela monta segredos falsos em WebDAV/NFS para detectar acessos anômalos
• Também houve quem defendesse a criação de uma barreira entre publicação de pacotes e repositórios públicos: ao configurar um repositório público diretamente como Trusted Publisher, a superfície de ataque aumenta
  • Como contraponto, argumentou-se que o objetivo original do Trusted Publishing é fornecer uma ligação auditável entre o código-fonte e o artefato publicado, e que passar por repositórios privados seria um retrocesso

Recomendações práticas de segurança

• Dependências devem ter versão fixada com checksum SHA256 obrigatoriamente
• Operar um espelho interno de pacotes para evitar o uso direto das versões mais recentes
• Usar artefatos de build e evitar depender de instalação em tempo real no deploy com uv run e similares
  • Isso também elimina o risco estrutural de o sistema parar em caso de indisponibilidade do PyPI
  • Vantagens dos artefatos implantáveis: auditabilidade, rollback rápido e possibilidade de bloquear endpoints de rede de saída arriscados
• A configuração exclude-newer do uv permite excluir pacotes novos dentro de um certo período
  • É possível definir [tool.uv] exclude-newer = "5 days" no pyproject.toml
• Em CI/CD, a solução fundamental é migrar tokens de publicação para workflows baseados em OIDC, eliminando o token em si
  • GitHub e PyPI suportam OIDC: se só o job de publicação tiver acesso ao endpoint OIDC, o job do Trivy não terá token para roubar
• Ferramentas de varredura de segurança como o Trivy devem rodar em workers separados sem permissão de publicação
• Recomenda-se manter lockfiles e fazer atualizações semanais, evitando adotar imediatamente a versão mais recente
• Arquivos .pth no Python permitem execução automática de código; é possível inibir a importação de site com a opção -S, embora isso possa causar incompatibilidades
• Também é recomendável fazer varredura de todas as dependências do projeto com ferramentas como osv-scanner
• Comandos para verificar infecção:
  • find / -name "litellm_init.pth" -type f 2>/dev/null
  • find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
• Também foi levantada a necessidade de rotação em massa de credenciais em todo o ecossistema de gerenciadores de pacotes

Auditoria SOC2 e questões de confiabilidade

• Foi apontado que a empresa responsável pela auditoria SOC2 do LiteLLM era a Delve, que esteve recentemente envolvida em controvérsia
• SOC2 apenas verifica se processos documentados estão realmente sendo seguidos, e não garante o nível real de segurança
• Mesmo uma auditoria SOC2 bem-feita talvez não tivesse prevenido este ataque à cadeia de suprimentos

Projetos alternativos ao LiteLLM

• Bifrost (github.com/maximhq/bifrost): alternativa em Rust, com configuração de chaves virtuais até mesmo em instâncias open source gratuitas
• Portkey (portkey.ai): serviço de proxy, com plano gratuito, avaliado por alguns como mais rápido que o LiteLLM
• pydantic-ai: alternativa baseada em Python
• any-llm (github.com/mozilla-ai/any-llm): projeto da Mozilla
• LLM Gateway (llmgateway.io): oferece um guia de migração a partir do LiteLLM
• InferXgate (github.com/jasmedia/InferXgate): projeto novo, com suporte mais limitado a provedores
• Alguns desenvolvedores argumentam que, na prática, as APIs de provedores de LLM se resumem a OpenAI e Anthropic, então chamar diretamente via requests.post() seria mais seguro
  • Em contraponto, a API compatível com OpenAI da Anthropic não é recomendada como solução de longo prazo/produção, e as APIs nativas de cada fornecedor têm recursos próprios que não se mapeiam à API da OpenAI

[GN⁺]

Comentários do Hacker News

• Sou o maintainer do LiteLLM. A situação ainda está sob investigação, mas o que foi apurado até agora é o seguinte

  1. O problema parece ter se originado no trivy usado no CI/CD (link de busca relacionado, post de análise)
  2. Se você usa o proxy docker, não foi afetado. Isso porque a versão estava fixada no requirements.txt
  3. O pacote em questão foi colocado em quarentena no PyPI, bloqueando downloads
     No momento estamos revisando a análise de causa raiz e as medidas para reforçar a segurança, e peço desculpas pelo transtorno
  • As versões afetadas (v1.82.7, v1.82.8) foram removidas do PyPI. Todas as contas de maintainer e chaves (GitHub, Docker, CircleCI, pip) foram trocadas. Ainda estamos escaneando todo o projeto e ajuda de especialistas em segurança é bem-vinda (contato: [e-mail])
  • Disseram que minha conta pessoal do GitHub também parece ter sido comprometida. Há rastros disso nos resultados de busca
  • Obrigado a quem disse que meu “sinto muito” soou humano. Esse retorno de que uma resposta sincera é melhor do que um pedido de desculpas formal ajuda bastante
  • Houve perguntas sobre por que a rotação de credenciais não aconteceu imediatamente. Parece que preciso explicar por que isso não foi percebido em pouco tempo
  • Alguém criou e compartilhou um script simples para encontrar a versão instalada do litellm no próprio sistema (link do script). Não é perfeito, mas consegue escanear rapidamente ambientes conda, .venv, uv e o sistema

• Ainda não podemos confiar em dependências e ambientes de desenvolvimento. Dev containers têm isolamento insuficiente e também deixam a desejar em usabilidade. Agora precisamos migrar para ambientes de desenvolvimento baseados em sandbox. É necessário um ambiente com isolamento em nível de VM, filtro de egress e camadas de defesa como seccomp e gVisor. Em um ambiente assim, mesmo que haja comprometimento, o contêiner seria encerrado imediatamente e o problema poderia ser identificado com facilidade

  • Parece que os atalhos de segurança adotados nos últimos 50 anos finalmente voltaram como um bumerangue. A cultura de desenvolvimento baseada em confiança está chegando ao fim. Não basta sandboxing simples; é preciso redesenhar o próprio modelo de segurança
  • Já não dá mais para dizer “como antigamente”. Segurança verificável criptograficamente é essencial. Devemos caminhar para algo como o DISA STIG da Red Hat, que proíbe o uso de repositórios externos
  • Pediu opiniões sobre seu projeto de isolar credenciais dos contêineres (tightbeam, airlock)
  • Estou desenvolvendo um projeto open source chamado smolvm (link). É uma tecnologia que combina isolamento em nível de VM com suporte a contêineres, com o objetivo de fazer deploy por unidade completa de máquina virtual. Estou procurando pessoas para colaborar
  • Surgiu a pergunta se houve casos reais recentes de escape de dev container entre os ataques à cadeia de suprimentos

• Foi apresentado um canary para macOS (link). É um binário simples em Go que detecta arquivos aos quais um pacote não deveria ter acesso. Ele expõe segredos falsos via WebDAV ou NFS e envia alertas quando há acesso. Dá para detectar comportamento anômalo com essa abordagem de honeypot

• Isso está relacionado às atividades recentes do TeamPCP nas últimas semanas. A linha do tempo que organizei talvez seja útil

  • Recebeu feedback de que a organização ficou excelente. Também houve uma piada dizendo que a “playlist” foi marcante
  • Houve reação de que já tinham visto o nome TeamPCP em vários lugares, mas era a primeira vez que viam tudo organizado de forma tão clara
  • Perguntaram como ele consegue manter as atualizações em dia tão rapidamente

• Houve críticas de que o sistema de detecção de spam do GitHub é fraco demais. Disseram que a issue do litellm recebeu mais de 170 comentários de spam

  • A mesma coisa aconteceu há alguns dias no repositório do trivy. Depois que a discussão sobre o hack foi fechada, surgiram mais de 700 comentários de spam. Alguns vinham de contas com histórico real de atividade. Parece que um ataque de roubo de credenciais se espalhou amplamente. Em várias contas, há sinais de que em fevereiro foi inserido um credential stealer no CI com um commit chamado “Update workflow configuration”
  • Houve reclamações de que denunciar spam no GitHub exige várias etapas e é ineficiente
  • Também foi mencionado que alguns podem ser apenas contas de bot

• Eu já esperava que algo assim fosse acontecer um dia. Tentei me defender com fixação de versões de dependências, mas nem isso é perfeito. Por causa da complexidade da cadeia de suprimentos no open source, é impossível verificar todo o código. Com LLMs, o risco de espalhar malware em grande escala aumentou 100 vezes

  • Houve a opinião de que o ecossistema Rust tem uma árvore de dependências profunda demais, o que dificulta a verificação. Rust, Node e Python sofrem de problemas parecidos. Já C/C++ usa gerenciadores de pacotes de sistema, então o custo de adicionar dependências é maior e, relativamente, mais seguro

• Se código escrito por IA se infiltrar no LLVM ou no Linux, vamos realmente encarar o problema de “trusting trust”

  • O problema de “Trusting Trust” já teve uma solução proposta com Diverse Double-Compiling. Mas ataques à cadeia de suprimentos continuam sendo um desafio difícil. A IA é apenas uma ferramenta que amplia a escala do ataque
  • Agora tudo parece inseguro. Talvez só um ambiente airgap seja seguro. Mas a maior parte dos dados está na nuvem, e nem temos controle sobre seus backups
  • Há esforços em andamento para criar software totalmente verificável por meio de uma cadeia de build determinística. No Debian, 93% dos pacotes têm builds reproduzíveis. Mesmo assim, muitos desenvolvedores continuam executando curl | bash sem pensar duas vezes. O caso do backdoor no XZ foi um exemplo que expôs essa realidade
  • Também houve a opinião de que a única defesa seria mudar frequentemente as APIs internas para impedir que LLMs aprendam o código do kernel
  • Se um ataque desses se tornar real, servidores governamentais ou infraestrutura de nuvem podem sofrer danos em grande escala. Especialmente se combinado com hacking em nível estatal, o prejuízo pode chegar a trilhões de dólares. Ainda assim, acho que o Linux é relativamente seguro

• Foi mencionado que a empresa de auditoria SOC2 do LiteLLM era a Delve.

  • Mas há dúvidas se uma certificação SOC2 teria conseguido impedir esse tipo de ataque. Também foi compartilhado um relato de experiência de que SOC2 não é um escudo completo

• Depois de instalar o Harbor, o uso de CPU subiu para 100% e o sistema travou. O processo grep -r rpcuser\rpcpassword aparentemente tentou procurar carteiras de criptomoedas. Felizmente, nenhum backdoor foi instalado

  • Alguém disse ter passado pela mesma experiência com browser-use. O litellm foi instalado como dependência e o sistema travou. A pessoa revogou os tokens do GitHub e do HuggingFace, mas perguntou se seria necessário reinstalar o sistema operacional
  • Também houve a pergunta “como você verificou o processo tão rápido?”. Queriam saber se ele mantém o Activity Monitor sempre aberto
  • Surgiu ainda a pergunta “o que é Harness?”

• Este caso parece ser obra do mesmo grupo atacante, o TeamPCP que hackeou o Trivy. O padrão de encher a issue com comentários de bot também é o mesmo. É bem provável que tenham usado ataques automatizados com LLM

  • Houve a pergunta de por que os atacantes inundariam a issue com comentários de bot. Provavelmente o objetivo é causar confusão e atrasar a resposta