Injeção de comandos no MCP do LiteLLM: CVE-2026-42271

GTIG confirma exploração da CVE-2026-42271: chaves LiteLLM válidas podiam executar comandos nas prévias MCP. Atualize para 1.83.7+.^{[1], [6], [8]}

Vetor CVSS

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N^[1]

💡 Explicação em Linguagem Simples (ELI5)

Uma oficina deixa visitantes testar uma ferramenta antes de cadastrá-la. O balcão de testes pode ligar uma máquina potente da oficina, então só um supervisor deveria entregar instruções a ela. Nas versões vulneráveis do LiteLLM, qualquer crachá aceito chegava a esse balcão. Uma falha distinta do Starlette também podia confundir um guarda que decide o acesso por uma URL reconstruída; cada limite exige sua própria correção. Em outro balcão, um visitante pode escrever uma barra ou um ponto de interrogação na etiqueta de uma encomenda. O funcionário cola esse texto ao reconstruir o endereço e o interpreta como uma nova rota, embora a encomenda continue pelo corredor original. Essa é a confusão separada entre Host e caminho no Starlette.^{[1], [3], [5]}

Conceitos Centrais e Termos

Model Context Protocol (MCP): Protocolo usado por aplicações, como gateways de IA, para se conectar a ferramentas e fontes de dados externas. Os endpoints de pré-visualização do LiteLLM testam uma configuração MCP antes de salvá-la.^[1]
Transporte stdio: Modo de conexão MCP que inicia um processo filho local e troca mensagens pela entrada e saída padrão. O processo roda no host do proxy LiteLLM com os privilégios do serviço.^{[1], [2]}
Autorização baseada em função: Verificação no servidor que permite uma operação apenas a uma identidade com a função exigida. A CVE-2026-42271 deixou as rotas de pré-visualização sem a verificação PROXY_ADMIN usada pela operação de salvamento.^{[1], [2]}
CVE-2026-48710 (Starlette BadHost): Falha separada do Starlette: um cabeçalho Host inválido podia fazer request.url.path divergir do caminho usado pelo roteamento. A Horizon3 relatou que isso poderia contornar a autenticação por caminho do LiteLLM em certas combinações; não faz parte da CVE-2026-42271.^{[3], [5], [4]}
Lista de comandos permitidos no stdio do MCP: Conjunto de nomes-base de executáveis aceitos pelo LiteLLM no transporte stdio. A verificação ocorre na validação da configuração e novamente antes da criação do cliente para registros antigos. Não é um sandbox, pois runtimes permitidos podem interpretar os argumentos recebidos.^[8]

Mapeamentos de frameworks

Referência CWE para a fraqueza descrita neste guia: CWE-78
CISA KEV — adicionado em 2026-06-08 — CVE-2026-42271

Fluxo de Ataque Passo a Paso

Passo 1

Confirme a versão e a exposição das rotas

O advisory do mantenedor afeta LiteLLM >=1.74.2 e <1.83.7 e exige uma chave de API válida do proxy; antes da correção, qualquer titular autenticado, inclusive com chave de usuário interno de baixo privilégio, podia acessar as rotas de pré-visualização. O GTIG inclui CVE-2026-42271 na lista de exploração confirmada; para os pré-requisitos deste CVE, siga o modelo autenticado descrito no advisory do mantenedor.^{[1], [6]}

Passo 2

Uma chave de menor privilégio alcança uma ação administrativa de pré-visualização

Os endpoints aceitavam uma configuração MCP completa, incluindo comando stdio, argumentos e variáveis de ambiente. O servidor autenticava a chave, mas não verificava a função PROXY_ADMIN; qualquer titular autenticado podia chamar a pré-visualização.^[1]

Passo 3

A pré-visualização inicia um processo no host do proxy

Para testar a configuração stdio enviada, o LiteLLM criava um cliente MCP e iniciava o processo filho configurado com os privilégios do serviço proxy. Isso é execução de comandos no host do gateway, não apenas uma resposta insegura gerada pelo modelo de IA.^{[2], [8]}

Passo 4

Uma falha independente do Starlette pode enfraquecer a autenticação

A Horizon3 relatou que a CVE-2026-48710 podia fazer a autenticação baseada em caminho enxergar um request.url.path diferente da rota selecionada pelo Starlette quando havia uma versão afetada. Os pesquisadores relataram o encadeamento com a CVE-2026-42271 para remover a exigência da chave de API em implantações afetadas. Atribua essa cadeia aos pesquisadores; as CVEs têm causas e correções distintas.^{[5], [3], [4]}

Passo 5

Corrija os dois limites e confira os pacotes resolvidos

O LiteLLM corrigiu as rotas de pré-visualização na versão 1.83.7: agora exigem PROXY_ADMIN e tools/list tem autenticação explícita. O patch também valida a lista de comandos permitidos em solicitações de criação/atualização e novamente em _create_mcp_client para detectar configurações antigas. A lista não é um sandbox; runtimes permitidos ainda interpretam argumentos. O Starlette corrigiu separadamente o CVE-2026-48710 na versão 1.0.1; verifique as versões resolvidas e avalie a cadeia relatada de forma independente.^{[1], [8], [4], [7]}

Passo 6

Contexto de campanha recente (relatado em 7 de outubro de 2026)

A Black Lotus Labs informou que uma amostra do malware PoeLLM provavelmente visava /mcp-rest/test/connection; o BleepingComputer também relatou tentativas de explorar CVE-2026-42271 na campanha. O relato não demonstra que todos os hosts infectados foram comprometidos por este CVE nem que todo alvo LiteLLM era vulnerável. Trate isso como evidência de direcionamento atual, não como contagem de vítimas atribuível a esta falha.^{[9], [10]}

Análise de Causa Raiz

A falha no LiteLLM era a ausência de verificação de função nas duas rotas de pré-visualização MCP: qualquer chave de API válida do proxy podia acioná-las sem a função PROXY_ADMIN. A pré-visualização da conexão aceitava uma configuração stdio fornecida pelo solicitante e iniciava o comando com os privilégios do processo do proxy. Uma falha separada no Starlette permitia que um cabeçalho Host malformado fizesse request.url.path diferir do caminho roteado pelo Starlette; a Horizon3 relatou que a validação de chave baseada no caminho podia ser contornada ao encadear esse comportamento com o LiteLLM. São vulnerabilidades distintas: corrija os limites de autorização e execução de comandos do LiteLLM e atualize o Starlette para 1.0.1 ou posterior.^{[1], [8], [3], [4], [5]}

Código-Fonte: Vulnerável vs. Seguro

Este trecho acompanha o patch mesclado do LiteLLM no limite de execução: verifica o nome-base do comando antes de construir o cliente stdio, fazendo com que registros legados de banco/configuração também passem pela validação. O patch também valida solicitações de criação e atualização de servidores e restringe os dois endpoints de pré-visualização a PROXY_ADMIN; /test/tools/list também recebeu a dependência explícita user_api_key_auth. A lista permitida não é um sandbox: runtimes permitidos ainda podem interpretar seus argumentos. Mantenha a pré-visualização restrita a administradores e execute o proxy com privilégios mínimos.^{[1], [2], [8]}

Trecho de origem: Trecho de validação do cliente stdio LiteLLM

IMPLEMENTAÇÃO VULNERÁVEL

# _create_mcp_client antes da inclusão da proteção contra comandos stdio.
if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

PATCH SEGURO E ROBUSTO

# _create_mcp_client: valide novamente registros antigos do banco de dados/configuração.
if server.command:
    base_command = os.path.basename(server.command)
    if base_command not in MCP_STDIO_ALLOWED_COMMANDS:
        raise HTTPException(
            status_code=403,
            detail="MCP stdio command is not in the allowlist",
        )

if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

Lista de Verificação de Segurança para Engenharia

✓Inventarie as implantações do proxy LiteLLM e confirme a versão efetivamente resolvida; atualize versões afetadas para 1.83.7 ou posterior.^{[1], [8]}
✓Inspecione o lockfile ou a imagem implantada e confirme Starlette 1.0.1 ou posterior quando a versão resolvida do FastAPI permitir; não aplique uma substituição de dependência sem testes.^{[3], [7]}
✓Até atualizar o LiteLLM, bloqueie POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list no proxy reverso ou gateway de API, conforme o aviso do mantenedor.^[1]
✓Verifique que as duas rotas exigem user_api_key_auth e rejeitam qualquer função diferente de PROXY_ADMIN antes de criar um cliente MCP.^{[1], [8]}
✓Adicione testes provando que uma requisição sem autenticação e uma chave válida sem função administrativa não alcançam nenhuma das operações de pré-visualização, enquanto uma pessoa administradora autorizada consegue usar o fluxo suportado.^[8]
✓Para a falha do Starlette, teste o tratamento de Host malformado e garanta que o middleware de acesso use o caminho ASGI canônico ou uma URL validada pelo framework.^{[3], [4]}
✓Revise logs do proxy e telemetria de processos filhos para encontrar uso inesperado das rotas MCP de pré-visualização; troque credenciais armazenadas no proxy se a investigação apontar possível acesso ao host.^{[1], [8]}
✓Mantenha os registros das duas vulnerabilidades separados: CVE-2026-42271 é execução de comandos no LiteLLM; CVE-2026-48710 é análise de Host e confusão de caminho no Starlette.^{[1], [3]}
✓Revise LITELLM_MCP_STDIO_EXTRA_COMMANDS em cada ambiente; entradas personalizadas ampliam a fronteira de confiança dos executáveis e não tornam seguro o tratamento dos argumentos.^[8]

Fontes

← AI Security Directory →