Estado da Segurança do MCP: Q1 2026

Passamos o primeiro trimestre de 2026 auditando servidores MCP. Escaneamos 19 repositórios populares, fizemos revisões manuais profundas em 6 e registramos avisos de segurança contra 3 deles. Isso é o que encontramos — e o que isso nos diz sobre como a segurança do MCP falha.

A versão curta: servidores MCP estão sendo construídos por desenvolvedores que entendem bancos de dados e APIs, mas que não modelaram o que acontece quando um agente de IA se conecta ao seu servidor e envia entradas inesperadas. O resultado é uma classe de vulnerabilidades que é notavelmente consistente entre os códigos.

O que auditamos

Executamos um scanner de análise estática contra 19 servidores MCP classificados por estrelas do GitHub e instalações do registro MCP. O escaneamento cobriu padrões de injeção SQL, injeção de shell, SSRF, credenciais codificadas e travessia de caminho. Limite de pontuação para revisão profunda: 50/100. Para triagem imediata: 70/100 com descobertas críticas.

A taxa de falsos positivos foi significativa. Muitas detecções do scanner em repositórios de alta estrela acabaram sendo credenciais codificadas em fixtures de teste, não vulnerabilidades de produção. Mas três servidores tinham vulnerabilidades reais e exploráveis em seu código em tempo de execução.

Taxonomia de Ataques

As vulnerabilidades que encontramos se agrupam em quatro classes. Cada classe tem uma causa raiz diferente, mas compartilham um padrão subjacente: o desenvolvedor confiou na forma da entrada.

1. Injeção SQL via Bypass de Prefixo

O padrão mais comum entre os servidores de banco de dados MCP: o código verifica se uma consulta começa com uma palavra-chave segura antes de executá-la.

# executeautomation/mcp-database-server
if not query.strip().upper().startswith("SELECT"):
    raise SecurityError("Apenas consultas SELECT são permitidas")

connection.execute(query)  # Executa de qualquer maneira

A verificação falha porque:

• Encadeamento de ponto e vírgula: SELECT 1; DROP TABLE users; passa na verificação de prefixo e executa ambas as instruções se o driver MySQL tiver multipleStatements: true
• Procedimentos armazenados: pg_terminate_backend(pid) não começa com SELECT, mas causa danos reais
• Consultas de múltiplas instruções: O driver pg permite instruções separadas por ponto e vírgula; a verificação de prefixo vê apenas a primeira

Registramos GHSA-2gc7-7mj4-79wg (CVSS 8.8) contra o adaptador MySQL, que tinha multipleStatements: true codificado, e três avisos separados cobrindo variantes do mesmo padrão na mesma base de código. CVE-2025-59333 (CVSS 8.1 ALTA, variante PostgreSQL) foi publicado em setembro de 2025 por outro pesquisador e permanece sem correção até o momento em que escrevemos.

A correção não é uma verificação de prefixo melhor. Use consultas parametrizadas e imponha permissões de leitura apenas no nível do banco de dados, não no código do aplicativo.

2. Bypass de Regex via Comentários SQL

Uma variante mais sutil que encontramos em ClickHouse/mcp-clickhouse (CVSS 8.1 ALTA):

# O regex protegendo contra DROP/TRUNCATE
destructive_pattern = r"\b(DROP\s+(\S+\s+)*(TABLE|DATABASE|VIEW|DICTIONARY)|TRUNCATE\s+TABLE)\b"

# Isso passa na verificação — ClickHouse executa como DROP TABLE
"DROP/**/TABLE my_db.my_table"

O regex requer \s+ (espaço em branco) entre palavras-chave SQL. ClickHouse e a maioria dos bancos de dados SQL permitem comentários estilo C (/* */) entre quaisquer tokens. O regex vê DROP/**/TABLE como dois tokens separados sem espaço entre eles — sem correspondência. O banco de dados vê como DROP TABLE.

O mesmo bypass funciona com:

DROP/*comentário*/DATABASE my_db
TRUNCATE/* */TABLE my_db.my_table
DROP-- comentário\nTABLE my_db.my_table

Esse regex específico foi adicionado em fevereiro de 2026 após um agente de IA acidentalmente excluir uma tabela de análises de produção. A correção derrotou o padrão de exploração anterior, mas introduziu este. Filtragem SQL baseada em regex não é um controle de segurança — é uma verificação de segurança que é fundamentalmente incapaz de lidar com toda a sintaxe SQL válida.

Correção: Normalize a entrada primeiro (remova todas as variantes de comentários), depois aplique o regex. Melhor: use um parser SQL adequado para classificar o tipo de consulta.

3. SSRF em Servidores Proxy e de Integração

A análise da BlueRock de 7.000 servidores MCP encontrou 36,7% vulneráveis a SSRF (Server-Side Request Forgery). Encontramos isso independentemente em sooperset/mcp-atlassian:

# Buscando icon_url diretamente do parâmetro da ferramenta MCP
response = requests.get(params["icon_url"])  # Sem validação

Um parâmetro da ferramenta MCP flui diretamente para uma solicitação HTTP do lado do servidor. O atacante (neste contexto: o agente de IA recebendo um prompt malicioso) passa uma URL interna — http://169.254.169.254/latest/meta-data/ (metadados da AWS), http://internal-service:8080/admin, ou http://localhost.