LiteLLM: Authenticated command execution via MCP stdio test endpoints

Endpoints de teste/preview de servidores MCP no proxy LiteLLM permitem que qualquer usuário autenticado — inclusive chaves de API de baixo privilégio ('internal-user') — envie uma configuração de transporte stdio completa e faça o proxy spawnar o comando informado como subprocesso no host, com os privilégios do processo do proxy. Não é uma falha de injeção clássica: é uma funcionalidade legítima (spawn de comando MCP via stdio) exposta sem checagem de papel/role nos endpoints de teste, o que transforma um recurso administrativo em execução remota de comando para qualquer conta autenticada. Está no catálogo KEV da CISA com exploração confirmada, tem PoC pública e template Nuclei — o que eleva o risco prático muito além do que uma CVSS 8.7 já sugere.

O LiteLLM Proxy expõe endpoints REST para testar uma configuração de servidor MCP antes de ela ser salva: POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list. Ambos aceitam no corpo da requisição a configuração completa do servidor MCP, incluindo os campos command, args e env usados pelo transporte stdio do protocolo MCP. Quando a configuração enviada usa transporte stdio, o backend tenta estabelecer a conexão executando de fato o comando informado como subprocesso no host onde o proxy roda.

O defeito central é de controle de acesso (CWE-862, Missing Authorization / autorização incorreta): os dois endpoints são protegidos apenas por uma chave de API válida do proxy, sem checagem de papel (role). Isso significa que qualquer chave autenticada — mesmo as de menor privilégio, destinadas a usuários internos sem função administrativa — consegue acionar o mesmo caminho de código que deveria estar restrito a quem tem permissão para cadastrar/gerenciar servidores MCP.

O atacante controla integralmente o binário executado (command), os argumentos (args) e variáveis de ambiente (env) passadas ao subprocesso. Como o objetivo declarado do endpoint é 'testar antes de salvar', não há persistência do servidor MCP malicioso no banco de configuração — mas isso é irrelevante para o impacto, porque a execução acontece de forma síncrona na própria chamada de teste, antes de qualquer decisão de salvar.

O vetor é uma chamada HTTP autenticada ao proxy LiteLLM, atingindo POST /mcp-rest/test/connection ou POST /mcp-rest/test/tools/list com um corpo JSON descrevendo um servidor MCP configurado para transporte stdio, no qual os campos command/args/env apontam para o binário e argumentos que o atacante deseja executar. Não há necessidade de interação do usuário nem de bypass de autenticação — o único pré-requisito real é possuir qualquer chave de API válida do proxy, incluindo chaves de usuário interno de baixo privilégio, o que na prática cobre qualquer conta legítima criada para uso cotidiano da plataforma, não apenas administradores.

O vetor CVSS 4.0 (AV:N/AC:L/AT:P/PR:L/UI:N) reflete exatamente isso: ataque remoto pela rede, complexidade baixa, privilégio baixo necessário (não administrativo), sem interação do usuário, mas com uma condição de ataque presente (AT:P) — a necessidade de a instância ter o recurso MCP/stdio acessível e de o atacante possuir uma chave válida. O resultado final é execução de comando arbitrário com os privilégios do processo do proxy no host — normalmente o suficiente para leitura de segredos/configuração do proxy, acesso à rede interna a partir do host, e movimento lateral, dependendo de como a instância está implantada.

A presença no catálogo KEV da CISA indica exploração confirmada em ambiente real, e a existência de PoC pública e template Nuclei reduz drasticamente a barreira técnica: a falha deixou de exigir pesquisa e passou a ser scanner-friendly, o que tende a acelerar exploração em massa contra instâncias expostas.

A correção definitiva é atualizar o LiteLLM para a versão 1.83.7 ou posterior (release v1.83.7-stable), que fecha o gate de autorização nos endpoints de teste MCP. Instalações do Red Hat OpenShift AI que empacotam o componente afetado foram corrigidas nas erratas RHSA-2026:27784 (RHOAI 3.4.1), RHSA-2026:28960 (RHOAI 2.25.8) e RHSA-2026:30056 (RHOAI 3.3.4).

Se a atualização imediata não for viável, os paliativos reais e seus custos: restringir o acesso de rede aos endpoints /mcp-rest/test/connection e /mcp-rest/test/tools/list (por exemplo, bloqueio de rota em proxy reverso/gateway) até a atualização — custo é perder a funcionalidade de preview de servidores MCP; ou desabilitar por completo o recurso MCP no proxy se ele não estiver em uso. Restringir apenas por role/permissão de chave de API não resolve, porque o próprio defeito é a ausência dessa checagem de role nesses endpoints — qualquer chave válida, independente de privilégio nominal, ainda passa. Rotação de chaves de API não mitiga a vulnerabilidade em si, apenas reduz a superfície de quem já possui uma chave comprometida.

Não funciona como mitigação: confiar apenas em autenticação básica da API como controle suficiente, já que o problema é justamente a falta de autorização granular sobre uma funcionalidade que executa comando no host — a autenticação por si só (qualquer chave válida) é exatamente o que o atacante precisa.

Nos logs de acesso do proxy LiteLLM, procure requisições POST para /mcp-rest/test/connection e /mcp-rest/test/tools/list cujo corpo contenha um objeto de configuração MCP com transporte stdio e campos command/args/env apontando para binários incomuns (shells, interpretadores, ferramentas de rede como curl/wget, ou caminhos fora do padrão de uso), especialmente originadas de chaves de API sem função administrativa ou de IPs fora do padrão de uso interno. Correlacionar essas chamadas com a identidade da chave de API usada (auditoria de uso de API key) ajuda a distinguir teste legítimo de servidor MCP de tentativa de abuso.

Como o mecanismo gera um subprocesso real no host, monitoramento de processos no servidor onde o proxy roda — alertando para processos filhos anômalos do processo do LiteLLM (shells, binários de sistema não relacionados a integrações MCP esperadas) — é um sinal mais confiável do que apenas log HTTP, já que a existência de PoC pública e template Nuclei sugere variações de payload que podem não seguir um padrão único de string na requisição.