A Crise de Segurança do MCP: O Que Encontramos Caçando Vulnerabilidades Através do Ecossistema

Por Akav Labs | Pesquisa AgentSentry

O Protocolo de Contexto de Modelo está se tornando silenciosamente o sistema nervoso da IA empresarial. Em questão de meses, cada grande empresa de infraestrutura lançou um servidor MCP — Microsoft, MongoDB, Auth0, Cloudflare, ClickHouse, Upstash. As empresas estão conectando esses servidores aos seus agentes LLM e apontando-os para bancos de dados de produção, pipelines de CI/CD e sistemas de autenticação.

Ninguém os auditou primeiro.

Passamos vários dias realizando uma pesquisa de segurança sistemática no ecossistema MCP. O que encontramos não foi uma coleção de bugs isolados. Foram as mesmas classes de vulnerabilidade, reproduzidas de fornecedor para fornecedor, sugerindo que o ecossistema foi lançado rapidamente e o pensamento de segurança veio depois. Este post documenta os padrões de ataque que identificamos, a metodologia que usamos e o que acreditamos que precisa mudar.

Não estamos nomeando fornecedores específicos ou números CVE neste post. Janelas de divulgação coordenada estão ativas. Quando essas janelas fecharem, os avisos técnicos completos serão publicados. O que podemos compartilhar agora é a metodologia e as classes de vulnerabilidade — que acreditamos estar presentes em muito mais servidores MCP do que os que examinamos.

Contexto: O Que É Realmente o MCP

Para leitores que não trabalharam diretamente com isso: o Protocolo de Contexto de Modelo é uma especificação da Anthropic que padroniza como os agentes LLM se comunicam com ferramentas externas e fontes de dados. Um servidor MCP expõe um conjunto de "ferramentas" — funções que o agente pode chamar para ler dados, escrever dados ou acionar ações. O agente decide quais ferramentas chamar com base no que está tentando realizar.

O modelo de segurança é implícito. O agente confia nas ferramentas. As ferramentas confiam no agente. Os dados que essas ferramentas retornam fluem diretamente para a janela de contexto do agente, onde influenciam decisões futuras. Não há sandbox. Não há camada de validação obrigatória. Há um conjunto fino de dicas em nível de protocolo — como destructiveHint, que sinaliza se uma ferramenta deve acionar uma confirmação do usuário — mas essas são consultivas, não aplicadas.

Essa arquitetura tem uma propriedade fundamental que os engenheiros de segurança precisam internalizar: a superfície de ataque não são apenas as ferramentas em si, mas tudo o que essas ferramentas podem ler. Se uma ferramenta busca uma página da web, um registro de banco de dados, uma descrição de pull request ou um arquivo de log, esse conteúdo entra no contexto do agente. Se um atacante controla esse conteúdo, ele pode influenciar o comportamento do agente. Isso é injeção de prompt, e é a chave mestra que torna cada outra vulnerabilidade do MCP explorável.

A Metodologia

Abordamos isso da mesma forma que uma equipe vermelha aborda uma base de código desconhecida: sistematicamente, começando amplo e estreitando para a explorabilidade confirmada.

Fase 1 — Descoberta e triagem. Identificamos servidores MCP oficiais de fornecedores de alto valor: empresas com bases de clientes empresariais, programas ativos de recompensas por bugs e implementações de MCP que tocavam operações sensíveis. Servidores de banco de dados, integrações de CI/CD, provedores de identidade, ferramentas de gerenciamento de infraestrutura. Clonamos cada repositório e executamos análise estática automatizada — semgrep com regras personalizadas direcionadas a padrões específicos do MCP, bandit para alvos Python, grep manual para manipulação de credenciais, construção de URL e parametrização de consultas.

Fase 2 — Identificação de padrões. A análise estática produz sinal, não descobertas. Revisamos cada sinal manualmente, procurando padrões que seriam exploráveis em uma implantação realista do agente. Procuramos especificamente: parâmetros não sanitizados sendo interpolados em consultas ou comandos, material de credenciais sendo retornado nas respostas das ferramentas, flags de somente leitura que não restringiam realmente operações perigosas e anotações destructiveHint ausentes ou incorretas.

Fase 3 — Verificação ao vivo. É aqui que muitos fluxos de trabalho de pesquisa de segurança param, e onde fizemos uma regra deliberada para nós mesmos: sem aviso sem um PoC ao vivo confirmado. Criamos instâncias locais de cada alvo — contêineres Docker para servidores de banco de dados, contas reais para serviços em nuvem, instalações locais de npm para bibliotecas de framework MCP. Cada descoberta foi testada contra uma instância em execução antes que qualquer divulgação fosse registrada. Uma descoberta que parecia forte na análise estática falhou em se reproduzir na configuração padrão atual. Nós a fechamos em vez de registrar uma descoberta que não pudemos provar.

Fase 4 — Divulgação. Relato privado do GHSA onde disponível, portal MSRC para alvos da Microsoft, e-mail direto para fornecedores sem um canal formal. Cada divulgação incluiu a localização do código vulnerável, um script de reprodução e a saída esperada.

As Classes de Vulnerabilidade

Através dos servidores que examinamos, as mesmas classes de vulnerabilidade apareceram repetidamente. Nós as descrevemos aqui como padrões, não como descobertas específicas de fornecedores.

Padrão 1: A Etiqueta Errada do destructiveHint

A especificação do MCP inclui um campo destructiveHint nas definições de ferramentas. Quando definido como true, clientes MCP compatíveis — Claude Desktop, Cursor, VS Code Copilot — devem solicitar ao usuário antes de executar a ferramenta. Quando definido como false, a ferramenta é executada silenciosamente.

Encontramos várias instâncias onde uma ferramenta que realiza uma operação genuinamente destrutiva ou sensível foi anotada com destructiveHint: false. Em um caso, a ferramenta mal rotulada era a única operação de escrita em todo um código que cria código executável — todas as outras operações de escrita estavam corretamente anotadas. A inconsistência não era ruído aleatório. Era uma ferramenta específica, fazendo algo sensível específico, com a anotação errada.

A explorabilidade desse padrão depende da injeção de prompt como pré-requisito. Se um atacante pode influenciar qual conteúdo um agente LLM lê — através de uma página da web maliciosa, um registro de banco de dados envenenado, uma descrição de pull request elaborada — ele pode instruir o agente a chamar a ferramenta mal rotulada. Como destructiveHint: false, o cliente MCP nunca avisa o usuário. A operação é executada silenciosamente.

A correção é simples: auditar a anotação destructiveHint de cada ferramenta em relação ao que a ferramenta realmente faz. Qualquer ferramenta que cria, modifica ou exclui dados — ou que aciona uma ação com consequências no mundo real — deve ser anotada como true.

Padrão 2: O Bypass de Somente Leitura

Vários servidores MCP expõem um "modo somente leitura" — uma flag de configuração ou configuração em tempo de execução que supostamente restringe o agente a operações não destrutivas. O modelo de segurança depende dessa flag para tornar o servidor seguro para implantação em contextos onde o agente não deve ser capaz de modificar dados.

Encontramos vários casos onde a flag de somente leitura não restringia todas as operações perigosas. O modo de falha comum: a flag foi implementada bloqueando uma lista específica de operações de escrita, em vez de permitir apenas uma lista específica de operações de leitura. A diferença é enorme. Uma abordagem de lista de bloqueio falha quando há operações que não são escritas no sentido tradicional, mas ainda têm efeitos perigosos — funções que executam código arbitrário, comandos que limpam bancos de dados inteiros, consultas que exfiltram dados sensíveis por design.

Um exemplo particularmente claro: um servidor Redis MCP marcou uma ferramenta de execução de comando como readonly: true em seus metadados. A ferramenta aceitava e executava EVAL (execução de código Lua arbitrário) e FLUSHALL (destrói todo o banco de dados). Nenhum é uma "escrita" no sentido de chave-valor, mas ambos são obviamente destrutivos. A flag de somente leitura fornece