SUPPLY CHAIN MEDIUM NEW

Uno de cada tres servidores MCP es una puerta SSRF a los metadatos de tu nube

Dos análisis de ecosistema publicados en 2026 encuentran server-side request forgery en buena parte de los servidores MCP públicos — y muestran que las estrellas, la actividad y las insignias de «verificado» no predicen cuáles son seguros.

2026-07-08 // 6 min affects: mcp-protocol, markitdown-mcp, third-party-mcp-servers

¿Qué es esto?

El Model Context Protocol (MCP) es el tejido conectivo entre los agentes de IA y el mundo exterior: sistemas de archivos, bases de datos, API y servicios en la nube. Dos esfuerzos de medición independientes publicados en 2026 sugieren ahora que una porción considerable del ecosistema MCP público incorpora la misma clase de vulnerabilidad web que aqueja al software de servidor desde hace una década: el server-side request forgery (SSRF).

Trend AI Security analizó 9 695 servidores MCP en GitHub, Glama, Lobehub y PulseMCP; los resultados se difundieron el 7 de julio de 2026. El estudio halló 5 832 servidores con problemas de seguridad y 2 259 confirmados como explotables más allá de simples ausencias de autenticación, catalogando 4 982 problemas distintos, entre ellos 422 fallos SSRF, 880 de acceso arbitrario a archivos, 476 de inyección de comandos y 185 casos de inyección de prompts. Por su parte, el análisis de BlueRock, en enero de 2026, sobre más de 7 000 servidores de su MCP Trust Registry, informó que más del 36,7 % presentaba una exposición potencial a SSRF («recuperación de red sin restricciones»). Corpus distintos, mismo mensaje: el SSRF no es un caso marginal en el mundo MCP, es la línea de base.

Cómo funciona

Un servidor MCP es más que un gestor de solicitudes. Cuando un agente invoca una de sus herramientas, el servidor actúa: recupera URL, lee archivos, ejecuta código. El SSRF aparece cuando una herramienta acepta un argumento de URL o de host y lo recupera sin validación.

El ejemplo desarrollado por BlueRock es el servidor MCP MarkItDown de Microsoft — un conversor de documentos a Markdown, con unas 85 000 estrellas en GitHub. Su herramienta convert_to_markdown acepta una URI arbitraria y la recupera sin restricción de esquema ni de host. En una instancia AWS EC2 que aún usa el servicio de metadatos heredado IMDSv1, un agente (o un atacante capaz de dirigir al agente) puede apuntar esa herramienta al endpoint de metadatos de la nube:

convert_to_markdown("http://169.254.169.254/latest/meta-data/iam/security-credentials/")
# → devuelve el nombre del rol IAM asociado
# añadir el nombre del rol a esa ruta → clave de acceso, clave secreta, token de sesión

Esas credenciales devueltas pueden luego reproducirse contra la API de la nube, otorgando un acceso a la cuenta limitado al rol de la instancia — y, según ese rol, un camino de escalada de privilegios en la cuenta. El punto crítico es arquitectónico: esta exposición vive en la capa de ejecución de herramientas, por debajo de la frontera de solicitud que inspeccionan las pasarelas MCP. Una pasarela puede dejar pasar una solicitud de apariencia válida y aun así permitir que el servidor exfiltre credenciales durante la ejecución.

Por qué importa

El hallazgo más incómodo tiene que ver con las señales de confianza. El escaneo de Trend AI Security no encuentra correlación significativa entre la popularidad de un servidor y su seguridad: los servidores muy populares (50 estrellas o más) suelen conllevar el mayor riesgo porque su radio de impacto es mayor, la actividad de commits no predice la seguridad, y las insignias de «verificado» de los directorios apenas mueven la aguja — los servidores verificados muestran un número medio de vulnerabilidades casi idéntico al de los no verificados. Las heurísticas a las que los equipos recurren por instinto al elegir una dependencia — estrellas, actividad, una marca de verificación — carecen aquí casi por completo de valor como indicadores de seguridad.

Como los servidores MCP suelen ejecutarse con los privilegios del usuario o la carga de trabajo que los lanzó, un fallo de SSRF o de acceso a archivos rara vez queda confinado a la herramienta. Es un pivote hacia todo lo que esa identidad pueda alcanzar: metadatos de la nube, servicios internos, secretos. Cuando el mismo servidor popular se despliega en muchas organizaciones, un solo fallo se vuelve sistémico — lo que BlueRock y los autores del escaneo describen como severidad ponderada por el alcance.

Defensas

Trate cada servidor MCP de terceros como código no confiable que se ejecuta dentro de su perímetro de confianza, y limite lo que sus herramientas pueden recuperar:

Allowlist de salida. Restrinja las recuperaciones de las herramientas a una allowlist explícita de esquemas/hosts (por ejemplo, solo https:// hacia dominios aprobados) en lugar de una blocklist.
Bloquee los objetivos internos. Deniegue los rangos RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), el loopback, el enlace local y la IP de metadatos de la nube 169.254.169.254.
Neutralice el DNS rebinding. Resuelva el nombre de host y compruebe la IP resuelta contra la denylist antes de conectar, no solo la cadena de texto.
Elimine IMDSv1. Imponga IMDSv2 (token de sesión requerido) en cada instancia; existe precisamente para mitigar el robo de metadatos por SSRF. Combínelo con roles de instancia de mínimo privilegio.
Prefiera stdio, en local. Ejecute los servidores MCP en stdio ligado a localhost en lugar de exponerlos por HTTP; fije tiempos de espera, límites de tamaño de cuerpo y elimine los encabezados Authorization/Cookie reenviados.
Vigile la ejecución, no solo las solicitudes. Observe lo que las herramientas hacen realmente en tiempo de ejecución; la inspección solo a nivel de pasarela pasa por alto la capa donde se dispara esta clase de fallo.
Abandone las heurísticas de confianza. No trate las estrellas, la velocidad de commits o una insignia de verificación como una señal de seguridad. Audite el código o escanee el servidor antes de conectarlo.

Estado

Elemento	Detalle
SSRF de MarkItDown MCP	Reportado a Microsoft y AWS en noviembre de 2025; ambos respondieron que hay soluciones alternativas disponibles. Divulgación pública en enero de 2026. Sin CVE asignado.
Prevalencia de SSRF en el ecosistema	BlueRock: > 36,7 % de 7 000+ servidores (ene. 2026). Trend AI Security: 422 SSRF entre 4 982 problemas en 9 695 servidores (7 jul. 2026).
Mitigación	IMDSv2, allowlist de salida y monitoreo en la capa de ejecución disponibles hoy; la brecha es la adopción.

Fuentes: el estudio «Stars Don’t Save You» de Trend AI Security sobre el ecosistema MCP (difundido el 7 de julio de 2026) y la divulgación «MCP fURI» de BlueRock sobre el servidor MarkItDown de Microsoft (enero de 2026).