El protocolo MCP acumula el mismo fallo de seguridad entre gigantes sin relación

Un investigador independiente documenta el mismo patrón de fallo en servidores MCP —valores sin validar que un agente propaga a otros agentes de la cadena— confirmado y corregido por separado por Google, JPMorgan Chase, Weaviate, la DINUM francesa y la ciudad de Tangerang, con un CVE de Rapid7 y cinco reportes federales de EE. UU. aún en triage.

Qué ha ocurrido

Syed Anas Mohiuddin, investigador de seguridad independiente, publicó en mayo una prueba de concepto sobre un patrón que denominó «Protocol Pivoting»: servidores MCP que intercalan valores controlados por un agente —una URL, un identificador— directamente en consultas internas (por ejemplo GraphQL o peticiones HTTP), lo que permite inyección server-side request forgery. Su hipótesis era que el problema era estructural, no un despiste puntual, y la puesta a prueba de mayo se ha convertido en una cuenta de casos verificada: al menos cinco equipos de seguridad sin relación entre sí —Google, JPMorgan Chase, Weaviate, la dirección digital interministerial de Francia (DINUM) y el gobierno de la ciudad indonesia de Tangerang— han confirmado cada uno el mismo fallo y lo han corregido por su cuenta. Rapid7 registró además un CVE (2026-97228, puntuación CVSS 2,7 «baja») por una variante en la inyección de consultas GraphQL en su exportador MCP. El propio investigador notificó el 2 de septiembre cinco problemas similares en servidores MCP construidos para el gobierno federal de EE. UU.; están en triage y él no los presenta como confirmados. Ars Technica informó del patrón el 5-10-2026, con la advertencia de Rapid7 de que la cadena agente→agente es difícil de cerrar porque cada eslabón «hace exactamente lo que fue diseñado para hacer».

Por qué importa

MCP se ha convertido en dos años en el cableado estándar por el que los agentes de IA se hablan entre sí dentro de las empresas, y el patrón descrito explota precisamente la confianza interna: un agente con pocas barreras recibe un texto malicioso desde el exterior, se lo pasa «como tarea delegada normal» al siguiente agente —que sí tiene credenciales— y ese segundo agente obedece. Cada organización ha tenido que encontrar y arreglar el mismo agujero en su propia casa, y la CVE de Rapid7 muestra que el propio fabricante del servidor es parte del problema. Para cualquiera que despliegue agentes, la lección no es «parchea MCP» sino: no asumas que el emisor interno es de confianza y valida toda entrada, incluso dentro.

Qué cambió

AntesCada incidente de inyección de prompts se trataba como un despiste del modelo o de la aplicación.

AhoraCinco organizaciones independientes y un CVE han confirmado el mismo fallo de validación en la capa MCP por separado.

ConsecuenciaEl protocolo emergente entra en revisión estructural antes de que nadie lo audite en común, mientras sigue desplegándose.

Qué sabemos · qué no

Confirmado

• Publicación del investigador (octubre 2026) con el seguimiento de casos: cinco confirmaciones y correcciones independientes, dos CVE publicados y cinco reportes federales aún en triage.
• CVE-2026-97228 de Rapid7 documentada en su base de vulnerabilidades: inyección GraphQL vía export_id sin validar en MCP 0.2.5–0.6.1, corregida en 0.6.2, CVSS 2,7 (ejecuta solo dentro del alcance de la API del propio operador).
• Crónica de Ars Technica del 5-10-2026 con la declaración de Rapid7 sobre la dificultad de mitigar la cadena agente→agente.

Todavía no

• El resultado del triage de los cinco servidores MCP del gobierno federal de EE. UU.
• Si existe o se planea una revisión conjunta del estándar MCP para este tipo de validación.
• La exposición real acumulada antes de los parches.

Para ir al grano técnico

• → docs
• → docs

Qué vigilamos ahora

El cierre del triage federal, más CVE de servidores MCP y una respuesta formal del proyecto estándar (especificación MCP) sobre validación obligatoria de argumentos.