La misma SSRF en Google, JPMorgan y dos gobiernos: el fallo de MCP no se arregla en el protocolo

El 5 de octubre, Ars Technica tituló que MCP para comunicar agentes "may be the riskiest protocol you've never heard of". El protocolo más arriesgado del que nunca has oído hablar. Presentar así a MCP en octubre de 2026 es como vender la tortilla de patatas como un plato exótico, con nombre en la pizarra y precio de sitio nuevo. Nosotros mismos le hemos dedicado una pieza a lo que sí resuelve y otra a cómo soltó la sesión. Pero el miedo del titular viene bien armado.

La historia que cuenta Ars va así. En cinco meses, Google y otras cuatro organizaciones con poco en común, salvo que usan agentes, han reconocido fallos del mismo tipo. Un agente comprometido contagia instrucciones dañinas a los demás de su red, y el segundo obedece porque se fía del primero. Lo remata Douglas McKee, director de inteligencia de vulnerabilidades de Rapid7: "Every piece in that chain did exactly what it was designed to do". Cada pieza hizo lo que debía.

Cinco casas, el mismo bicho y un experto diciendo que nada se rompió: suena a fallo de protocolo, de los que arreglan los mantenedores. Hemos ido a mirar qué arreglaron exactamente esas cinco casas.

Abres los cinco arreglos y no sale ni un agente

El investigador es Syed Anas Mohiuddin, y va por libre. Google, JPMorgan Chase, Weaviate, la DINUM francesa (la dirección interministerial de lo digital) y el ayuntamiento indonesio de Tangerang confirmaron y arreglaron lo que les reportó. Lo cuenta en su informe de octubre, y en los cinco casos es lo mismo: una SSRF en un servidor MCP. Ninguno de los arreglos va de un agente pasándole órdenes a otro.

SSRF (server-side request forgery) es de los fallos más viejos de la web. Consigues que un servidor haga peticiones por ti adonde tú no llegas, como su red interna o el servicio de metadatos de la nube. En AWS, la primera versión de ese servicio, IMDSv1, entrega credenciales sin pedir nada.

Piensa en el servidor MCP como el recadero de la oficina: tiene llave de todos los despachos y va adonde diga la nota. En una web de toda la vida, la nota la rellena un desconocido en un formulario, y en recepción se mira con lupa. Con MCP, explica Mohiuddin, el atacante deja el texto donde el modelo lo va a leer, y es el modelo quien teclea la URL. El servidor ve una petición de su propio modelo y no se pregunta de dónde salió la idea. La nota llega con la letra de la casa. Nadie mira quién la dictó.

Quién	Qué hacía su servidor MCP	Qué le faltaba
Google, mcp-toolbox 0.3.0 a 1.4.0 (severidad 8,0)	Seguía redirecciones sin revisarlas y no validaba la IP de destino	Revisar cada salto y el destino: llegó en la v1.5.0
JPMorgan Chase, servidor de búsqueda de documentación (severidad media)	read_documentation comprobaba una lista blanca; su hermana related() iba a cualquier URL, aunque sin credenciales a bordo	La misma lista blanca en las dos
Weaviate, módulos de Google	El campo apiEndpoint esquivó dos rondas de endurecimiento pensadas para baseURL	Limitar apiEndpoint a los hosts de la API de Google, que es lo que hicieron
DINUM, servidor MCP oficial de data.gouv.fr	Iba a buscar URLs que ponían los productores de datos, aunque apuntaran a la red interna o a metadatos de la nube	Validar la IP al conectar y revisar cada redirección, que es lo que añadió el arreglo
Ayuntamiento de Tangerang, Wazuh MCP	Presumía de protección SSRF, pero solo rechazaba IPs escritas a pelo y nunca resolvía nombres	Resolver el nombre y comprobar la IP real

Rapid7 arregló un sexto fallo, distinto, que también encontró él: una inyección GraphQL en su Bulk Export MCP, de severidad 2,7 sobre 10. Apúntate el detalle, porque McKee trabaja en esa casa.

Tenían conserje, pero miraba otra puerta

Google es el caso fácil: no revisaba nada. El cliente HTTP de Go sigue las redirecciones por su cuenta, y sin una política que las controle el toolbox no podía mirar cada salto. Es el mensajero que comprueba la dirección del paquete y, cuando en el portal le dicen "súbelo al ático de enfrente", lo sube sin rechistar.

Lo revelador es que en al menos tres de los cinco casos había control, y vigilaba la puerta equivocada.

JPMorgan tenía dos ventanillas en la misma sucursal. En una te pedían el DNI, y en la de al lado atendían a quien trajera una dirección apuntada en un papel. Y el agujero no venía de serie, porque el proyecto de AWS del que bifurcaron el componente ni siquiera iba a buscar la URL del que llamaba. La segunda ventanilla la abrieron ellos al adaptarlo. Eso sí, la petición falsificada no llevaba credenciales encima, y Mohiuddin le pone severidad media.

Weaviate ya lo había arreglado. Dos veces. Blindó el campo baseURL en dos rondas que cubrían 21 constructores de URL, pero los módulos de Google llamaban a ese campo apiEndpoint. Cambiaron la cerradura del portal y se dejaron abierto el garaje porque en el plano ponía "acceso vehículos". Por ahí salían la clave de la API de Google del operador o su token OAuth de GCP, camino de un servidor del atacante. Bastaba con poder lanzar una consulta GraphQL.

En Tangerang, el conserje tiene orden de no abrirle al del cuarto B. Llega uno, dice que es Manolo y le abre. Manolo vive en el cuarto B. La herramienta rechazaba la IP escrita a pelo, pero dejaba pasar cualquier nombre DNS que apuntara a una dirección privada o de metadatos.

Todos sabían lo que es una SSRF. Pusieron el control donde creían que entraba lo de fuera, y lo de fuera entró por la puerta que daban por de casa.

La advertencia viene en la caja

Si el fallo fuera del protocolo, la primera en tenerlo arreglado sería la propia casa de MCP. Vamos a la casa.

En mayo, Mohiuddin avisó en la lista Full Disclosure de dos servidores que aceptaban cualquier URL del agente, sin lista blanca ni bloqueo de rangos internos. Uno es mcp-server-fetch, el servidor de referencia del propio proyecto MCP. El otro, playwright-mcp, de Microsoft. Su cadena de ataque es de libro: una web con una instrucción escondida manda al agente a la dirección de metadatos, y las credenciales acaban en su respuesta. Mohiuddin no puede confirmar que ninguno de los dos se haya arreglado, y lo de Microsoft no tiene CVE ni confirmación del fabricante.

Lo mejor es que el README del fetch ya lo avisa: "This server can access local/internal IP addresses and may represent a security risk". Es el paquete de tabaco: la advertencia en grande y el producto a la venta igual.

Eso sí, el detalle más jugoso de esta parte viene inflado. Mohiuddin cuenta que el fetch tiene una guardia que la ruta get_prompt se salta. Pero esa función mira el robots.txt, no si la IP es interna. Y la ruta que se la salta es la manual, la que lanza el usuario desde su interfaz. Él mismo, en Full Disclosure, la llama guardia del robots.txt. El agujero de verdad es más tonto y está impreso en la caja.

La especificación tampoco va a rescatarte, y lo dice ella misma: "MCP itself cannot enforce these security principles at the protocol level". Les toca a los implementadores. Su guía de buenas prácticas trae un apartado de SSRF, pero mira hacia otro lado. Va del cliente al que un servidor malicioso le planta URLs durante el descubrimiento de OAuth, no del servidor que va adonde le dicta el modelo. Es el estándar del enchufe Schuko: define cómo encaja la clavija y no impide que el electricista te deje un cable pelado detrás del armario.

MCP vive desde diciembre de 2025 en la Agentic AI Foundation de la Linux Foundation, pero deciden los mismos mantenedores. Y hay precedente. Cuando OX Security llamó sistémico al fallo del transporte STDIO, Anthropic pidió cautela en su SECURITY.md, no tocó la arquitectura y dejó una sola palabra on the record: "expected". Esperado. Ni una coma más.

Dice mi madre que me lo fíes

Queda el monstruo del titular. Mohiuddin lo llama protocol pivoting. En su ejemplo, el atacante cuela en la respuesta de una herramienta MCP un texto con forma de tarea de A2A, el protocolo de Google para delegar entre agentes. El orquestador se lo pasa a un subagente como un encargo normal, y el subagente lo ejecuta porque se fía de él. Fíjate en un detalle que el titular se come: aquí el protocolo de agente a agente es A2A, y MCP es el enchufe entre el modelo y sus herramientas.

Es el crío que llega a la panadería con un dice mi madre que me lo fíes. El panadero conoce al crío y a la madre, así que lo apunta en la cuenta. Y aquí la cuenta existe, porque los servidores MCP guardan las credenciales de cada agente. Nadie comprueba si la madre dijo nada. A2A resuelve la primera mitad: el agente que recibe sabe quién le habla, con OAuth2 u OpenID Connect anunciados en la Agent Card. La segunda mitad se la deja a cada uno, porque la autorización depende de la implementación de cada agente. El protocolo te dice quién trae el recado. Quién lo escribió, no.

McKee lo cuenta con otra imagen: cada protocolo se hizo como si viviera solo, así que cada uno vigila su puerta y nadie mira el pasillo. El búfalo, que ha montado sistemas donde varios agentes se reparten el trabajo, vigila ese pasillo sin fe. En sus montajes reparte el trabajo un programa, no un modelo. Lo que un agente entrega a otro viaja en un formato comprobable, y el que revisa repite las pruebas en vez de creerse el parte del compañero.

Ahora la letra pequeña. Este salto entre agentes está descrito en un preprint de mayo y en un borrador informativo que Mohiuddin ha presentado en el IETF. En lo que hemos leído no consta demostrado contra un sistema real, y los cinco arreglos confirmados son SSRF de una sola pieza. El titular vende como reconocida por cinco organizaciones la hipótesis más ambiciosa del investigador. Hipótesis con traje de hecho.

Ni el nombre convence a todos. Markus Vervier, de X41 D-Sec, lo llama prompt injection indirecta y dice que el salto entre protocolos no hace falta para que el ataque funcione. Es la discusión del falso nueve: táctica nueva o delantero de toda la vida que baja a recibir. McKee le da la razón a medias: debajo hay inyección y SSRF de las de siempre, con arreglos que no han cambiado en 20 años. Pero agradece el nombre, porque es lo que hace que defensores y organismos de estándares diseñen para ello.

La apuesta que sí ganó el investigador

Hasta aquí, el humo. Ahora lo que aguanta, que es bastante. Y duele más que el monstruo, porque esto sí ha pasado por caja.

En mayo, Mohiuddin apostó que si el fallo era estructural aparecería en servidores de equipos que no comparten código, sector, país ni dueño. En octubre tenía un hiperescalar, un banco, un gobierno nacional, una base de datos vectorial y una ciudad indonesia. Para él, ver volver el mismo error informe a informe sacó su argumento de mayo del terreno de las suposiciones. En eso Ars acierta: es estructural. La misma gotera en cinco fincas que no se saludan en el portal.

Y la cola que el titular no cuenta es peor. El 2 de septiembre reportó en privado cinco servidores MCP federales de EE. UU., que según él siguen sin arreglar. El de prestaciones de Veteranos vuelca en los logs las respuestas de error completas de la API. Ahí pueden ir el nombre del veterano, su número de la Seguridad Social, su fecha de nacimiento y su dirección. Es el camarero que, cuando falla el datáfono, apunta el número de la tarjeta en la libreta de las comandas. Mohiuddin achaca esto y la SSRF a la misma suposición: lo que cruza la frontera de MCP es de fiar porque viene de dentro.

Y tu escáner de dependencias no lo va a ver. El dato peligroso llega como argumento de una herramienta, descrito en un manifiesto que el escáner nunca lee. Es el vigilante que revisa el DNI en la puerta y no abre la mochila. Y Mohiuddin admite que las herramientas que buscan patrones, la suya incluida, se dejan una buena parte.

El recadero lo contrataste tú

Cuánto humo había: el monstruo del titular, agentes que se contagian órdenes por un fallo de MCP, es la parte menos demostrada. Lo confirmado es más aburrido y bastante peor. Es un fallo de los de siempre, que equipos sin nada en común repiten porque dan por hecho que lo que llega por dentro es de casa.

Peor, porque un fallo de protocolo lo parchean los mantenedores, actualizas y a correr. Este se arregla servidor a servidor y agente a agente, o no se arregla. ¿Podría hacer más la casa de MCP? Sí. El borrador de Mohiuddin exige que los servidores traten como no fiables todos los parámetros de las llamadas a herramientas. Y el fetch de la casa podría salir con filtro en vez de con cartel. Culpable no es, pero libre de pecado tampoco. Aunque ese MUST acabe en la especificación, la petición la seguirá haciendo tu cliente HTTP.

Lo que haríamos el lunes con nuestros servidores MCP:

• Lo que pasa el modelo viene de un desconocido. McKee lo dice tal cual: trata lo que va del LLM a tu herramienta como input de un extraño de internet. En una prompt injection, eso es exactamente lo que es.
• Comprueba el destino, no el texto. Resuelve el nombre, mira la IP final y revisa cada redirección. Bloquear la IP de metadatos escrita a pelo se esquiva con una redirección o con DNS rebinding. El rebinding es un nombre que resuelve a una IP pública cuando validas y a una interna cuando conectas. Google acabó con guardia contra DNS rebinding, rangos permitidos y bloqueados, y la URL base validada al arrancar.
• El bloqueo, donde no dependa de acordarse. En tres de los cinco casos, el control se lo saltó una herramienta hermana, un campo con otro nombre o un nombre DNS. El búfalo solo se cree un bloqueo si lo sostiene el aislamiento del sistema operativo; una comprobación en el código, sola, no le basta. Para la SSRF, lo equivalente es cortar la salida en la red: un cortafuegos no sabe cómo se llama tu campo.
• La credencial, atada a su destino. La del operador de Weaviate viajaba adonde apuntara un campo que cambiaba cualquiera con permiso de lectura.
• Entre agentes, autentica al que habla y desconfía de lo que trae. El búfalo deja que el modelo elija, pero lo que tiene efectos fuera lo ejecuta código con sus pasos fijados, sin atajos. Es lo mismo que defendimos con los pagos agénticos.

El titular buscaba al monstruo dentro del protocolo. Lo que hay es un recadero con llave de todos los despachos que obedece cualquier nota con la letra de la casa. Lo contrataste tú, y a ese no lo despide ningún comité de la Linux Foundation.