Investigador revela la misma vulnerabilidad MCP en Google, JPMorgan y dos gobiernos

El investigador de seguridad independiente Syed Anas Mohiuddin reveló en una actualización de investigación de octubre de 2026 que el mismo error de falsificación de solicitud del lado del servidor en los servidores Model Context Protocol ha sido confirmado y corregido por los equipos de seguridad de cinco organizaciones no relacionadas: Google, JPMorgan Chase, Weaviate, la dirección digital interministerial de Francia y el gobierno de la ciudad de Tangerang en Indonesia.

La actualización, titulada “Protocol Pivoting, cuatro meses después”, prueba una predicción que Mohiuddin hizo en mayo de 2026: si la vulnerabilidad fuera estructural y no una única implementación descuidada, el mismo error aparecería en servidores creados por equipos que no comparten código, industria, país ni propietario. Informa que cada una de las cinco organizaciones confirmó su caso a través de su propio equipo de seguridad, y que el proveedor de seguridad Rapid7 publicó por separado una CVE para un error diferente pero relacionado. La actualización contabiliza cinco organizaciones que corrigieron el mismo SSRF, dos publicaron CVEs y cinco hallazgos en servidores federales estadounidenses de MCP que siguen abiertos.

Mohiuddin describe dos modos de falla detrás del patrón. El primero es la falsificación de solicitud del lado del servidor: un servidor MCP construye una solicitud saliente a partir de una URL, ruta o punto final proporcionado por un agente sin comprobar a dónde se resuelve, de modo que el agente decide efectivamente con qué se comunica la identidad de red del servidor. El segundo es el manejo inseguro de datos ascendentes, que se manifiesta principalmente al escribir respuestas completas de API ascendentes en registros centralizados sin redacción, lo que basta para que errores ordinarios lo desencadenen. Él atribuye ambos a una suposición: que los datos que cruzan el límite del MCP se confían porque provienen del interior del sistema, lo que, según él, no se sostiene en una canalización agente.

CVE-2026-14540 en el MCP Toolbox de Google

Según la entrada de la Base de datos de avisos de GitHub para CVE-2026-14540, publicada por la National Vulnerability Database, existe una vulnerabilidad SSRF en los componentes genéricos de origen HTTP y herramienta del mcp-toolbox de Google versiones 0.3.0 a 1.4.0. Debido a que el cliente HTTP no tenía una política restrictiva de redirecciones y nunca validaba direcciones IP de destino, un parámetro de ruta manipulado podía redirigir las solicitudes salientes del toolbox hacia puntos finales internos o externos arbitrarios. El aviso califica la falla como de alta gravedad con una puntuación CVSS de 8.0; se publicó el 31 de julio de 2026 y se actualizó por última vez el 8 de agosto de 2026. Mohiuddin indica que la CVE se reservó el 3 de julio de 2026 y que el registro lo acredita como descubridor.

Google incorporó la corrección, solicitud de extracción #3448 en el repositorio googleapis/mcp-toolbox, el 18 de junio de 2026, y se lanzó en mcp-toolbox v1.5.0. La solicitud de extracción implementa un SSRFGuard para prevenir ataques de rebind de DNS en el intervalo entre la verificación de la dirección y la conexión, añade propiedades configurables allowPrivateNetworks, allowedIpRanges y customBlockedIpRanges, valida la BaseURL configurada en la inicialización en lugar de en la primera solicitud, y advierte explícitamente sobre el riesgo de ataques man-in-the-middle cuando la verificación SSL está deshabilitada. El PR acredita a Mohiuddin como reportero, y Mohiuddin describe la remediación de Google como una implementación de referencia de un guardia SSRF real.

Cuatro casos más confirmados

Mohiuddin informa que el repositorio de código abierto jpmorgan-payments/ai de JPMorgan Chase incluye un servidor MCP de búsqueda de documentación cuyo herramienta read_documentation aplica una lista blanca de dominios antes de obtener, mientras que su herramienta hermana related() recupera una URL suministrada por el llamante del lado del servidor sin restricción. Señala que el componente se bifurcó de un proyecto de AWS cuyo original nunca desreferenciaba la URL del llamante, que el equipo de Divulgación Responsable del banco confirmó el hallazgo como válido, y que se ha implementado una corrección. Aparece listado por su nombre en la página pública de reconocimiento de divulgación responsable de JPMorgan Chase y califica el hallazgo como de gravedad media, observando que ninguna credencial viaja con la solicitud falsificada.

Weaviate, informa, incorporó una solicitud de extracción que restringe los ajustes apiEndpoint, region y location del módulo Google a hosts de la API de Google, y lo lista por su nombre en su entrada pública del Salón de la Fama de Seguridad con fecha 25 de agosto de 2026.

El proyecto datagouv/datagouv-mcp incorporó solicitud de extracción #126, “feat: harden SSRF on external APIs”, el 4 de septiembre de 2026, y la solicitud de extracción comienza acreditando a Mohiuddin como reportero. Según el PR, un campo machinedocumentaciónurl suministrado por cualquier productor registrado de data.gouv.fr se recuperaba del lado del servidor y podía apuntar a direcciones de bucle invertido, red privada o metadatos en la nube, pudiendo el rebind de DNS cambiar el objetivo entre la verificación y la conexión y una redirección 302 llegar a un host interno. La corrección valida la IP de destino en el momento de la conexión, vuelve a comprobar cada salto de redirección y rechaza los proxies. Mohiuddin identifica el proyecto como el servidor MCP oficial de la plataforma nacional de datos abiertos de Francia, mantenido por DINUM, la dirección digital interministerial del gobierno.

Una GitHub Security Advisory publicada el 3 de septiembre de 2026 por los mantenedores de INFOKOM-KI/Wazuh-MCP-Server, calificada como Alta, registra que la herramienta blueteamcheckwebshell anunciaba una protección SSRF que rechazaba solo direcciones IP literales y nunca resolvía nombres de host, de modo que cualquier nombre DNS que apuntara a una dirección privada, de bucle invertido o link‑local, incluida la metadata de instancias en la nube, la eludía. La advertencia señala que la garantía documentada de la herramienta, “SSRF Protection: Private/reserved IPs in the URL host are rejected”, no se cumplía para URLs basadas en nombres de host. La vulnerabilidad se corrigió en el commit 2bbfe12, y el aviso acredita a Mohiuddin como reportero. Mohiuddin afirma que la informó el 2 de septiembre de 2026, que los mantenedores respondieron desde una dirección tangerangkota.go.id, y que el proyecto está mantenido por el gobierno de la ciudad de Tangerang en Indonesia.

Rapid7’s entrada de base de datos de vulnerabilidades para CVE-2026-97228 registra una inyección de consulta GraphQL en Rapid7 Bulk Export MCP versiones 0.2.5 a 0.6.1, en la que el argumento id de la herramienta MCP se interpola directamente en una consulta GraphQL. Rapid7 le asigna una puntuación de 2.7, Baja, en la escala CVSS 3.1, publicó el registro el 25 de septiembre de 2026, y señala que las consultas inyectadas se ejecutan dentro del alcance de la API del operador y no pueden cruzar el límite de un inquilino; la versión 0.6.2 corrige el problema pasando exportid. Mohiuddin afirma que Rapid7 lo acreditó como descubridor.

Más allá de esos casos, Mohiuddin informa que, a partir de la actualización, 16 avisos de seguridad de GitHub publicados por los propios mantenedores de los proyectos le acreditan como reportero, cubriendo SSRF así como inyección de comandos, brechas de autenticación, secuestro de sesión, filtraciones de credenciales y elusión de correcciones anteriores, y que ha tenido correcciones incorporadas en proyectos como github-mcp-server, mongodb-mcp-server y salesforce-mcp-server.

Unresolved Government Findings

Mohiuddin informa haber presentado cinco hallazgos como avisos de seguridad privados en GitHub el 2 de septiembre de 2026, que cubren servidores MCP bajo el Servicio de Transformación Tecnológica de la GSA: un servidor de reclamos de beneficios del Departamento de Asuntos de Veteranos, un servidor CMS Blue Button, un servidor regulations.gov, un servidor USASpending y un servidor CDC PLACES. Afirma que los cinco siguen en triage, no están corregidos y no se presentan como resultados confirmados.

En el caso del VA, que describe solo a nivel de clase, el servidor registra el cuerpo completo del error de la API de beneficios en nivel ERROR sin redacción; esos cuerpos pueden contener el nombre de un veterano, número de Seguro Social, fecha de nacimiento y dirección, y afirma que fallos rutinarios de validación son suficientes para activar el registro durante la operación normal. Está reteniendo los detalles a nivel de código hasta que los servidores sean parcheados.

También informa que el 1 de septiembre de 2026 notificó a JPCERT que el jgrants-mcp-server de la Agencia Digital de Japón no tenía autenticación, y que el 7 de septiembre de 2026 abrió una solicitud de extracción pública que exige una opción explícita de opt‑in para vincular el servidor a algo distinto del bucle invertido y limitar el tamaño de escritura de adjuntos. La solicitud de extracción no ha sido fusionada y no la presenta como un resultado confirmado.

Protocol Pivoting y la charla de MCPCon

Mohiuddin define Protocol Pivoting como un ataque de varios pasos en el que un adversario ingresa a través de un protocolo, explota las suposiciones de confianza que los protocolos colocan entre sí y escala a capacidades disponibles solo a través de otro protocolo. Su ejemplo concreto inserta texto con forma de instrucción de tarea A2A dentro de la salida de una herramienta MCP; un agente orquestador lo pasa a un subagente como delegación normal, y el subagente, confiando en su orquestador, lo ejecuta.

El el preprint formal, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” se publicó en Zenodo el 24 de mayo de 2026. Presenta tres escenarios: escalada de privilegios MCP‑to‑A2A mediante delegación de confianza implícita, inyección de capacidad A2A‑to‑MCP mediante suplantación de agente malicioso, y cadenas de inyección de prompts entre protocolos. También analiza por qué las defensas existentes fallan contra esta clase y propone un marco de seguridad cross‑protocol unificado con un modelo formal de límite de confianza y tres mitigaciones agnósticas al protocolo.

El trabajo de mayo comenzó con el playwright-mcp de Microsoft, cuya herramienta browser_navigate aceptaba cualquier URL suministrada por el agente sin protección SSRF, permitiendo que un agente fuera dirigido al servicio de metadata de instancias de AWS en 169.254.169.254 y sus credenciales. Mohiuddin señala que lo presentó como un issue público en GitHub, que no existe CVE ni confirmación del proveedor, y que la calificación de gravedad es su propia evaluación.

Mohiuddin argumenta que los análisis de composición de software y los escáneres de dependencias pasan por alto esta clase porque la entrada peligrosa llega a través del transporte como un argumento de herramienta descrito en un manifiesto de herramienta que el escáner nunca lee, de modo que el grafo de llamadas se detiene en la frontera del transporte. Afirma que construyó mcp-safeguard, un escáner de código abierto que prueba servidores MCP a través de su superficie de herramienta expuesta sin necesidad de código fuente, buscando seis clases: SSRF, permisos excesivos, superficies de inyección de prompts, filtración de información, brechas de autenticación y elusión del ciclo de vida. También indica que las herramientas de coincidencia de patrones, incluida la suya, omiten una gran parte de la clase.

Mohiuddin declara que presentará el patrón cross‑vendor el 23 de octubre de 2026 en MCPCon North America en San José, incluyendo los hallazgos que estén corregidos para entonces, y que los hallazgos federales permanecerán privados hasta que sean parcheados.