Servidores MCP são a nova superfície de ataque
O Model Context Protocol agora tem um banco de dados de segurança. Ele tem 50 entradas.1
Trinta CVEs foram registradas em 60 dias. Entre 2.614 implementações MCP analisadas, 82% tinham vulnerabilidades em operações de arquivos propensas a path traversal. Entre 38% e 41% dos servidores não tinham autenticação alguma.2 A ferramenta oficial MCP Inspector – aquela que os desenvolvedores usam para depurar servidores MCP – tinha uma vulnerabilidade de RCE. O pacote amplamente usado mcp-remote tinha um bug de injeção de comando de OS.1
Esta não é uma superfície de ataque teórica. São CVEs reais em pacotes reais que desenvolvedores reais estão conectando ao Claude Code, Codex CLI e Cursor agora mesmo. Este post estende o território de segurança de agentes com análise de ameaças no nível do protocolo.
TL;DR
Servidores MCP são a superfície de integração que mais cresce no ecossistema de agentes. Também são a menos auditada. O banco de dados de vulnerabilidades tem 50 entradas: 13 Críticas, 32 Altas. Falhas de validação de entrada e prompt injection respondem por 30 das 50. Três vulnerabilidades de SSRF em três servidores MCP diferentes apareceram em um único dia nesta semana.3 O padrão é claro: a comunidade está publicando servidores MCP mais rápido do que está revisando eles.
Principais conclusões
- Usuários de Claude Code: Cada servidor MCP que você conecta é um limite de confiança que você está estendendo. Execute
claude mcp listagora mesmo e audite o que você tem conectado. Se você está rodando servidores MCP da comunidade que instalou meses atrás, verifique se foram corrigidos desde então. - Construtores de harness: Seus hooks PreToolUse são sua última linha de defesa antes que uma chamada de ferramenta MCP chegue a um servidor não auditado. Considere hooks que validem as entradas de ferramentas MCP antes da execução, especialmente para servidores que aceitam URLs, caminhos de arquivo ou comandos shell.
- Autores de servidores MCP: A especificação MCP diz que “DEVERIA sempre haver um humano no loop”. Trate isso como DEVE. Valide todas as entradas. Nunca passe strings controladas pelo usuário para comandos shell via interpolação de string. Nunca confie em valores
$refem especificações OpenAPI sem validação de URL.
Os números
O Vulnerable MCP Project mantém um banco de dados de problemas de segurança documentados em MCP.1 O estado atual:
| Categoria | Quantidade |
|---|---|
| Validação de entrada (injeção, traversal) | 17 |
| Prompt injection / envenenamento de ferramentas | 13 |
| RCE / injeção de comando | 12 |
| Roubo de credenciais | 8 |
| DNS rebinding | 6 |
| Falhas de autenticação | 5 |
| SSRF | 4 |
Severidade: 13 Críticas, 32 Altas, 5 Médias.1 Trinta e dois pesquisadores de segurança contribuíram com achados. Os servidores afetados incluem o próprio servidor Git MCP da Anthropic, o MCP Inspector oficial, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes e mais de 20 servidores construídos pela comunidade.1
O resultado do levantamento é o mais condenatório: 82% de 2.614 implementações MCP tinham vulnerabilidades em operações de arquivos propensas a path traversal.2 Quatro em cada cinco servidores MCP permitirão que um atacante leia arquivos aos quais não deveria ter acesso.
Cinco padrões de ataque
A onda de CVEs de 60 dias revelou cinco padrões recorrentes:2
1. Envenenamento de ferramentas. Instruções maliciosas embutidas em descrições de ferramentas MCP. O agente lê a descrição, confia nela e segue as instruções ocultas usando suas próprias ferramentas autorizadas. A ferramenta envenenada nunca é executada — as ferramentas legítimas do agente executam o ataque. Cobrimos esse padrão no paradoxo implantar-e-defender: a confiança é transitiva, a auditoria não é.
2. Prompt injection via dados externos. Servidores MCP que buscam conteúdo de issues do GitHub, mensagens do Slack, emails ou páginas da web trazem texto controlado pelo atacante para o contexto do agente. A injeção não mira o servidor MCP – ela mira o agente que lê a saída do servidor. A superfície de ataque de egress silencioso é o caso geral; servidores MCP são o vetor mais comum.
3. Bypass de confiança após aprovação inicial. O Claude Code pede sua aprovação para um servidor MCP na primeira vez. Depois disso, as definições de ferramentas podem mudar entre sessões sem nova solicitação em todos os casos. Um servidor que era seguro no momento da instalação pode se comportar de forma diferente no momento da atualização. A lacuna de revalidação é estrutural: o protocolo não exige assinatura criptográfica das descrições de ferramentas.2
4. Comprometimento da supply chain. Servidores MCP com backdoor publicados em registries, incluindo pacotes que se passam por servidores legítimos. O mesmo padrão de supply chain que documentamos em a supply chain é a superfície de ataque, aplicado ao ecossistema MCP.
5. Exposição entre tenants. Ambientes de hospedagem compartilhada onde múltiplos servidores MCP podem interceptar chamadas de função uns dos outros antes da execução.4 Limites de isolamento que parecem sólidos de fora se quebram quando múltiplos servidores compartilham um processo ou container.
O padrão SSRF
Três vulnerabilidades de SSRF em três servidores MCP diferentes apareceram em uma única varredura nesta semana:3
- n8n-mcp: SSRF autenticado via injeção de host de instância
- mcp-from-openapi: SSRF via valores
$refem especificações OpenAPI. Uma spec maliciosa com URLs internas faz o servidor buscar esses recursos durante a inicialização - stata-mcp: Validação insuficiente de URLs fornecidas pelo usuário
SSRF em servidores MCP é particularmente perigoso porque o servidor geralmente tem acesso de rede que o agente não tem. Veja como uma única spec OpenAPI maliciosa se transforma em roubo de credenciais:
Passo 1. Um atacante publica um servidor MCP de aparência legítima que envolve uma API externa. O servidor usa mcp-from-openapi para gerar ferramentas a partir de uma especificação OpenAPI.
Passo 2. A spec OpenAPI contém um $ref apontando para um endereço interno:
components:
schemas:
Config:
$ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"
Passo 3. Durante initialize(), o servidor MCP resolve o $ref buscando a URL. O servidor roda na sua infraestrutura: dentro da sua VPC, no seu laptop, no seu container de CI. A requisição vai para o endpoint de metadados da AWS a partir de uma fonte confiável.
Passo 4. O endpoint de metadados retorna credenciais IAM temporárias: access key, secret key, session token.
Passo 5. O servidor agora tem suas credenciais de nuvem. Ele pode exfiltrá-las em respostas de ferramentas, registrá-las em um endpoint externo ou usá-las diretamente.
O agente nunca fez nada malicioso. O usuário aprovou o servidor MCP. A spec OpenAPI parecia normal. A resolução do $ref aconteceu no nível da biblioteca, abaixo de onde qualquer um revisa. O SSRF converteu a posição de rede do servidor MCP na posição de rede do atacante.
A Microsoft corrigiu uma SSRF crítica em Azure MCP (CVE-2026-26118) em março de 2026. O mesmo padrão se aplicou ao Azure: uma vulnerabilidade de elevação de privilégio de alta severidade que poderia roubar tokens de autenticação e conceder acesso não autorizado a recursos do Azure.5
O que fazer
Audite seus servidores conectados. Execute claude mcp list e revise cada servidor. Verifique cada um contra o banco de dados do Vulnerable MCP Project.1 Remova servidores que você não está usando ativamente.
Fixe as versões dos servidores. Se você instala servidores MCP via npm ou pip, fixe a versão. Não use auto-update. Revise os changelogs antes de atualizar. O padrão de bypass de confiança significa que uma atualização pode mudar as definições de ferramentas sem nova aprovação.
Adicione hooks de validação de entrada. Um hook PreToolUse em chamadas de ferramentas MCP pode validar entradas antes que cheguem ao servidor:
#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')
# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
echo "Blocked: MCP tool input contains internal/metadata address" >&2
exit 2
fi
fi
exit 0
Considere isolamento de transporte. Os padrões de defesa em tempo de execução para agentes ampliados por ferramentas se aplicam diretamente aqui: cada servidor MCP é uma ferramenta que o agente invoca, e a arquitetura de defesa precisa considerar ferramentas comprometidas. Servidores MCP HTTP rodam em seu próprio processo com limites de rede explícitos. Servidores stdio compartilham o contexto de processo do agente. Nenhum transporte é inerentemente seguro. O fator maior é se o servidor tem acesso a credenciais, redes internas ou caminhos de arquivo sensíveis. Escolha o transporte que oferece os limites de isolamento que seu modelo de ameaças exige.
Acompanhe o banco de dados. O Vulnerable MCP Project em vulnerablemcp.info é a coisa mais próxima de um rastreador de CVEs para o ecossistema MCP. Consulte antes de instalar novos servidores.
O ecossistema MCP cresce rápido: mais de 3.000 servidores indexados e 100 milhões de downloads mensais.6 A postura de segurança não está crescendo junto. Cinquenta vulnerabilidades em um banco de dados que não existia um ano atrás. O protocolo não é o problema. As implementações são. E como documentei em seu agente tem um intermediário, cada intermediário na cadeia de ferramentas do agente é uma oportunidade de interceptação que a maioria dos desenvolvedores nunca audita.
Fontes
Perguntas frequentes
Os servidores MCP que vêm com o Claude Code são afetados?
As vulnerabilidades afetam principalmente servidores MCP construídos pela comunidade e por terceiros, não a infraestrutura MCP central do Claude Code. Contudo, a ferramenta oficial MCP Inspector teve uma vulnerabilidade de RCE, então “oficial” não significa “imune”.
Devo parar de usar servidores MCP?
Não. O MCP é uma camada de integração poderosa. Mas trate cada servidor MCP como um limite de confiança. Audite o que você tem conectado, fixe versões e adicione hooks de validação de entrada para servidores que aceitam URLs, caminhos de arquivo ou comandos shell.
Como verifico se meus servidores MCP são vulneráveis?
Execute claude mcp list para ver seus servidores conectados. Faça referência cruzada de cada um com o banco de dados do Vulnerable MCP Project. Verifique o repositório GitHub do servidor em busca de avisos de segurança recentes.
-
The Vulnerable MCP Project. Banco de dados completo de segurança MCP. 50 vulnerabilidades documentadas, 13 críticas, 32 pesquisadores contribuintes. Cobre Anthropic, GitHub, Microsoft, Docker, Kubernetes e mais de 20 servidores da comunidade. ↩↩↩↩↩↩
-
MCP Security 2026: 30 CVEs in 60 Days. Março de 2026. Mais de 30 CVEs em janeiro-fevereiro de 2026. 82% de 2.614 implementações tinham path traversal. 38-41% não tinham autenticação. Injeção de exec/shell: 43% de todas as vulnerabilidades reportadas. ↩↩↩↩
-
GitHub Security Advisories, 8 de abril de 2026: GHSA-4ggg-h7ph-26qr (n8n-mcp SSRF), GHSA-v6ph-xcq9-qxxj (mcp-from-openapi SSRF), GHSA-jpcj-7wfg-mqxv (stata-mcp validação). ↩↩
-
MCP and Its Critical Vulnerabilities. Strobes, 2026. Cenários de ataque incluindo injeção por WhatsApp, ofuscação Unicode, interferência entre servidores e recomendações práticas de defesa. ↩
-
Microsoft Patches Critical Azure MCP SSRF (CVE-2026-26118). Março de 2026. Elevação de privilégio de alta severidade via SSRF em Azure MCP Server Tools. ↩
-
Ecossistema MCP. Mais de 3.000 servidores indexados, mais de 100M de downloads mensais em março de 2026. ↩