CISA inclui no KEV vulnerabilidade do LiteLLM sob exploração ativa (CVE-2026-42271) — gateway de IA vira RCE

A CISA acrescentou nesta segunda-feira (8/6) o CVE-2026-42271 — uma falha crítica de injeção de comando no LiteLLM da BerryAI — ao catálogo de vulnerabilidades exploradas ativamente (KEV). O bug, encadeável com o “BadHost” (CVE-2026-48710) do Starlette, permite a qualquer usuário autenticado executar comandos arbitrários no servidor do gateway de IA. Pesquisadores da Horizon3.ai mostraram que o segundo CVE elimina até o requisito de autenticação. Agências federais americanas têm até 22 de junho para corrigir.

O que aconteceu

O LiteLLM é uma das peças mais difundidas da infraestrutura de IA corporativa: uma biblioteca open-source que oferece interface única (no formato OpenAI) para chamar dezenas de provedores de LLM — Anthropic, Google, Azure, Bedrock, Cohere, Mistral, modelos locais via Ollama, e assim por diante. Pode ser usada como SDK Python embarcado ou como proxy/gateway autônomo. Para empresas, é o ponto de centralização de chaves de API, controle de custos e roteamento de tráfego de IA — exatamente o tipo de alvo que um atacante quer comprometer.

O CVE-2026-42271 foi divulgado em abril de 2026 e classificado como “improper neutralization of special elements used in a command”. O bug está em dois endpoints REST destinados a testar configurações de servidores MCP (Model Context Protocol) antes de salvá-las: POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list. Ambos aceitavam configurações completas no corpo da requisição — incluindo command, args e env usados pelo transport stdio.

O resultado é direto: ao receber uma configuração stdio, o endpoint spawnava o comando especificado como subprocesso, no host do proxy, com os privilégios do processo. A única barreira era a posse de uma chave de API válida do proxy — sem verificação de papel (role). Ou seja, qualquer chave, mesmo de usuário interno de baixo privilégio, virava chave de execução remota.

Detalhes da vulnerabilidade

A reviravolta veio com a publicação da pesquisa do Horizon3.ai. A equipe demonstrou que o pré-requisito de chave válida desaparece se o atacante encadear o CVE-2026-42271 com o CVE-2026-48710, um bypass de autenticação no Starlette — o framework Python leve sobre o qual o LiteLLM constrói seus endpoints HTTP. O CVE-2026-48710 foi apelidado de “BadHost” e permite enganar a camada de autenticação manipulando o header Host da requisição. Combinados, os dois bugs transformam o gateway de IA em RCE não autenticada na internet aberta.

“A exploração bem-sucedida permite executar comandos arbitrários no host do LiteLLM, acessar credenciais de provedores de modelo, roubar chaves de API e segredos armazenados pelo proxy, mover-se lateralmente para infraestrutura de IA conectada e comprometer sistemas downstream integrados ao gateway.”

Horizon3.ai

O patch oficial está na versão 1.83.7 do LiteLLM, que introduz controles de autorização adicionais (somente usuários com role PROXY_ADMIN podem chamar os endpoints de teste) e atualiza a dependência do Starlette. O Starlette corrigiu o BadHost na 1.0.1. A CISA, por sua vez, ordenou às agências federais civis (FCEB) que apliquem a correção até 22 de junho de 2026 sob o BOD 22-01.

Quem é afetado

• Qualquer empresa rodando LiteLLM Proxy como gateway de IA em versão anterior à 1.83.7 — especialmente equipes de plataforma de dados que centralizam chamadas a múltiplos provedores de LLM.
• Stacks de RAG, agentes corporativos e copilotos internos construídos sobre LiteLLM, que tipicamente expõem o proxy a redes internas e, em alguns casos, à internet via API gateway.
• Provedores SaaS que oferecem “model routing” ou “BYOLLM” para clientes finais usando LiteLLM por baixo.
• Ambientes onde o LiteLLM Proxy roda como container Docker com privilégios elevados ou em hosts compartilhados com outros serviços críticos — o RCE escala para a infraestrutura adjacente.
• Aplicações que sincronizam com servidores MCP externos via configuração stdio — o vetor de teste é o mesmo das atualizações legítimas de catálogo.

Análise

O caso LiteLLM marca uma transição importante na superfície de ataque corporativa: gateways de IA são o novo “Microsoft Exchange das integrações” — pontos críticos de centralização onde uma falha vira chave-mestra. Quem comprometer o proxy ganha não apenas o acesso ao host, mas também as chaves de API de OpenAI, Anthropic, Google, Bedrock, Azure OpenAI armazenadas no vault, mais o histórico de prompts (que muitas empresas guardam para auditoria) e a capacidade de redirecionar chamadas para modelos sob controle do atacante — abrindo vetor para prompt injection sistêmico.

É também o segundo incidente sério com o LiteLLM em menos de noventa dias. Em março de 2026, a BerryAI sofreu ataque de cadeia de suprimentos atribuído ao grupo TeamPCP, com publicação de versões maliciosas do pacote no PyPI. Padrão consistente: o ecossistema de tooling de IA está crescendo mais rápido do que sua disciplina de segurança. Bibliotecas com milhões de downloads operam com equipes pequenas, sem programa formal de bug bounty proporcional ao impacto e sem auditoria contínua de dependências.

A combinação CVE-2026-42271 + BadHost também acende um alerta sobre o Starlette/FastAPI como base. Boa parte do ecossistema Python moderno de IA (LiteLLM, Langflow, Flowise, várias APIs de RAG) repousa em Starlette. Uma falha de autenticação base contamina dezenas de produtos simultaneamente. Equipes de segurança precisam tratar o BadHost como evento de cadeia de suprimentos, não como bug isolado de uma lib.

Recomendações práticas

• Atualize imediatamente para LiteLLM 1.83.7+ e confirme que o Starlette está em 1.0.1+ (pip show starlette).
• Se não puder atualizar agora, bloqueie no proxy reverso/WAF os caminhos /mcp-rest/test/connection e /mcp-rest/test/tools/list.
• Rotacione todas as chaves de API armazenadas no LiteLLM Proxy (OpenAI, Anthropic, Bedrock, Azure, etc.) — assuma comprometimento se a versão vulnerável esteve exposta.
• Restrinja o acesso de rede ao proxy: ele não deveria estar acessível pela internet pública. Use VPN, ZTNA ou firewall de aplicação para limitar a segmentos de confiança.
• Verifique logs por chamadas aos endpoints /mcp-rest/test/* nos últimos 60 dias e investigue qualquer chamada de IP externo ou de chaves de baixo privilégio.
• Habilite role-based access control e revogue chaves de API com escopo “internal-user” que tenham acessado endpoints administrativos.
• Inventarie outras ferramentas Python de IA na sua stack que dependem de Starlette e priorize as atualizações.
• Considere isolar o LiteLLM em container com perfil seccomp restrito e usuário não-root, reduzindo o blast radius de qualquer RCE futura.

Fonte: Help Net Security