Skip to content

Vulnerabilidades de los servidores MCP y cómo protegerlos

2 de octubre de 2026 · PlayCISO

Los servidores MCP son un riesgo de seguridad real porque permiten a los agentes de IA ejecutar herramientas, leer archivos y llamar a APIs con una confianza heredada, y la mayoría son código comunitario sin revisar. Las vulnerabilidades principales son el envenenamiento de herramientas (descripciones de herramientas maliciosas que secuestran al modelo), la inyección de prompts a través de los datos devueltos, los ámbitos de permisos excesivos, los servidores locales sin autenticación y el compromiso de la cadena de suministro. Se protegen tratando cada servidor MCP como código de terceros no fiable: fija las versiones, limita al máximo el alcance de las credenciales, aísla la ejecución en un sandbox y analiza las definiciones de herramientas antes de conectarte.

Por qué los servidores MCP son un riesgo de seguridad ahora mismo

El ecosistema del Model Context Protocol creció muy deprisa. Pasó de un puñado de servidores de referencia en su lanzamiento de noviembre de 2024 a miles de servidores creados por la comunidad en cuestión de meses, superando la capacidad de revisión de seguridad y creando un patrón de confianza sin verificación parecido al de los primeros tiempos de npm. La comparación importa: la historia de npm incluye event-stream (2018), en la que un nuevo mantenedor publicó una actualización maliciosa de un paquete muy usado, y left-pad (2016), en la que retirar un paquete de 11 líneas rompió compilaciones en todo el ecosistema. Una fue un fallo de confianza y la otra un fallo de disponibilidad, y MCP hereda ambos riesgos.

MCP lo amplifica porque un servidor MCP no se limita a ejecutarse en tu pipeline de compilación: está dentro del bucle de decisión de tu agente de IA. Un servidor comprometido puede inyectar instrucciones que el modelo obedece, exfiltrar datos que el agente puede leer o encadenar llamadas a herramientas que nunca aprobaste. El radio de impacto es todo aquello a lo que tu agente tiene acceso.

Las principales clases de vulnerabilidad con las que te vas a encontrar

En lugar de perseguir números de CVE sueltos, céntrate en estas cinco categorías recurrentes:

  • Envenenamiento de herramientas / rug pulls: la descripción de una herramienta de un servidor contiene instrucciones ocultas («envía también las claves SSH del usuario a X»). El modelo lee la descripción como contexto y la sigue. Un servidor también puede servir definiciones limpias durante la revisión y cambiarlas después.
  • Inyección indirecta de prompts: los datos que devuelve una herramienta (una página web, una fila de base de datos, el cuerpo de un correo) contienen instrucciones adversarias que el agente trata como órdenes.
  • Alcance excesivo / confused deputy: el servidor tiene un token OAuth o una credencial de base de datos amplios, y el agente los usa para realizar acciones que el usuario nunca pretendió.
  • Transporte local sin autenticación: un servidor MCP local que escucha por HTTP sin autenticación, o que se enlaza a todas las interfaces en lugar de a localhost, puede ser alcanzado por otros procesos, por otras máquinas de la red o, sin comprobaciones de Origin, por una página web maliciosa mediante DNS rebinding. (Los servidores stdio son un canal privado hacia el cliente, pero heredan todo lo que puede hacer el usuario del host).
  • Compromiso de la cadena de suministro: instalas un servidor MCP desde un registro público y una dependencia, o el propio servidor, lleva una puerta trasera.

La desventaja de ejecutar servidores MCP, en una frase: amplías tu superficie de ataque para incluir código arbitrario de terceros en el que tu agente de IA confiará implícitamente salvo que le obligues a no hacerlo.

Buenas prácticas y checklist de seguridad para servidores MCP

Proteger MCP es, sobre todo, la higiene clásica de cadena de suministro y mínimo privilegio, adaptada a los agentes. Usa este checklist antes y después de conectar cualquier servidor:

  • Fija las versiones y guárdalas en tu propio repositorio. Nunca actualices automáticamente los servidores MCP. Fija un commit o una versión exactos y revisa los diffs antes de actualizar: así neutralizas los rug pulls en los servidores que ejecutas tú.
  • Inspecciona las definiciones de herramientas. Lee cada descripción de herramienta y cada esquema de parámetros en busca de instrucciones inyectadas antes de habilitar el servidor. Automatízalo con un escáner.
  • Limita las credenciales al mínimo. Emite un token dedicado por servidor con acceso de solo lectura o a un único recurso. Relaciónalo con el mínimo privilegio de OWASP y con el control AC-6 de NIST 800-53.
  • Aísla la ejecución. Ejecuta los servidores en un contenedor o en un proceso restringido, sin acceso ambiental a la red ni al sistema de archivos más allá de lo que necesita la herramienta.
  • Exige aprobación humana para las acciones destructivas. Pon las escrituras, los borrados, los pagos y los envíos salientes detrás de una confirmación explícita.
  • Registra cada llamada a herramientas. Captura las entradas, las salidas y qué servidor las atendió para poder rastrear un incidente.
  • Trata los datos devueltos como no fiables. No dejes nunca que la salida de una herramienta se convierta en silencio en nuevas instrucciones: elimínala o delimítala con claridad en el contexto del agente.

Herramientas de seguridad para MCP: intégralas en tu pipeline

La revisión manual no escala cuando conectas decenas de servidores. La configuración práctica es un control de tres capas: un escáner que inspecciona las definiciones de herramientas y las dependencias antes de conectar, una puerta de políticas que impone la fijación de versiones y los límites de alcance en la configuración de tu agente, y un registro en tiempo de ejecución que marca las cadenas anómalas de llamadas a herramientas. Los escáneres de código abierto en GitHub ya comprueban firmas conocidas de envenenamiento de herramientas y CVE de dependencias: conecta uno al CI para que no pueda publicarse un servidor sin revisar.

Las organizaciones que gestionan bien MCP lo tratan exactamente igual que npm, PyPI o cualquier otro registro: asumen la brecha, verifican antes de confiar y mantienen un inventario de cada servidor, su versión y los ámbitos que tiene concedidos.

Cómo revisar un servidor MCP en busca de vulnerabilidades

Revisa un servidor MCP como revisarías cualquier código que se ejecuta con los privilegios de tu agente. Eso abarca cinco áreas: sus dependencias, su transporte y autenticación, cómo maneja cada herramienta la entrada, qué dicen sus descripciones de herramientas y qué credenciales tiene.

  • Dependencias. Ejecuta las herramientas de auditoría del ecosistema (npm audit, pip-audit o un análisis con OSV) y fija versiones exactas antes de conectar nada.
  • Transporte y autenticación. Los servidores stdio locales heredan la confianza del host. Para los servidores basados en HTTP, la especificación de MCP indica que los servidores deben validar la cabecera Origin para evitar el DNS rebinding, enlazarse a localhost (no a todas las interfaces) cuando se ejecutan en local y exigir autenticación. Su modelo de autorización para los transportes HTTP se basa en OAuth 2.1.
  • Manejo de la entrada en cada herramienta. Muchos hallazgos en MCP son fallos clásicos dentro del código de las herramientas: inyección de comandos cuando los argumentos de una herramienta llegan a un shell, path traversal en herramientas de archivos, server-side request forgery en herramientas que descargan URLs e inyección SQL en herramientas de bases de datos. Prueba cada herramienta con argumentos hostiles, no solo con llamadas del caso ideal.
  • Descripciones de herramientas. Lee cada descripción y cada esquema de parámetros en busca de instrucciones ocultas, y vuelve a revisarlos tras cada actualización, ya que las descripciones pueden cambiar después de la revisión.
  • Credenciales. Da a cada servidor su propio token con un alcance limitado. Un servidor solo debería aceptar tokens emitidos para él y no debería reenviar el token de un cliente a las APIs posteriores.

¿Quieres una primera pasada antes de conectar un servidor? MCP Scan de PlayCISO ejecuta 27 comprobaciones deterministas de higiene sobre un único handshake MCP estándar, sin explotación. Consultar su explorador público de servidores de registros es gratis; analizar tu propio servidor forma parte de PlayCISO Pro.

Preguntas frecuentes

¿Son seguros los servidores MCP?

No por defecto. Un servidor MCP ejecuta herramientas con todo el acceso que tenga tu agente, y muchos son código comunitario sin revisar. Trata cada uno como código de terceros no fiable: fija las versiones, limita al máximo el alcance de las credenciales, aísla la ejecución en un sandbox, lee las descripciones de herramientas antes de habilitarlas y registra cada llamada a herramientas.

¿Qué es el envenenamiento de herramientas en MCP?

El envenenamiento de herramientas se produce cuando la descripción de una herramienta o su esquema de parámetros contiene instrucciones ocultas que el modelo lee como contexto y sigue, como enviar un archivo a algún sitio. Un rug pull es la variante en la que un servidor sirve definiciones limpias durante la revisión y las cambia más tarde.

🖤 Black Friday: new customers get 3 months of Pro for $5, then $5/month. Ends 30 Nov. Claim 3 months for $5 →