Alerta Máximo: Como Duas Falhas se Uniram para Transformar o LiteLLM em um Ponto de Invasão Total em IA

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Ambos os endpoints aceitam uma configuração completa de servidor MCP no corpo da requisição JSON, incluindo os campos Cmd, args e env que o transporte stdio utiliza para iniciar processos do servidor . Quando um usuário autenticado chama qualquer um desses endpoints com essa configuração, o LiteLLM pega o valor do Cmd fornecido e o executa como um subprocesso na máquina hospedeira, com as mesmas permissões do sistema operacional do próprio processo do proxy LiteLLM .

Originalmente, a BerriAI divulgou isso como um bug de execução remota de código autenticada — um invasor precisava de uma chave de API válida para alcançar os endpoints, e não havia nenhuma verificação de função para restringir quem poderia chamá-los. Até mesmo um usuário interno com poucos privilégios, munido de qualquer chave de API válida do proxy, poderia executar comandos arbitrários no host . Mas a história não termina aí.

O Desvio "BadHost" do Starlette que Remove a Barreira de Autenticação

A segunda vulnerabilidade é a CVE-2026-48710, apelidada de "BadHost" pelos pesquisadores. Trata-se de uma falha de validação do cabeçalho Host no Starlette, o framework ASGI leve que serve de base para o FastAPI, vLLM e milhares de outras aplicações web em Python — incluindo o LiteLLM . Todas as versões do Starlette da 0.8.3 até a 1.0.0 são afetadas .

A causa raiz é uma discordância de interpretação entre como o Starlette roteia as requisições que chegam e como ele reconstrói a URL para a lógica da aplicação . A camada de roteamento ASGI usa o caminho HTTP bruto da requisição para decidir qual endpoint vai tratá-la. Mas o request.url — a URL que os middlewares e decoradores da aplicação enxergam — é reconstruída concatenando o valor bruto do cabeçalho Host com o caminho da requisição, sem a devida validação .

Ao injetar caracteres delimitadores de autoridade-para-caminho da URI, como ? ou #, no cabeçalho Host, um invasor pode fazer com que o request.url.path pareça completamente diferente do caminho real que foi roteado . O middleware de segurança vê um caminho inofensivo, como /, enquanto o roteador, nos bastidores, encaminha a requisição para o verdadeiro endpoint alvo. Qualquer middleware de autenticação baseado em caminho que confie no request.url.path pode ser contornado com facilidade .

Montando a Cadeia de Ataque: De 8.7 para 10.0

O decorador de autenticação do LiteLLM verifica o request.url.path para determinar se uma requisição precisa de uma chave de API válida. O desvio do BadHost permite que um invasor manipule essa URL de forma que o middleware veja um caminho que não exige autenticação, enquanto o roteador ASGI, ao mesmo tempo, despacha a requisição para um dos endpoints vulneráveis de injeção de comandos do MCP .

Isso remove a única barreira de controle de acesso que existia entre a internet e a execução arbitrária de comandos. Um invasor sem nenhuma credencial e sem acesso prévio à rede pode enviar uma única requisição HTTP manipulada que contorna totalmente a autenticação e executa comandos no sistema operacional do servidor que hospeda o proxy LiteLLM . A Horizon3.ai confirmou que a cadeia completa funciona e atribuiu a ela uma pontuação CVSS combinada de 10.0 — a gravidade máxima — porque atinge a execução remota de código sem autenticação .

O Que os Invasores Podem Fazer com Esse Acesso

Uma exploração bem-sucedida concede ao invasor a execução de comandos com os privilégios do processo do proxy LiteLLM. A partir daí, a superfície de ameaça se expande rapidamente:

• Execução arbitrária de comandos: Os invasores podem instalar backdoors, malware, mineradores de criptomoedas ou qualquer outro software que as permissões do processo hospedeiro permitirem .
• Roubo de credenciais em escala: O proxy LiteLLM fica entre as aplicações e dezenas de provedores de LLM. Ele armazena chaves de API para serviços como OpenAI, Anthropic, Azure, AWS Bedrock, Google e outros em seu banco de dados ou variáveis de ambiente . Explorar essa vulnerabilidade permite que os invasores exfiltrem todas as credenciais armazenadas em uma única operação.
• Movimentação lateral pela infraestrutura de IA: Com as chaves de API de nuvem roubadas e acesso shell ao host do proxy, os invasores podem pivotar para serviços conectados, servidores MCP internos, bancos de dados vetoriais e frameworks de agentes downstream .
• Implicações mais amplas para o ecossistema: A falha BadHost do Starlette afeta mais de 400.000 projetos dependentes, incluindo aplicações FastAPI, servidores vLLM, implantações de servidores MCP e frameworks de agentes de IA. Qualquer um desses que utilize middleware de autenticação baseado em caminho em versões do Starlette anteriores à 1.0.1 está similarmente exposto ao desvio de autenticação .

Por que a Ação da CISA Torna Tudo Mais Urgente

A adição da CVE-2026-42271 ao catálogo KEV pela CISA, em 8 de junho de 2026, confirma que a vulnerabilidade não é teórica — criminosos já estão armando ataques com ela neste exato momento . Sob a Diretriz Operacional Vinculativa 22-01, todas as agências civis do poder executivo federal dos EUA devem corrigir as vulnerabilidades listadas no KEV dentro de um prazo de remediação definido. A CISA também recomenda fortemente que todas as organizações, públicas e privadas, tratem as adições ao KEV como prioridades emergenciais de correção .

Passos Imediatos para a Correção

A correção para a exploração combinada exige atualizações em duas frentes, além de várias medidas de defesa em profundidade para lidar com a exposição de credenciais:

1. Atualize o LiteLLM para a versão 1.83.7 ou posterior. Esta versão remove a capacidade dos endpoints de teste do MCP de executar diretamente comandos fornecidos pelo usuário, fechando completamente o vetor de injeção de comandos .
2. Atualize o Starlette para a versão 1.0.1 ou posterior. A correção valida os cabeçalhos Host recebidos em relação à especificação de URL e ignora cabeçalhos que contenham caracteres inválidos, impedindo o truque de confusão de caminho que viabiliza o desvio de autenticação .
3. Faça a rotação de todas as credenciais armazenadas imediatamente. Presuma que qualquer chave de API, token de acesso ou credencial de banco de dados que o proxy LiteLLM já tenha armazenado foi comprometida. Rode todas as chaves da OpenAI, Anthropic, Azure, AWS e outros provedores, e verifique os painéis de faturamento em busca de uso não autorizado .
4. Bloqueie os endpoints no proxy reverso ou WAF. Como uma medida de defesa em profundidade enquanto as correções são implementadas, configure seu proxy reverso ou firewall de aplicação web (WAF) para descartar qualquer requisição para

   POST /mcp-rest/test/connection

   e

   POST /mcp-rest/test/tools/list

   antes que cheguem à aplicação .
5. Faça uma auditoria retrospectiva de acessos não autorizados. Verifique os logs do proxy LiteLLM em busca de atividades incomuns nos endpoints de teste do MCP, particularmente requisições vindas de endereços IP inesperados ou aquelas com cabeçalhos Host manipulados .

A severidade combinada CVSS 10.0, a exploração ativa em ambientes reais e a designação KEV da CISA significam que as organizações que executam serviços baseados em LiteLLM ou Starlette devem tratar este evento como uma emergência para correção e rotação de credenciais. A janela entre a exploração ativa e a exfiltração de credenciais já está aberta.