Los servidores MCP son la nueva superficie de ataque

El Model Context Protocol ahora tiene una base de datos de seguridad. Cuenta con 50 entradas.¹

Se registraron treinta CVE en 60 días. Entre las 2.614 implementaciones de MCP analizadas, el 82% presentaba vulnerabilidades en operaciones de archivos propensas a path traversal. Entre el 38% y el 41% de los servidores carecían por completo de autenticación.² La herramienta oficial MCP Inspector —la que los desarrolladores usan para depurar servidores MCP— tenía una vulnerabilidad de RCE. El paquete ampliamente utilizado mcp-remote tenía un bug de inyección de comandos de sistema operativo.¹

No se trata de una superficie de ataque teórica. Son CVE reales en paquetes reales que desarrolladores reales están conectando a Claude Code, Codex CLI y Cursor en este mismo momento. Esta publicación amplía el territorio de la seguridad de agentes con análisis de amenazas a nivel de protocolo.

TL;DR

Los servidores MCP son la superficie de integración de más rápido crecimiento en el ecosistema de agentes. También son la menos auditada. La base de datos de vulnerabilidades tiene 50 entradas: 13 críticas, 32 altas. Las fallas de validación de entrada y la inyección de prompts suman 30 de las 50. Esta semana surgieron tres vulnerabilidades de SSRF en tres servidores MCP distintos en un solo día.³ El patrón es claro: la comunidad está publicando servidores MCP más rápido de lo que los revisa.

Conclusiones clave

• Usuarios de Claude Code: Cada servidor MCP que conectas es un límite de confianza que estás extendiendo. Ejecuta claude mcp list ahora mismo y audita lo que tienes conectado. Si estás ejecutando servidores MCP comunitarios que instalaste hace meses, verifica si han sido parchados desde entonces.
• Constructores de harness: Tus hooks de PreToolUse son tu última línea de defensa antes de que una llamada a una herramienta MCP llegue a un servidor no auditado. Considera hooks que validen las entradas de herramientas MCP antes de la ejecución, especialmente para servidores que aceptan URL, rutas de archivos o comandos de shell.
• Autores de servidores MCP: La especificación de MCP dice que “DEBERÍA haber siempre un humano en el proceso”. Trátalo como DEBE. Valida todas las entradas. Nunca pases cadenas controladas por el usuario a comandos de shell mediante interpolación de cadenas. Nunca confíes en los valores de $ref en especificaciones de OpenAPI sin validación de URL.

Las cifras

El Vulnerable MCP Project mantiene una base de datos de problemas de seguridad documentados en MCP.¹ El estado actual:

Severidad: 13 críticas, 32 altas, 5 medias.¹ Treinta y dos investigadores de seguridad aportaron hallazgos. Los servidores afectados incluyen el propio servidor Git MCP de Anthropic, el MCP Inspector oficial, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes y más de 20 servidores construidos por la comunidad.¹

El hallazgo del estudio es el más condenatorio: el 82% de las 2.614 implementaciones de MCP presentaba vulnerabilidades en operaciones de archivos propensas a path traversal.² Cuatro de cada cinco servidores MCP permitirán que un atacante lea archivos a los que no debería tener acceso.

Cinco patrones de ataque

La oleada de CVE de 60 días reveló cinco patrones recurrentes:²

1. Envenenamiento de herramientas. Instrucciones maliciosas incrustadas en las descripciones de herramientas MCP. El agente lee la descripción, confía en ella y sigue las instrucciones ocultas usando sus propias herramientas autorizadas. La herramienta envenenada nunca se ejecuta: las herramientas legítimas del agente llevan a cabo el ataque. Cubrimos este patrón en la paradoja de desplegar y defender: la confianza es transitiva, la auditoría no.

2. Inyección de prompts vía datos externos. Los servidores MCP que obtienen contenido desde issues de GitHub, mensajes de Slack, correos electrónicos o páginas web traen texto controlado por el atacante al contexto del agente. La inyección no apunta al servidor MCP, apunta al agente que lee la salida del servidor. La superficie de ataque de exfiltración silenciosa es el caso general; los servidores MCP son el vector más común.

3. Bypass de confianza tras la aprobación inicial. Claude Code te pide aprobar un servidor MCP la primera vez. Después de eso, las definiciones de herramientas pueden cambiar entre sesiones sin volver a solicitar aprobación en todos los casos. Un servidor que era seguro en el momento de la instalación puede comportarse de manera diferente en el momento de la actualización. La brecha de revalidación es estructural: el protocolo no exige la firma criptográfica de las descripciones de herramientas.²

4. Compromiso de la cadena de suministro. Servidores MCP con backdoors publicados en registros, incluyendo paquetes que suplantan a servidores legítimos. El mismo patrón de cadena de suministro que documentamos en la cadena de suministro es la superficie de ataque, aplicado al ecosistema MCP.

5. Exposición entre inquilinos. Entornos de alojamiento compartido donde varios servidores MCP pueden interceptar las llamadas a funciones de otros servidores antes de la ejecución.⁴ Los límites de aislamiento que parecen sólidos desde afuera se desmoronan cuando varios servidores comparten un proceso o contenedor.

El patrón SSRF

Tres vulnerabilidades de SSRF en tres servidores MCP distintos surgieron en un solo escaneo esta semana:³

• n8n-mcp: SSRF autenticado vía inyección de host de instancia
• mcp-from-openapi: SSRF vía valores de $ref en especificaciones OpenAPI. Una especificación maliciosa con URL internas hace que el servidor obtenga esos recursos durante la inicialización
• stata-mcp: Validación insuficiente de URL proporcionadas por el usuario

El SSRF en servidores MCP es especialmente peligroso porque el servidor suele tener acceso a la red del que el agente carece. Así es como una sola especificación OpenAPI maliciosa se convierte en robo de credenciales:

Paso 1. Un atacante publica un servidor MCP de apariencia legítima que envuelve un API externo. El servidor usa mcp-from-openapi para generar herramientas a partir de una especificación OpenAPI.

Paso 2. La especificación OpenAPI contiene un $ref que apunta a una dirección interna:

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

Paso 3. Durante initialize(), el servidor MCP resuelve el $ref obteniendo la URL. El servidor se ejecuta en tu infraestructura: dentro de tu VPC, en tu laptop, en tu contenedor de CI. La solicitud llega al endpoint de metadatos de AWS desde una fuente de confianza.

Paso 4. El endpoint de metadatos devuelve credenciales temporales de IAM: access key, secret key, session token.

Paso 5. El servidor ahora tiene tus credenciales en la nube. Puede exfiltrarlas en respuestas de herramientas, registrarlas en un endpoint externo o usarlas directamente.

El agente nunca hizo nada malicioso. El usuario aprobó el servidor MCP. La especificación OpenAPI parecía normal. La resolución del $ref ocurrió a nivel de biblioteca, por debajo del punto donde alguien revisa. El SSRF convirtió la posición de red del servidor MCP en la posición de red del atacante.

Microsoft parchó un SSRF crítico de Azure MCP (CVE-2026-26118) en marzo de 2026. El mismo patrón se aplicó a Azure: una vulnerabilidad de elevación de privilegios de alta severidad que podía robar tokens de autenticación y otorgar acceso no autorizado a recursos de Azure.⁵

Qué hacer

Audita tus servidores conectados. Ejecuta claude mcp list y revisa cada servidor. Contrasta cada uno con la base de datos del Vulnerable MCP Project.¹ Elimina los servidores que no estés utilizando activamente.

Fija las versiones de los servidores. Si instalas servidores MCP desde npm o pip, fija la versión. No uses actualización automática. Revisa los changelogs antes de actualizar. El patrón de bypass de confianza significa que una actualización puede cambiar las definiciones de herramientas sin volver a solicitar aprobación.

Agrega hooks de validación de entrada. Un hook de PreToolUse en las llamadas a herramientas MCP puede validar las entradas antes de que lleguen al servidor:

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

Considera el aislamiento del transporte. Los patrones de defensa en tiempo de ejecución para agentes con herramientas aumentadas se aplican directamente aquí: cada servidor MCP es una herramienta que el agente invoca, y la arquitectura de defensa debe contemplar herramientas comprometidas. Los servidores MCP HTTP se ejecutan en su propio proceso con límites de red explícitos. Los servidores stdio comparten el contexto de proceso del agente. Ningún transporte es inherentemente seguro. El factor más importante es si el servidor tiene acceso a credenciales, redes internas o rutas de archivos sensibles. Elige el transporte que te dé los límites de aislamiento que requiere tu modelo de amenazas.

Vigila la base de datos. El Vulnerable MCP Project en vulnerablemcp.info es lo más parecido a un rastreador de CVE para el ecosistema MCP. Consúltalo antes de instalar nuevos servidores.

El ecosistema MCP crece rápido: más de 3.000 servidores indexados y 100 millones de descargas mensuales.⁶ La postura de seguridad no crece al mismo ritmo. Cincuenta vulnerabilidades en una base de datos que no existía hace un año. El protocolo no es el problema. Las implementaciones sí. Y como documenté en tu agente tiene un intermediario, cada intermediario en la cadena de herramientas del agente es una oportunidad de interceptación que la mayoría de los desarrolladores nunca audita.

Fuentes

Preguntas frecuentes

¿Los servidores MCP integrados con Claude Code están afectados?

Las vulnerabilidades afectan principalmente a servidores MCP construidos por la comunidad y de terceros, no a la infraestructura MCP central de Claude Code. Sin embargo, la herramienta oficial MCP Inspector sí tuvo una vulnerabilidad de RCE, así que “oficial” no significa “inmune”.

¿Debería dejar de usar servidores MCP?

No. MCP es una capa de integración poderosa. Pero trata cada servidor MCP como un límite de confianza. Audita lo que tienes conectado, fija versiones y agrega hooks de validación de entrada para servidores que acepten URL, rutas de archivos o comandos de shell.

¿Cómo verifico si mis servidores MCP son vulnerables?

Ejecuta claude mcp list para ver tus servidores conectados. Contrasta cada uno con la base de datos del Vulnerable MCP Project. Revisa el repositorio GitHub del servidor en busca de avisos de seguridad recientes.