Era 11h09 UTC do dia 24 de março de 2026 quando o notebook de Callum McMahon simplesmente travou. Mais de 11.000 processos rodando em paralelo, CPU a 100%, sistema inoperante. Primeiro pensamento: algum loop maluco no Claude Code. Segundo pensamento: o que diabos está acontecendo?

Trinta e dois minutos depois, ele tinha identificado a causa raiz. Setenta e dois minutos após os primeiros sintomas, a divulgação estava publicada. O que ele descobriu não era um bug — era um ataque de supply chain contra o LiteLLM, uma das bibliotecas Python mais baixadas do planeta.

O que é o LiteLLM e por que isso importa

Se você já conectou seu código a múltiplos provedores de IA — OpenAI, Anthropic, Google Gemini, Mistral — provavelmente já usou o LiteLLM sem saber. É uma das bibliotecas mais populares do ecossistema Python para quem trabalha com LLMs, funcionando como um proxy universal que padroniza chamadas para qualquer modelo.

Números que ajudam a entender a escala: 97 milhões de downloads mensais no PyPI. É o tipo de dependência que entra silenciosamente em projetos de IA, frameworks de agentes, MCP servers e pipelines de produção inteiros.

E foi exatamente isso que tornou o ataque tão perigoso.

Quem é o TeamPCP

Antes de entender o que aconteceu com o LiteLLM, vale conhecer quem está por trás. O grupo TeamPCP — também rastreado como PCPcat, Persy_PCP, ShellForce e DeadCatx3 — opera pelo menos desde dezembro de 2025. Têm canais no Telegram (@Persy_PCP e @teampcp) e embedam a string “TeamPCP Cloud stealer” nos próprios payloads, como se fosse uma assinatura de artista.

Pesquisadores da Socket e Endor Labs descrevem o grupo como uma “plataforma de crime cibernético nativa da nuvem” — uma mistura de disruption ideológica e ganância financeira. O ataque ao LiteLLM não foi um incidente isolado. Foi a fase 09 de uma campanha em andamento.

A Cadeia do Ataque: Cinco Dias, Quatro Alvos

O que derrubou o LiteLLM não começou no LiteLLM. Começou cinco dias antes, com o Trivy.

A lógica é elegante e perversa: ferramentas de segurança são exatamente o tipo de coisa que você não questiona no CI/CD. Você roda o Trivy porque quer ser seguro. Mas quando o Trivy está comprometido, cada pipeline que confia nele vira um vetor de ataque.

No caso do LiteLLM, a equipe rodava o Trivy sem versão pinada — apt install trivy pegou a versão mais recente, que já estava corrompida. O pipeline então exfiltrou o token de publicação do PyPI diretamente do ambiente do GitHub Actions runner.

Com esse token em mãos, o TeamPCP publicou as versões maliciosas diretamente no PyPI às 10h39 e 10h52 UTC, sem passar pelo processo normal de release do GitHub. Nenhuma tag correspondente existia no repositório oficial.

O Payload: Uma Obra de Engenharia Maliciosa

As duas versões comprometidas usaram técnicas diferentes, mas ambas tinham o mesmo objetivo: roubar tudo que estava no ambiente.

A bomba-fork do arquivo .pth

A versão 1.82.8 incluiu um arquivo chamado litellm_init.pth. Se você não sabe o que é um arquivo .pth do Python, bem-vindo ao clube — a maioria dos desenvolvedores não sabe.

Arquivos .pth são um mecanismo do Python para adicionar caminhos ao sys.path, mas com um efeito colateral: qualquer linha que começa com import executa automaticamente toda vez que o interpretador Python inicia, mesmo que você não importe o LiteLLM explicitamente.

# litellm_init.pth — executa em CADA inicialização do Python
import subprocess; subprocess.Popen(['python3', '-c', '<payload_base64>'])

O problema: o processo filho também inicia o Python, que também lê o .pth, que também spawna outro filho. Exponencialmente. A bomba-fork que travou o notebook de Callum foi, tecnicamente, um bug no malware — os atacantes não pretendiam crashar as máquinas, só queriam rodar o payload uma vez.

O que o malware fazia quando funcionava “corretamente”

Nos casos onde o fork bomb não ocorria, o payload executava uma operação de colheita em três estágios:

1. Reconhecimento: varreu o ambiente em busca de:

• Chaves SSH privadas (~/.ssh/)
• Tokens de AWS, GCP, Azure (~/.aws/credentials, ~/.config/gcloud/)
• Arquivos .env em qualquer diretório
• Configs do Kubernetes (~/.kube/config)
• Histórico do shell (~/.bash_history, ~/.zsh_history)
• Senhas de banco de dados e arquivos de carteiras de criptomoedas

2. Exfiltração criptografada: usou AES-256 para os dados + RSA-4096 para a chave de sessão. Os dados chegam ao C2 ilegíveis para qualquer interceptador intermediário.

3. Persistência e movimento lateral: se encontrou um token de service account do Kubernetes, tentou criar um pod privilegiado em cada nó do cluster no namespace kube-system, montando o filesystem do host. O backdoor foi instalado em /root/.config/sysmon/sysmon.py com um serviço systemd chamado “System Telemetry Service” — nada suspeito, certo?

CanisterWorm: C2 que Não Pode Ser Derrubado

Aqui é onde o TeamPCP mostrou que não é um grupo qualquer. O componente CanisterWorm usa o Internet Computer Protocol (ICP) — uma rede blockchain descentralizada — como infraestrutura de C2.

O que isso significa na prática: ao contrário de um C2 tradicional que pode ter o domínio tirado do ar por um registrador ou provedor de hosting, um canister ICP não tem dono centralizado que possa ser forçado a remover o conteúdo. É a primeira vez documentada publicamente que um worm de supply chain usa ICP dessa forma.

O canister expõe três métodos simples:

get_latest_link()  → URL do payload atual
http_request()     → serve o payload
update_link(url)   → troca o payload SEM republicar nenhum pacote

Máquinas infectadas continuam se conectando ao canister periodicamente mesmo depois que os pacotes foram removidos do PyPI. O atacante pode rotacionar o payload a qualquer momento. Ah, e tem um kill switch embutido: se a URL retornada contiver youtube.com, o backdoor não executa. Elegante.

IA Como Arma de Ataque

Um detalhe que passou despercebido em muita cobertura: o componente hackerbot-claw usa um agente de IA chamado openclaw para targeting automatizado de ataques. Pesquisadores da Aikido documentaram isso como um dos primeiros casos de um agente de IA sendo usado operacionalmente em um ataque de supply chain.

Enquanto a indústria debate como usar IA para defesa, grupos como o TeamPCP já estão usando IA para ataque. Pense nisso.

A Tentativa de Suprimir a Divulgação

Quando membros da comunidade começaram a reportar o comprometimento na issue #24512 do GitHub, o TeamPCP respondeu com uma operação de supressão coordenada: 88 comentários de bot de 73 contas únicas em uma janela de 102 segundos entre 12h44 e 12h46 UTC. Não eram contas recém-criadas — eram contas de desenvolvedores previamente comprometidas.

Usando a conta do maintainer krrishdholakia (que tinha sido comprometida), os atacantes fecharam a issue como “not planned” e fizeram commits em repositórios não relacionados com a mensagem “teampcp update”. Provocação ou identificação de rastro — não está claro.

Quem Foi Afetado e Como Verificar

Você pode ter sido afetado se:

• Instalou ou atualizou o LiteLLM via pip em 24/03/2026 entre 10h39 e 16h00 UTC
• Rodou pip install litellm sem versão pinada e recebeu 1.82.7 ou 1.82.8
• Construiu imagens Docker durante essa janela com pip install litellm sem versão pinada
• Alguma dependência do seu projeto puxou o LiteLLM como dependência transitória não pinada

Para verificar:

# Verificar versão instalada
pip show litellm

# Procurar o arquivo .pth malicioso
find $(python3 -c "import site; print(site.getsitepackages()[0])") -name "litellm_init.pth" 2>/dev/null

# Verificar backdoor de persistência
ls ~/.config/sysmon/ 2>/dev/null
systemctl --user status sysmon 2>/dev/null

Se encontrar qualquer desses artefatos:

# Remover o pacote e purgar cache
pip uninstall litellm -y
pip cache purge
rm -rf ~/.cache/uv  # se usar uv

# Verificar e remover backdoor
rm -rf ~/.config/sysmon/
systemctl --user disable sysmon 2>/dev/null
systemctl --user stop sysmon 2>/dev/null

# URGENTE: rotacionar credenciais
# Todas as chaves AWS, GCP, Azure, SSH devem ser consideradas comprometidas

O ID de vulnerabilidade no Snyk é SNYK-PYTHON-LITELLM-15762713.

O Ecossistema de IA Tem um Problema de Supply Chain

O LiteLLM não é apenas mais uma biblioteca Python. É parte de um ecossistema interconectado de ferramentas que está sendo adotado rapidamente por empresas de todos os tamanhos para construir produtos com IA.

Frameworks como LangChain, LlamaIndex, AutoGen e dezenas de MCP servers dependem do LiteLLM como dependência transitória. Num ambiente onde o LiteLLM funciona como gateway centralizado de LLMs — armazenando chaves de API para OpenAI, Anthropic, Google e outros provedores — uma única instalação comprometida pode expor todas as credenciais de IA de uma organização de uma vez só.

É diferente de um app web sendo comprometido. A superfície de ataque inclui:

• Chaves de API de todos os provedores de LLM (valores que podem gerar contas enormes em minutos)
• Tokens de autenticação de serviços cloud onde o app roda
• Acesso a clusters Kubernetes inteiros via service accounts
• Dados sensíveis que passam pelo proxy (prompts, respostas, dados de usuários)

Esse é o motivo pelo qual o TeamPCP mirou especificamente no LiteLLM: o retorno por alvo comprometido é excepcionalmente alto.

Boas Práticas que Teriam Prevenido Isso

Nenhuma dessas práticas é nova. Todas são “melhores práticas” que todo mundo conhece e poucos seguem consistentemente.

1. Pine suas dependências

# pyproject.toml — ERRADO
dependencies = ["litellm"]

# CERTO — pin the exact version
dependencies = ["litellm==1.82.6"]

Ou melhor ainda, use um lockfile gerado:

# uv (recomendado)
uv lock  # gera uv.lock com hashes verificáveis

# pip-tools
pip-compile --generate-hashes requirements.in

2. Verifique hashes em CI/CD

# pip com verificação de hash
pip install --require-hashes -r requirements.txt

# formato no requirements.txt
litellm==1.82.6 \
    --hash=sha256:abc123... \
    --hash=sha256:def456...

3. Não confie cegamente em ferramentas de CI/CD

# GitHub Actions — ERRADO
- uses: aquasecurity/trivy-action@latest  # pega qualquer versão

# CERTO — pin por commit hash, não por tag
- uses: aquasecurity/trivy-action@a20de5420d57c4102486cdd9349b532415f1b622

Tags podem ser sobrescritas (exatamente o que o TeamPCP fez). Commit hashes não.

4. Audite dependências transitórias

# Ver todas as dependências e versões
pip-audit  # verifica vulnerabilidades conhecidas
uv tree    # mostra árvore de dependências

# Dependências de um pacote específico
pip show litellm | grep Requires

5. Minimize permissões em ambientes de CI/CD

O token PYPI_PUBLISH não deveria ter sido acessível para qualquer step do pipeline que rodasse código externo não verificado. Variáveis de ambiente sensíveis devem ser isoladas nos steps que realmente precisam delas, usando secrets scoped:

jobs:
  publish:
    steps:
      - name: Publish to PyPI
        env:
          PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
        run: twine upload dist/*
      # outros steps NÃO têm acesso ao PYPI_TOKEN

O que Muda Depois Disso

Ataques de supply chain não são novidade — SolarWinds, log4shell, xz-utils. Mas o TeamPCP trouxe algumas inovações que merecem atenção:

1. Pivoting via ferramentas de segurança: atacar o Trivy para chegar ao LiteLLM é um movimento cirúrgico. Qual empresa questiona o scanner de vulnerabilidades que roda no CI/CD?

2. C2 descentralizado: o ICP como infraestrutura de C2 representa uma evolução séria. Takedowns tradicionais não funcionam. A indústria de segurança vai precisar de novas abordagens.

3. IA como ferramenta ofensiva: o openclaw não é o último agente de IA que vai aparecer em ataques. É o primeiro documentado.

4. Bomba de supressão coordenada: 88 comentários em 102 segundos de contas legítimas comprometidas. Não é força bruta — é operação de informação.

As lições práticas são conhecidas mas raramente seguidas: pine suas dependências, use lockfiles, assine commits, verifique checksums, e — talvez o mais importante — trate suas ferramentas de segurança com o mesmo ceticismo que você trata qualquer outro software de terceiros.

O ataque ao LiteLLM durou menos de três horas no ar. Três horas que podem ter comprometido dezenas de milhares de ambientes. E o TeamPCP, segundo os pesquisadores, não terminou. “This campaign is almost certainly not over.”

Fonte de inspiração: My minute-by-minute response to the LiteLLM malware attack e relatórios técnicos do Arctic Wolf, Datadog Security Labs, Snyk, Endor Labs e Aikido Security.

👉 Leia também: Axios Hackeado no NPM: Seu npm install Pode Ter Instalado um Trojan

• A IA Escapou da Caixa: Os Piores Bugs, Vazamentos e Falhas de Segurança Causados por Inteligência Artificial