📍 Visão Geral do Relatório

[!IMPORTANT] Este relatório foi intencionalmente sanitizado para publicação pública no GitHub. Identificadores sensíveis, credenciais, valores de infraestrutura e evidências específicas de clientes foram substituídos por espaços reservados claros.

🧭 Navegação Rápida

• Resumo Executivo
• Análise Técnica
• Impacto
• Remediação
• Lições Aprendidas e Estratégia de Mitigação

[!TIP] Para uma revisão rápida, comece pelas seções Resumo Executivo e Impacto. Para profundidade técnica, continue com Análise Técnica e Remediação.

🏷️ Título

CVE-2026-42271 - Injeção de Comandos RCE no LiteLLM AI Gateway MCP

🧾 Resumo Executivo

Foi descoberta uma vulnerabilidade crítica no gateway LiteLLM AI Gateway que permite a um atacante autenticado executar comandos arbitrários no servidor que o hospeda. A vulnerabilidade explora os endpoints de teste do Model Context Protocol (MCP), que aceitam uma configuração completa de servidor MCP enviada pelo atacante, incluindo os campos command, args e env, sem qualquer sanitização ou validação de segurança.

🔬 Análise Técnica

A vulnerabilidade foi avaliada sob as perspectivas de segurança de aplicações e de risco de infraestrutura. O problema central é classificado como RCE e foi documentado de forma sanitizada, adequada para publicação pública em portfólio.

📊 Impacto

• Execução não autorizada de comandos no contexto da aplicação afetada.
• Potencial assunção de controle do serviço, exposição de dados e movimento lateral, dependendo dos privilégios da implantação.

🛠️ Remediação

• Atualização imediata: atualizar o LiteLLM para a versão 1.83.7 ou posterior
• Restrição de acesso: aplicar regras de firewall para restringir o acesso aos endpoints MCP
• Auditoria de chaves: revisar as permissões das chaves de API e reduzi-las ao mínimo necessário
• Monitoramento de logs: ativar o registro e o monitoramento para detectar quaisquer tentativas de exploração

pip install --upgrade litellm

🧠 Lições Aprendidas e Estratégia de Mitigação

• Trate cada fronteira de integração como não confiável, especialmente quando a lógica da aplicação encaminha valores controlados pelo usuário para sistemas de arquivos, shells, parsers ou ferramentas externas.
• As revisões de segurança devem validar toda a cadeia de exploração, não apenas o primeiro endpoint vulnerável; configurações incorretas de baixa severidade podem se tornar críticas quando encadeadas.
• A documentação pública deve descrever risco, causa raiz e remediação sem expor identificadores operacionais, credenciais ou artefatos de exploração reutilizáveis.
• Os controles defensivos devem combinar validação preventiva, privilégio mínimo em tempo de execução, telemetria e governança de patches para reduzir tanto a explorabilidade quanto o raio de impacto.

🧼 Notas de Sanitização da Publicação

• Identificadores sensíveis de infraestrutura, endereços IP, nomes de host, credenciais, hashes e endereços de e-mail foram substituídos por espaços reservados explícitos.
• Evidências operacionais reutilizáveis foram minimizadas ou abstraídas para manter o documento adequado à publicação pública no GitHub.
• O documento utiliza uma estrutura em estilo consultivo, alinhada às práticas comuns de relatórios de testes de segurança web, como as expectativas de relatório do OWASP WSTG.