Pesquisador divulga mesma falha MCP no Google, JPMorgan, dois governos

Pesquisador de segurança independente Syed Anas Mohiuddin divulgou em uma atualização de pesquisa de outubro de 2026 que o mesmo erro de falsificação de solicitação do lado do servidor em servidores Model Context Protocol foi confirmado e corrigido pelas equipes de segurança de cinco organizações não relacionadas: Google, JPMorgan Chase, Weaviate, a diretoria digital interministerial da França e o governo da cidade de Tangerang na Indonésia.

A atualização, intitulada “Protocol Pivoting, four months later”, testa uma previsão que Mohiuddin fez em maio de 2026: se a vulnerabilidade fosse estrutural em vez de uma única implementação descuidada, o mesmo bug surgiria em servidores escritos por equipes que não compartilham código, setor, país ou proprietário. Ele relata que cada uma das cinco organizações confirmou seu caso por meio de sua própria equipe de segurança, e que o fornecedor de segurança Rapid7 publicou separadamente um CVE para um bug diferente, porém relacionado. A atualização contabiliza cinco organizações que corrigiram o mesmo SSRF, duas publicaram CVEs e cinco descobertas em servidores federais dos EUA que permanecem abertas.

Mohiuddin descreve dois modos de falha por trás do padrão. O primeiro é falsificação de solicitação do lado do servidor: um servidor MCP cria uma solicitação de saída a partir de uma URL, caminho ou endpoint fornecido por um agente sem verificar para onde ele resolve, de modo que o agente decide efetivamente com o que a identidade de rede do servidor se comunica. O segundo é o manuseio inseguro de dados upstream, mais visivelmente escrevendo respostas completas de APIs upstream em logs centralizados sem redação, o que erros comuns são suficientes para desencadear. Ele atribui ambos a uma suposição: que os dados que cruzam a fronteira do MCP são confiáveis porque vieram de dentro do sistema, o que ele argumenta não ser válido em um pipeline agente.

CVE-2026-14540 na MCP Toolbox do Google

De acordo com a entrada do GitHub Advisory Database para CVE-2026-14540, publicada pelo National Vulnerability Database, existe uma vulnerabilidade SSRF nos componentes genéricos de origem HTTP e ferramentas do Google mcp-toolbox nas versões 0.3.0 a 1.4.0. Como o cliente HTTP não possuía uma política restritiva de redirecionamento e nunca validava endereços IP de destino, um parâmetro de caminho manipulado poderia redirecionar as solicitações de saída da toolbox para endpoints internos ou externos arbitrários. O aviso classifica a falha como de alta gravidade com pontuação CVSS de 8.0; foi publicado em 31 de julho de 2026 e atualizado pela última vez em 8 de agosto de 2026. Mohiuddin afirma que o CVE foi reservado em 3 de julho de 2026 e que o registro o credita como descobridor.

Google incorporou a correção, pull request #3448 no repositório googleapis/mcp-toolbox, em 18 de junho de 2026, e ela foi lançada no mcp-toolbox v1.5.0. A pull request implementa um SSRFGuard para impedir ataques de DNS-rebinding no intervalo entre a verificação de endereço e a conexão, adiciona propriedades configuráveis allowPrivateNetworks, allowedIpRanges e customBlockedIpRanges, valida o BaseURL configurado na inicialização em vez de na primeira solicitação, e avisa explicitamente sobre o risco de ataque man-in-the-middle quando a verificação SSL está desativada. O PR credita Mohiuddin como o relator, e Mohiuddin descreve a remediação do Google como uma implementação de referência de um verdadeiro guardião SSRF.

Quatro casos confirmados adicionais

Mohiuddin relata que o repositório de código aberto jpmorgan-payments/ai da JPMorgan Chase inclui um servidor MCP de pesquisa de documentação cujo ferramenta read_documentation aplica uma lista de permissões de domínios antes de buscar, enquanto sua ferramenta irmã related() busca uma URL fornecida pelo chamador do lado do servidor sem restrição. Ele afirma que o componente foi bifurcado de um projeto da AWS cujo original nunca referenciou a URL do chamador, que a equipe de Divulgação Responsável do banco confirmou a descoberta como válida, e que uma correção foi implantada. Ele está listado pelo nome na página pública de reconhecimento de divulgação responsável da JPMorgan Chase e classifica a descoberta como de gravidade média, observando que nenhuma credencial viaja com a solicitação falsificada.

Weaviate, relata, incorporou uma pull request que restringe as configurações apiEndpoint, region e location do módulo Google aos hosts da API do Google, e o lista pelo nome em sua entrada pública do Security Hall of Fame datada de 25 de agosto de 2026.

O projeto datagouv/datagouv-mcp incorporou pull request #126, “feat: harden SSRF on external APIs”, em 4 de setembro de 2026, e a pull request abre creditando Mohiuddin como relator. De acordo com a PR, um campo machinedocumentaçãourl fornecido por qualquer produtor registrado no data.gouv.fr era buscado do lado do servidor e poderia apontar para endereços de loopback, rede privada ou metadados de nuvem, com o DNS rebinding capaz de trocar o alvo entre a verificação e a conexão e um redirecionamento 302 capaz de chegar a um host interno. A correção valida o IP de destino no momento da conexão, reavalia cada salto de redirecionamento e rejeita proxies. Mohiuddin identifica o projeto como o servidor MCP oficial da plataforma nacional de dados abertos da França, mantido pela DINUM, a diretoria digital interministerial do governo.

Um Aviso de Segurança do GitHub publicado em 3 de setembro de 2026 pelos mantenedores do INFOKOM-KI/Wazuh-MCP-Server, classificado como Alto, registra que a ferramenta blueteamcheckwebshell anunciava proteção contra SSRF que rejeitava apenas endereços IP literais e nunca resolvia nomes de host, de modo que qualquer nome DNS apontando para um endereço privado, de loopback ou link‑local, inclusive metadados de instâncias em nuvem, contornava a proteção. O aviso observa que a garantia documentada da ferramenta, “Proteção SSRF: IPs privados/reservados no host da URL são rejeitados”, não se aplicava a URLs baseadas em nomes de host. A falha foi corrigida no commit 2bbfe12, e o aviso credita Mohiuddin como relator. Mohiuddin afirma que a reportou em 2 de setembro de 2026, que os mantenedores responderam a partir de um endereço tangerangkota.go.id, e que o projeto é mantido pelo governo da cidade de Tangerang, na Indonésia.

O registro da base de dados de vulnerabilidades para CVE-2026-97228 da Rapid7 registra uma injeção de consulta GraphQL no Rapid7 Bulk Export MCP nas versões 0.2.5 até 0.6.1, na qual uma exportação não validadao argumento id da ferramenta MCP é interpolado diretamente em uma consulta GraphQL. A Rapid7 atribui a ela pontuação 2.7, Baixa, na escala CVSS 3.1, publicou o registro em 25 de setembro de 2026, e observa que consultas injetadas são executadas dentro do escopo da própria API do operador e não podem atravessar a fronteira de um locatário; a versão 0.6.2 corrige o problema passando exportid como uma variável parametrizada. Mohiuddin afirma que a Rapid7 o creditou como descobridor.

Além desses casos, Mohiuddin relata que, a partir da atualização, 16 avisos de segurança do GitHub publicados pelos próprios mantenedores dos projetos o credenciam como relator, abrangendo SSRF, injeção de comando, lacunas de autenticação, sequestro de sessão, vazamento de credenciais e contornos de correções anteriores, e que ele teve correções incorporadas em projetos incluindo github-mcp-server, mongodb-mcp-server e salesforce-mcp-server.

Constatações Governamentais Não Resolvidas

Mohiuddin relata ter registrado cinco constatações como Avisos de Segurança privados no GitHub em 2 de setembro de 2026, abrangendo servidores MCP sob o Technology Transformation Services da GSA: um servidor de solicitações de benefícios do Departamento de Assuntos de Veteranos, um servidor CMS Blue Button, um servidor regulations.gov, um servidor USASpending e um servidor CDC PLACES. Ele afirma que todas as cinco permanecem em triagem, não foram corrigidas e não são apresentadas como resultados confirmados.

No caso do VA, que ele descreve apenas ao nível da classe, o servidor registra o corpo completo do erro da API de benefícios upstream no nível ERROR sem anonimização; esses corpos podem conter o nome de um veterano, número da Segurança Social, data de nascimento e endereço, e ele afirma que falhas rotineiras de validação são suficientes para acionar o registro durante a operação normal. Ele está retendo detalhes de código até que os servidores sejam corrigidos.

Ele também relata que, em 1 de setembro de 2026, notificou o JPCERT de que o jgrants-mcp-server da Agência Digital do Japão não possuía autenticação, e em 7 de setembro de 2026 abriu um pull request público exigindo um opt‑in explícito para vincular o servidor a algo diferente de loopback e limitando o tamanho de gravação de anexos. O pull request ainda não foi mesclado, e ele não o apresenta como um resultado confirmado.

Pivotagem de Protocolo e a Palestra MCPCon

Mohiuddin define Pivotagem de Protocolo como um ataque em múltiplas etapas no qual um adversário entra por um protocolo, explora as suposições de confiança que os protocolos colocam uns nos outros e escala para capacidades disponíveis apenas através de outro protocolo. Seu exemplo concreto insere texto formatado como uma instrução de tarefa A2A dentro da saída da ferramenta MCP; um agente orquestrador o repassa a um subagente como delegação normal, e o subagente, confiando em seu orquestrador, o executa.

O preprint formal, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” foi publicado no Zenodo em 24 de maio de 2026. Ele apresenta três cenários: escalada de privilégios MCP‑para‑A2A via delegação de confiança implícita, injeção de capacidade A2A‑para‑MCP via personificação maliciosa de agente, e cadeias de injeção de prompt entre protocolos. Também analisa por que as defesas existentes falham contra a classe e propõe uma estrutura de segurança cross‑protocol unificada com um modelo formal de fronteira de confiança e três mitigações agnósticas ao protocolo.

O trabalho de maio começou com o playwright-mcp da Microsoft, cuja ferramenta browser_navigate aceitava qualquer URL fornecida pelo agente sem proteção contra SSRF, permitindo que um agente fosse direcionado ao serviço de metadados de instância da AWS em 169.254.169.254 e suas credenciais. Mohiuddin observa que registrou isso como uma issue pública no GitHub, que não há CVE nem confirmação do fornecedor, e que a classificação de severidade é sua própria avaliação.

Mohiuddin argumenta que análises de composição de software e scanners de dependências perdem essa classe porque a entrada perigosa chega pelo transporte como um argumento de ferramenta descrito por um manifesto de ferramenta que o scanner nunca lê, de modo que o grafo de chamadas para no limite do transporte. Ele afirma que desenvolveu o mcp-safeguard, um scanner de código aberto que testa servidores MCP através de sua superfície de ferramenta exposta sem precisar do código-fonte, procurando por seis classes: SSRF, permissões excessivas, superfícies de injeção de prompt, vazamento de informações, lacunas de autenticação e contorno de ciclo de vida. Ele também afirma que ferramentas de correspondência de padrões, inclusive a sua própria, perdem uma grande parte da classe.

Mohiuddin declara que apresentará o padrão cross‑vendor em 23 de outubro de 2026 na MCPCon North America em San Jose, incluindo quaisquer constatações que estejam corrigidas até lá, e que as constatações federais permanecerão privadas até serem corrigidas.