Servidor MCP que busca URL: o erro que cinco equipes repetiram

Um provedor de nuvem, um banco global, uma empresa de banco de dados, o governo francês e a prefeitura de uma cidade na Indonésia corrigiram, entre junho e setembro de 2026, o mesmo defeito em servidores MCP que eles mesmos publicaram. Segundo o pesquisador que reportou os cinco casos, nenhum deles divide código ou dono com os outros. O que eles dividem é o protocolo que liga agentes de IA a ferramentas e sistemas, e um pressuposto: o valor que chega pelo agente é de confiança, porque veio de dentro.

O defeito tem nome antigo, SSRF (server-side request forgery, falsificação de requisição pelo servidor). Uma ferramenta recebe um endereço, um caminho ou um endpoint como argumento e faz a requisição sem conferir para onde aquele endereço realmente aponta. Quem consegue pôr texto na frente do agente, numa página, num e-mail ou num documento, passa a escolher com quem o servidor conversa, inclusive sistemas internos que a internet não enxerga.

O pesquisador é o independente Syed Anas Mohiuddin, que reuniu os casos numa publicação de outubro de 2026 que a Ars Technica e o The Next Web repercutiram em 6 de outubro. O que dá peso ao relato é que as correções não dependem da palavra dele: quatro estão em repositório público da própria organização, com ele creditado.

Cinco correções, um mesmo pressuposto

A do JPMorgan é a exceção: se apoia no relato do pesquisador e na página de reconhecimento do banco que ele cita.

A gravidade varia. A falha do Google recebeu 8,0 na escala CVSS 4.0 e 6,1 na versão 3.1 da mesma escala, e o advisory diz que um prompt malicioso alimentado por dados pode provocar o desvio. No caso do JPMorgan, a requisição forjada não carregava credencial, o que limita o estrago. A conta que importa para quem decide não é a nota de cada caso. É a repetição.

O fork que perdeu a checagem

Para o pesquisador, o caso do JPMorgan é o mais instrutivo, porque ninguém fez nada obviamente errado. O servidor nasceu de um projeto da AWS que nunca buscava a URL do chamador. Na reescrita, alguém acrescentou a busca numa ferramenta nova e não levou junto a lista de domínios permitidos que a ferramenta irmã aplicava. Duas equipes competentes, um passo rotineiro de derivação, e um buraco que nenhum dos dois códigos tinha sozinho.

O de Tangerang é o inverso: o servidor anunciava proteção contra SSRF, e ela existia. Só conferia o texto do endereço, não para onde o nome resolvia. Um domínio comum que apontasse para a rede interna, ou para o serviço de metadados da nuvem em 169.254.169.254, onde ficam credenciais da máquina, atravessava a verificação. O servidor tinha 132 ferramentas com acesso amplo de leitura e escrita a um SIEM, o sistema que centraliza os alertas de segurança.

Nos dois casos, quem olhasse a lista de recursos veria segurança. O defeito estava no detalhe de onde a validação acontecia.

Por que a varredura de dependências passa batido

Ferramenta de análise de dependências procura pacote com vulnerabilidade conhecida e segue o caminho do código. No servidor MCP, a entrada perigosa não chega por um caminho que essas ferramentas modelam: ela chega pelo transporte, como argumento que o modelo escolheu, descrito num manifesto de ferramenta que o scanner não lê. Nos casos que o pesquisador detalha, nenhuma dependência estava vulnerável. O problema era como o servidor tratava um valor em que não devia confiar.

O pesquisador publicou um scanner aberto, o mcp-safeguard, que testa o servidor pela superfície de ferramentas. Ele mesmo escreve que vários achados exigiram ler código e comparar forks lado a lado, e que ferramenta de padrão perde boa parte dessa classe. Para quem compra ou contrata, a consequência é que "passou no scanner" não responde a pergunta.

Quem não precisa se preocupar com isso

A notícia não diz que o MCP é inseguro, e seria errado lê-la assim.

SSRF é uma classe de falha conhecida há anos em aplicações web, e o protocolo não a inventou. Servidor MCP cujas ferramentas não recebem endereço como argumento, ou que só chamam destinos fixos definidos no código, não tem essa superfície. Servidor que roda apenas na máquina do desenvolvedor, sem acesso a rede interna, tem um alcance menor. E ferramenta que lê de um banco por consulta parametrizada, sem montar requisição de saída, está fora do problema descrito aqui.

Também vale separar o que está confirmado do que não está. O padrão vem de um pesquisador só, que escolheu onde olhar. Ele diz ter reportado em 2 de setembro achados em cinco servidores MCP ligados ao governo federal dos Estados Unidos, e um no servidor da Agência Digital do Japão, mas nenhum deles foi confirmado pelas organizações até a publicação, e ele próprio não os apresenta como resultado. Não encontramos posicionamento da Anthropic, que lançou o protocolo, nem dos mantenedores dele sobre esse conjunto de casos.

O que os cinco casos corrigidos mostram é que o erro é fácil de cometer e aparece em equipes de perfil muito diferente. Não mostram com que frequência ele aparece nos servidores que existem por aí.

O que o protocolo recomenda, e onde o texto para

As boas práticas de segurança publicadas pelo projeto do MCP têm uma seção inteira sobre SSRF, com recomendações sólidas: exigir HTTPS, bloquear faixas de rede privada e o endereço de metadados da nuvem, validar cada salto de redirecionamento, usar um proxy de saída e cuidar do intervalo entre conferir o DNS e fazer a requisição. O texto avisa ainda para não implementar a validação de IP na mão, porque truques de codificação enganam parser caseiro.

O contexto daquela seção, na versão consultada em 6 de outubro, é outro: o cliente MCP buscando endereços durante a descoberta de autorização OAuth, e o servidor de autorização buscando documentos de identificação de cliente. O caso dos cinco servidores, uma ferramenta que busca o endereço recebido como argumento, fica por conta de quem implementa. As mesmas recomendações servem, mas alguém precisa decidir aplicá-las em cada ferramenta.

Quatro perguntas antes de ligar o servidor MCP

Servem para quem constrói o próprio servidor e para quem contrata um fornecedor para isso. Partem das correções publicadas e das recomendações do pesquisador.

1. Para onde cada ferramenta pode fazer requisição, e quem confere isso no momento da conexão? A validação precisa olhar o IP para o qual o nome resolveu na hora de conectar, e não o texto do endereço antes. Foi o que a correção do Google passou a fazer, com faixas permitidas e bloqueadas configuráveis e a recusa de endereço-base inseguro já na inicialização.
2. O servidor segue redirecionamento sozinho? Se segue, cada salto precisa passar pela mesma verificação. O redirecionamento foi a porta da falha do Google.
3. Toda ferramenta que busca endereço passa pela mesma lista de destinos permitidos, inclusive as que entraram depois e as que vieram de outro projeto? O caso do JPMorgan é exatamente a segunda ferramenta, escrita depois, sem a regra da primeira.
4. O backend confia no servidor MCP para autorizar, ou confere de novo? Num projeto nosso com um gateway MCP na frente de um CMS Strapi, a exigência de segurança do lado do cliente foi que o backend nunca autorize só porque a chamada veio do gateway, e confira usuário, papel e permissão a cada requisição. É a mesma lógica aplicada na direção contrária: o que atravessa a fronteira do MCP não ganha confiança por ter atravessado.

Nenhuma das quatro elimina o risco. Elas reduzem o que um agente enganado consegue alcançar, e é essa a medida razoável quando quem chama a ferramenta é um agente que, por definição, lê texto que ninguém da empresa controla.

Quando o log vira incidente pela LGPD

O pesquisador descreve um segundo modo de falha nos servidores federais americanos ainda em triagem: o servidor grava o corpo inteiro da resposta do sistema de origem no log de erro, sem mascarar nada. No caso de um servidor de benefícios para veteranos, esse corpo pode conter nome, número de seguridade social, data de nascimento e endereço, e bastam erros de validação comuns para ele ir parar no log centralizado.

Traduzido para cá: um servidor MCP ligado a ERP, CRM ou sistema de RH que despeja a resposta inteira no log pode levar CPF e dado pessoal para um lugar que muita gente da operação lê e que nem sempre tem a mesma proteção do banco de origem. Se isso vazar e houver risco relevante aos titulares, a Resolução CD/ANPD nº 15, de abril de 2024, dá 3 dias úteis para comunicar a ANPD e os próprios titulares. A correção custa uma regra de mascaramento antes de gravar. Descobrir depois custa um incidente.

A decisão desta semana

Liste as ferramentas dos servidores MCP que a empresa já tem ou está contratando, e marque as que recebem endereço, caminho ou endpoint como argumento. Para cada uma, alguém precisa conseguir responder às quatro perguntas acima com o código ou o contrato na mão.

Das ferramentas que buscam endereço nos seus servidores MCP, quantas passam pela mesma lista de destinos permitidos?

Fontes e método

• Syed Anas Mohiuddin, "Protocol Pivoting, Four Months Later", publicação de outubro de 2026, consultada em 06/10/2026. É a fonte do padrão, do caso JPMorgan, dos achados ainda em triagem nos Estados Unidos e no Japão (alegação do pesquisador, não confirmada pelas organizações) e das recomendações de mitigação.
• Google: advisory GHSA-3x3x-8ffg-ghcv (CVE-2026-14540), publicado em 31/07/2026, com versões afetadas e notas CVSS 4.0 (8,0) e 3.1 (6,1); pull request 3448 do repositório googleapis/mcp-toolbox, mesclado em 18/06/2026 e lançado na versão 1.5.0 no mesmo dia.
• Weaviate: pull request 12961, mesclado em 07/09/2026. DINUM: pull request 126 do repositório datagouv/datagouv-mcp, mesclado em 04/09/2026. Tangerang: advisory GHSA-pw2j-pj4h-f5vg do repositório INFOKOM-KI/Wazuh-MCP-Server, publicado em 03/09/2026. DINUM e Tangerang creditam o pesquisador no próprio documento; a Weaviate, segundo ele, o lista no seu quadro público de reconhecimento de segurança.
• Projeto MCP: boas práticas de segurança, versão de rascunho consultada em 06/10/2026.
• ANPD: Resolução CD/ANPD nº 15, de 24/04/2024, sobre comunicação de incidente de segurança.
• Repercussão: Ars Technica e The Next Web, 06/10/2026, usadas para localizar a fonte primária, não como lastro.
• Experiência da X-Apps: exigência de revalidação de permissão atrás de um gateway MCP, descrita sem nome de cliente e sem número.