Cinco equipos de Google, JPMorgan, Weaviate y dos administraciones corrigieron fallos SSRF en servidores MCP; el patrón revela riesgos de diseño.
Google, JPMorgan Chase, Weaviate, la dirección digital interministerial francesa (DINUM) y el ayuntamiento de Tangerang, en Indonesia, corrigieron fallos del mismo tipo en sus servidores del Model Context Protocol (MCP). El investigador independiente Syed Anas Mohiuddin informó de los cinco casos. La vulnerabilidad es SSRF: el servidor acepta una dirección proporcionada por quien controla al agente y realiza una petición saliente sin comprobar adecuadamente a qué destino conduce.

La consecuencia importa porque el servidor puede tener acceso a redes internas o a servicios de metadatos en la nube. Si alguien consigue que la herramienta consulte una URL controlada, o un nombre que resuelve hacia un destino sensible, la petición sale desde la infraestructura del servidor. El problema no es MCP en sí, sino que una herramienta conectada puede convertirse en un intermediario con más alcance del debido.
El caso de Google ilustra varios controles ausentes. Su MCP Toolbox for Databases no tenía una política restrictiva de redirecciones ni verificaba las IP de destino; un parámetro de ruta manipulado podía dirigir las peticiones a endpoints internos o externos. La vulnerabilidad, CVE-2026-14540, recibió una puntuación alta de 8,0 y afectaba a las versiones de la 0.3.0 a la 1.4.0. El arreglo añade defensas frente a DNS rebinding y listas de rangos permitidos y bloqueados, según el aviso de GitHub.
En JPMorgan, un servidor MCP de búsqueda de documentación tenía dos herramientas que obtenían contenido: una comprobaba los dominios con una lista permitida y la otra aceptaba cualquier URL. Según Mohiuddin, el componente derivaba de un proyecto de AWS que nunca pedía la URL al solicitante. El banco confirmó el hallazgo y desplegó una corrección; el investigador lo calificó de severidad media. La pista práctica es revisar cada punto de entrada, no suponer que una protección cubre todo el servidor.
Los demás casos son variantes de la misma frontera mal definida. Weaviate limitó el endpoint de su módulo de Google a los hosts de las API de Google. El servidor de DINUM para datos abiertos consultaba URLs aportadas por productores de datos, incluidos destinos internos o de metadatos en la nube. En Tangerang, una herramienta anunciaba protección pero solo rechazaba IP literales y nunca resolvía nombres de host, según el aviso de alta severidad.
Mohiuddin llama «protocol pivoting» a una clase de ataque más amplia: contenido devuelto por una herramienta MCP puede tener forma de tarea para el protocolo A2A de Google; el agente coordinador se la pasa a un subagente, que la ejecuta porque confía en quien la transmite. Ars Technica recoge que cada eslabón hace lo que fue diseñado para hacer, y por eso es difícil de detectar. No es SSRF, pero recuerda que los límites de confianza atraviesan varias herramientas.
La lista no está cerrada. Mohiuddin informó de cinco servidores MCP de servicios tecnológicos del Gobierno de Estados Unidos que siguen en evaluación y sin parche; en el de prestaciones para veteranos, los registros guardan respuestas de error completas con datos personales. También sigue abierto su informe sobre un servidor de subvenciones de la Agencia Digital de Japón sin autenticación. Presentará los hallazgos en MCPCon North America el 23 de octubre, según su actualización.
Nos quedamos con el coste oculto de estas integraciones: cada llamada añade una ruta de red y una frontera de confianza que alguien debe mantener. Para quien opera agentes, las listas de destinos, la resolución DNS y las redirecciones forman parte de la fiabilidad. Cinco correcciones independientes no prueban que todo MCP esté roto, pero sí que este patrón es fácil de repetir y merece controles compartidos y pruebas específicas.
Fuente original: thenextweb.com
Elaborado con apoyo de IA y revisado por la redacción



Comentarios
Publicar un comentario