LiteLLM foi backdoor: audite seu conjunto de ferramentas de IA esta semana

Em março de 2026, um agente de ameaça que se autodenomina TeamPCP publicou uma versão adulterada de litellm, a biblioteca Python que reúne mais de 100 provedores de LLM em um único Interface compatível com OpenAI. A versão enviou um infostealer conectado ao caminho pós-instalação. Qualquer um que correu pip install litellm durante a janela entregue chaves privadas SSH, Credenciais da AWS, tokens do Azure, JSONs de contas de serviço do GCP e Docker config.json arquivos para um endpoint controlado pelo invasor. The Hacker News, Ardan Labs e Security Boulevard cada um confirmou a atribuição e a lista de artefatos exfiltrados.

LiteLLM não é obscuro. Ele fica dentro de estruturas de agentes, dentro de pipelines de CI que roteiam eval tráfego entre provedores, dentro de notebooks Jupyter no laptop de um cientista de dados que também contém credenciais de nuvem de longa duração. Uma única versão comprometida deu ao invasor uma carteira de provedor chaves, um conjunto de funções de nuvem e o material SSH para mover lateralmente para cada repositório dessas chaves poderia alcançar.

Você não pode impedir que o token PyPI de um mantenedor seja roubado. Você pode diminuir o raio da explosão para que quando a próxima biblioteca de IA for atingida; e vai; um laptop não se transforma em um incidente entre nuvens. Aqui estão cinco verificações que valem a pena executar esta semana em toda a IA conjunto de ferramentas: LiteLLM, LangChain, LlamaIndex, wrappers Ollama, SDKs Claude, clientes MCP e todos estrutura de agente que você tem em produção.

O que o TeamPCP realmente levou

A carga correu dentro setup.py e um gancho pós-instalação. Ao importar ou instalar leia o seguinte no diretório inicial do desenvolvedor e no sistema de arquivos do executor de CI:

• ~/.ssh/id_rsa, id_ed25519, e known_hosts
• ~/.aws/credentials e ~/.aws/config perfis
• ~/.azure/ tokens e atualizar credenciais
• GCP application_default_credentials.json e arquivos JSON da conta de serviço
• ~/.docker/config.json incluindo tokens de autenticação de registro
• Variáveis ​​de ambiente começando com AWS_, GCP_, OPENAI_, ANTHROPIC_, GITHUB_

O canal exfil era um HTTPS POST simples para um domínio invasor que era alternado semanalmente. Remoção aconteceu em poucos dias, mas essa janela foi suficiente; credenciais que vazaram não podem ser liberadas. Vamos aos cheques.

Verificação 1: fixe versões exatas, não intervalos

O ^1.14.0 e ~=1.48 padrões em requirements.txt, pyproject.toml, e package.json deixe qualquer novo lançamento menor ou patch role para um ambiente limpo durante a noite. É assim que uma janela maliciosa de três horas se torna um exposição de um mês; seu arquivo de bloqueio nunca foi regenerado, mas seu cache de CI puxou o mal versão em sua próxima compilação a frio.

Fixe versões exatas. Fixar por hash quando o ecossistema suportar.

Com --require-hashes, pip se recusa a instalar qualquer coisa cujo SHA-256 não corresponda o que você gerou no momento do bloqueio. Uma versão comprometida com a mesma string de versão, mas um hash tarball diferente falha na instalação. Par pip-compile --generate-hashes com um Trabalho de CI que regenera o arquivo hash apenas em atualizações de dependência explícitas, nunca de forma simples instalar.

Os usuários de poesia obtêm a mesma rede de segurança por meio do lockfile. A pegadinha é a sintaxe do cursor em pyproject.toml; substitua-o por pinos exatos:

poetry install --sync remove qualquer pacote que não esteja no lockfile, o que interrompe uma dependência perdida de se esconder entre implantações. Para ferramentas de IA do lado npm, use npm ci (não npm install) em cada execução e confirmação de CI package-lock.json.

Verificação 2: isolar credenciais de shells de desenvolvimento

Um shell de desenvolvimento que tem ~/.aws/credentials com uma chave de acesso de longa duração é um carregado arma apontada para sua conta na nuvem e para os dados do cliente. LiteLLM não precisava dessas credenciais para faça o seu trabalho; eles ficaram no disco porque o desenvolvedor uma vez executou aws configure e nunca limpou.

Mova as credenciais do disco. Carregue-os sob demanda, reduza o escopo deles e revogue o persistente camada:

• AWS: aws sso login com duração da sessão limitada entre 8 e 12 horas. Excluir ~/.aws/credentials. Tudo deveria passar ~/.aws/sso cache que expira sozinho.
• GCP: gcloud auth application-default login com --lifetime=43200. Revogar JSONs de contas de serviço de longa duração armazenados em laptops; use a federação de identidade de carga de trabalho do CI.
• Azul: az login com acesso condicional que obriga à AMF; matar tokens de atualização armazenados há mais de 12 horas.
• Chaves de API: mantenha-os em 1Password, Vault ou Doppler. Injetar no início do processo através de op run ou vault read. Nunca os exporte para ~/.zshrc.

Se o TeamPCP tivesse encontrado apenas tokens de sessão STS expirados, o raio da explosão pararia em algumas horas de acesso. O incidente aconteceu porque chaves de longa duração estavam em texto simples no disco, prontas para serem leia.

Verificação 3: verifique cada instalação com um sandbox

Antes de confiar em uma nova biblioteca de IA ou em uma atualização para uma existente, instale-a em algum lugar não pode acessar suas credenciais. Um contêiner Docker descartável com recursos descartados e o isolamento de rede informa se o código do momento da instalação faz algo suspeito:

O padrão de duas etapas é importante. A primeira etapa precisa de acesso à rede para acessar o PyPI, portanto, uma pós-instalação o script ainda pode vazar. Execute a primeira etapa em uma VM limpa, sem segredos e com uma regra de saída de DNS que registra cada nome de host de saída. A segunda etapa é executada com --network=none; se o seu a biblioteca tenta telefonar para casa no momento da importação, a importação falha e você sabe.

Melhor: use um microVM descartável como Firecracker ou orb no macOS para o mesmo forma sem o kernel compartilhado do Docker. Para JavaScript, o modelo de permissão do Deno oferece a opção mesmo isolamento sem contêiner: deno run --allow-net=api.openai.com,api.anthropic.com agent.ts.

Verificação 4: verifique a exposição à violação antes de girar

Se suas chaves estiverem em uma máquina que soltou mal, gire-as. Sem debate. Mas também verifique se as identidades vinculadas a essas chaves já aparecem em dumps conhecidos; um laptop que executou uma versão comprometida do LiteLLM no mês passado pode ser um laptop cujo proprietário reutilizou senhas de um despejo da Coleção 1 de 2019. Ambos os problemas precisam ser corrigidos e a Verificação 4 informa quais contas precisam da atenção mais urgente.

Botoi's /v1/breach/check endpoint envolve as mesmas fontes de dados da maioria dos IAM corporativos as ferramentas pagam por usuário e não custam nada no nível gratuito:

Acompanhe cada e-mail de conta de serviço, cada e-mail de usuário de máquina e cada desenvolvedor humano cujo laptop tocou na janela. Qualquer e-mail com password_exposed: true precisa de uma rotação e um reinicialização forçada do MFA antes de prosseguir. Canalize a saída para seu runbook de resposta a incidentes; um curl por identidade, dez minutos para uma organização de engenharia com 50 pessoas.

Verificação 5: observe sua saída de saída

O malware pós-instalação precisa telefonar para casa de alguma forma. A maioria dos desenvolvedores não consegue se lembrar da última vez eles observaram com o que seu laptop estava realmente falando; essa é a lacuna com a qual o TeamPCP contava.

Em uma máquina suspeita, um único comando informa o que é cada processo Python e Node conectado a:

No nível da frota, empurre todos os laptops de desenvolvedores e executores de CI por meio de uma saída Zero Trust lista de permissões. Cloudflare WARP, Tailscale ACLs e Little Snitch oferecem a mesma forma: liste os nomes de host que você realmente precisa, bloqueie o resto, alerte sobre os blocos.

Uma lista de permissões tão restrita parece difícil na primeira semana. Na segunda semana, os únicos alertas que você vê são real: uma biblioteca tentando chegar a um destino que não deveria alcançar. Isso é exatamente o sinal que o infostealer do TeamPCP teria desarmado na instalação.

As cinco verificações em resumo

Principais conclusões

• Fixe versões exatas, não intervalos. Um sinal de intercalação ou til em seu arquivo de bloqueio é uma promessa que o lançamento de amanhã é seguro. TeamPCP quebrou essa promessa.
• As credenciais da nuvem não pertencem aos shells de desenvolvimento. Sessões de SSO de curta duração transformam-se em credencial roubada em um evento de rotação, não em uma violação.
• O Sandbox é instalado antes de você confiar nele. Docker com letras maiúsculas e --network=none é suficiente para detectar malware no momento da instalação pelo custo de 15 minutos.
• Rodar mais verificação de violação. Se uma máquina tocou em uma liberação incorreta, gire cada identidade que ele viu e executou cada e-mail /v1/breach/check para encontrar aqueles que precisa de redefinições urgentes de MFA.
• As listas de permissões de saída pegam o telefone para casa. Regras de Zero Trust em laptops e CI transformam-se em exfiltração silenciosa em um evento barulhento, registrado e bloqueável.

Botoi oferece endpoints HTTP para verificação de violações, verificação de hash, inspeção SSL, HTTP auditoria de cabeçalho e pesquisa de metadados npm; os primitivos que você precisa para auditar uma cadeia de suprimentos incidente sem instalar mais uma biblioteca. Uma chave de API, 5 req/min no nível gratuito, não instale ganchos. Navegue pelo documentos interativos ou ligue o Servidor MCP em Claude Code ou Cursor para chamar os mesmos endpoints do seu editor enquanto você trabalha no lista de verificação.