Pivote de protocolo: 5 gigantes caen por fallo en MCP

Cómo funciona el "pivote de protocolo" entre agentes de IA

En los últimos cinco meses, Google, JPMorgan Chase, Weaviate, la Dirección Interministerial Digital de Francia (DINUM) y el gobierno de la ciudad de Tangerang (Indonesia) reconocieron de forma separada una misma clase de vulnerabilidad en sus sistemas de agentes de inteligencia artificial. Lo que une a estos cinco casos no es el código, ni la industria, ni el equipo detrás: todos usan MCP (Model Context Protocol), el estándar que permite que aplicaciones y agentes de IA se conecten entre sí dentro de una organización.

El investigador independiente Syed Anas Mohiuddin bautizó la técnica como "pivote de protocolo" (protocol pivoting). La idea es sencilla y, por eso mismo, incómoda: un atacante entra por un agente de IA, le inyecta una instrucción maliciosa y ese agente la reenvía como si fuera una tarea legítima al siguiente de la cadena. Como los agentes internos confían entre sí por defecto, el segundo ejecuta la orden sin validar su procedencia. Para el sistema, no hay señal evidente de ataque: cada uno está haciendo exactamente para lo que fue diseñado.

El problema es estructural, no de implementación. Mohiuddin publicó un preprint en Zenodo el 24 de mayo de 2026 llamado "Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems" y predijo que, si la debilidad era de diseño y no de un descuido puntual, el mismo bug aparecería en servidores MCP escritos por equipos que no comparten código. Cuatro meses después, su predicción se cumplió en cinco organizaciones sin relación entre sí.

Google, JPMorgan y tres más: los casos confirmados

El caso más grave es CVE-2026-14540, una vulnerabilidad de tipo server-side request forgery (SSRF) en la herramienta mcp-toolbox de Google, versiones 0.3.0 a 1.4.0. Según el GitHub Advisory Database y el National Vulnerability Database de EE. UU., publicados el 31 de julio de 2026, un parámetro de ruta manipulado podía redirigir las solicitudes salientes del toolbox hacia direcciones internas o endpoints arbitrarios. La causa: el cliente HTTP no tenía política restrictiva de redirecciones ni validaba direcciones IP de destino. CVSS 8.0 sobre 10 (severidad alta).

Google fusionó el arreglo en el pull request #3448 del repositorio googleapis/mcp-toolbox el 18 de junio de 2026 y lo envió en la versión 1.5.0. El parche añade un SSRFGuard que valida la IP de destino en el momento de la conexión, permite configurar allowedIpRanges y customBlockedIpRanges, y revalida la BaseURL al inicializar en vez de en la primera petición.

JPMorgan Chase tuvo un caso de severidad media en su servidor MCP de búsqueda de documentación (jpmorgan-payments/ai). La herramienta read_documentation aplicaba una lista de dominios permitidos, pero su función hermana related() fetcheaba una URL proporcionada por el llamador sin restricción. El equipo de Responsible Disclosure del banco confirmó la vulnerabilidad y la corrigió; Mohiuddin aparece en la página pública de reconocimiento.

Weaviate arregló una vulnerabilidad similar en el módulo Google de su servidor MCP el 25 de agosto de 2026, restringiendo los parámetros apiEndpoint, region y location a hosts de la API de Google. En Francia, el proyecto oficial datagouv-mcp del DINUM fusionó el pull request #126 el 4 de septiembre de 2026 con el encabezado "Feat l harden SSRF on external APIs": un campo machine_documentation_url podía apuntar a direcciones loopback o a la metadata de la nube.

El caso del gobierno de Tangerang (Indonesia), mantenido por la dirección INFOKOM-KI, recibió CVSS alto y fue parcheado el 3 de septiembre de 2026. La herramienta blueteam_check_webshell prometía bloquear IPs privadas en el host, pero solo rechazaba literales, no nombres de host que resolvieran hacia esas mismas IPs.

Rapid7, por su parte, publicó CVE-2026-97228 (CVSS 2.7) el 25 de septiembre de 2026: una inyección GraphQL en su servidor MCP de Bulk Export, ya corregida en la versión 0.6.2.

Por qué los escáneres tradicionales no detectan estos ataques

El software composition analysis y los escáneres de dependencias miran el código que importa tu proyecto. El problema con el protocolo MCP es distinto: la entrada peligrosa llega por el transporte, descrita en un manifiesto de herramienta que el escáner nunca lee, según explica Mohiuddin. El call graph se corta en el límite del transporte y la vulnerabilidad pasa desapercibida.

Un análisis de OX Security sobre 15.465 servidores MCP públicos indexados en cinco marketplaces, deduplicados a 5.095 hostnames únicos, dibuja el tamaño real del problema: el 15,6% de los hostnames resuelve en infraestructura fuera de EE. UU. (19 en China, 18 in Russia). El 0,45% enruta tráfico por túneles de consumo tipo ngrok gratuito, lo que sugiere servidores corriendo en máquinas personales y redes de hogar. El 2,3% de los dominios ya no resuelve: seis apuntan a dominios expirados que cualquier atacante puede registrar entre 4 y 12 dólares al año, heredando la identidad y las solicitudes de los agentes que aún las conservan.

La conclusión de OX Security es directa: "El protocolo no es el problema. La confianza que depositamos en él, sí". Hasta que los marketplaces MCP añadan revisión, firma de código y verificación de origen, el trabajo de vetting recae en la empresa que los instala.

Qué significa esto para tu startup

Si estás montando flujos con agentes de IA que llaman a bases de datos, CRMs, ERPs o servicios internos vía MCP, este no es un riesgo teórico: ya está siendo explotado en cinco organizaciones de primer nivel con su propio equipo de seguridad. La superficie de ataque se multiplica con cada agente que conectas.

Tres acciones concretas que puedes tomar esta semana:

• Audita qué servidores MCP tienes en producción y de quién vienen. Pregunta a tu equipo quién los instaló, de qué marketplace salieron y si el repositorio público coincide con el binario que realmente corre. OX Security encontró servidores cuyo código remoto no coincide con el publicado en GitHub.
• Aplica el principio de cero confianza entre agentes, no solo entre usuarios. Trata cada instrucción que pasa de un agente a una herramienta como si viniera de una fuente externa. El propio Google lo hizo así: validó la IP de destino en el momento de la conexión, no en la primera petición, y añadió listas explícitas de rangos permitidos y prohibidos.
• Pon un proxy inline entre tus agentes y las herramientas externas. Una capa que inspeccione cada llamada de herramienta y su respuesta, redacte PII y credenciales, y exporte logs a tu SIEM. Esa es, de hecho, la arquitectura que ofrece ahora el producto MCP Proxy de Protectt.ai para el sector BFSI, y el tipo de mitigación que el propio Mohiuddin recomienda.

El 23 de octubre de 2026, Mohiuddin presentará el patrón transversal en MCPCon North America en San José. Mientras tanto, cinco hallazgos adicionales abiertos en servidores MCP del Gobierno de EE. UU. (VA, CMS, regulations.gov, USASpending y CDC) siguen sin parche y sin reconocimiento público. La pregunta ya no es si tu startup va a usar agentes de IA, sino cuántos vas a conectar y con qué controles alrededor.

Fuentes

• El nuevo peligro de la IA: un agente puede engañar a otro para que robe información - Infobae
• MCP for agent-to-agent comms may be the riskiest protocol you've never heard of - Ars Technica
• Researcher Discloses Same MCP Flaw at Google, JPMorgan, Two Governments - Unite.AI
• Welcome to the Jungle: What We Found Inside 15,465 Public MCP Servers - The Hacker News