Seguridad en Servidores MCP: Ataques Reales y Defensas en 2026

Un desarrollador abre un repositorio con Claude Code. No ejecuta nada. No aprueba ninguna acción. En ese instante, un atacante remoto ya está corriendo comandos en su computadora. Este caso, documentado en febrero de 2026, es solo un síntoma. La verdadera historia es que la seguridad en servidores MCP se convirtió en 2026 en la superficie de ataque más grande que ha creado la inteligencia artificial hasta ahora.

En esta guía vas a entender qué es MCP, por qué se convirtió en el eslabón débil de todos los agentes de inteligencia artificial, cuáles son las cinco clases de ataque activas hoy, los casos reales que ya sacudieron a la industria, y las cinco capas de defensa que sí funcionan en producción.

¿Qué es MCP y por qué importa para la ciberseguridad? #

Definición del Model Context Protocol

MCP son las siglas en inglés de Model Context Protocol, en español Protocolo de Contexto de Modelo. Es un estándar abierto creado por Anthropic en noviembre de 2024 con un propósito muy concreto: permitir que un modelo de inteligencia artificial se conecte con herramientas, datos y servicios externos siguiendo un mismo lenguaje.

Antes de MCP, cada aplicación de inteligencia artificial se conectaba a cada herramienta a su manera. Un plugin para leer correo, otro para acceder a un repositorio, otro para consultar una base de datos. MCP unificó ese ecosistema. Hoy, cuando un agente basado en Claude, ChatGPT o cualquier otro modelo necesita leer un archivo, enviar un correo o modificar código, lo hace a través de un servidor MCP.

Arquitectura básica en tres piezas

Toda comunicación por MCP funciona con tres componentes:

+------------------+       +------------------+       +---------------------+
|  HOST / CLIENTE  | <---> |  SERVIDOR MCP    | <---> |  RECURSO EXTERNO    |
|  (Claude,        |       |  (código que     |       |  (GitHub, correo,   |
|  Cursor, etc.)   |       |  expone tools)   |       |  base de datos)     |
+------------------+       +------------------+       +---------------------+

• Host o cliente: la aplicación de inteligencia artificial que usa el usuario final (Claude Desktop, Cursor, un editor de código con agente).
• Servidor MCP: un programa intermedio que declara qué herramientas ofrece y sabe cómo ejecutarlas.
• Recurso externo: el sistema real al que el servidor conecta (un repositorio en GitHub, una bandeja de correo, una base de datos).

El punto crítico para la ciberseguridad es este: el modelo no habla directamente con GitHub o con la base de datos. Habla con un servidor MCP intermedio. Y ese servidor es código escrito por un tercero.

Curso recomendado

OpenClaw — Agentes de IA Seguros y Autónomos

Aprende a diseñar agentes con OpenAI aplicando buenas prácticas de seguridad desde el día uno.

La adopción explosiva en 2026

En menos de dieciocho meses, MCP pasó de propuesta a estándar de facto. Fue adoptado por Anthropic, OpenAI, Google y Microsoft. En 2026 existen más de siete mil servidores MCP públicos registrados. Según Gartner, para fin de 2026 el cuarenta por ciento de las aplicaciones empresariales tendrá agentes de inteligencia artificial integrados. La organización promedio ya maneja treinta y siete agentes desplegados, un número que crece cada trimestre.

Esta velocidad de adopción tiene una consecuencia directa que casi nadie está midiendo: cada servidor MCP conectado a un agente es una puerta nueva abierta al sistema. Y cada puerta se puede convertir en un vector de ataque.

La nueva ecuación de riesgo de los agentes de IA #

Cuando conectas un servidor MCP a tu agente, estás haciendo tres cosas al mismo tiempo:

1. Estás ejecutando código de terceros con los permisos que le concedas.
2. Estás confiando en un endpoint externo sin haber validado su comportamiento.
3. Estás abriendo un canal directo por donde ese servidor puede introducir texto e instrucciones dentro del contexto del modelo.

Y hay una regla adicional que define toda la disciplina de la seguridad MCP: el radio de impacto de un ataque no se limita al servidor comprometido. Es igual a la suma de los permisos de todos los servidores conectados al mismo agente. Si uno cae, todos caen.

Este comportamiento es lo que convierte a MCP en un problema de cadena de suministro, no solo de aplicación. Y esa diferencia importa, porque las defensas tradicionales de aplicación no bastan para contenerlo.

Las 5 clases de ataque a servidores MCP documentadas en 2025-2026 #

La comunidad de seguridad ha catalogado y nombrado cinco clases de ataque específicas de MCP entre 2025 y 2026. Todas tienen casos reales, todas están activas hoy.

1. Prompt injection a través de respuestas de herramientas

En inglés, prompt injection significa inyección de instrucciones. El ataque funciona así:

• El modelo llama a una herramienta legítima (leer un correo, consultar un ticket).
• La herramienta devuelve datos que contienen instrucciones ocultas.
• El modelo interpreta esas instrucciones como si fueran órdenes del usuario.

Ejemplo sectoral: en banca, un servidor MCP de atención al cliente lee un ticket enviado por un atacante. El ticket contiene texto invisible que instruye al modelo a enviar el historial completo de la cuenta a un correo externo. El modelo obedece porque no distingue entre instrucciones del usuario y contenido de datos.

Este es el problema más difícil de la familia. No tiene solución completa a nivel de modelo, y la defensa vive en la arquitectura del sistema. Si quieres ver casos prácticos de este tipo de ataques ejecutados sobre modelos reales, IA Generativa y LLM Hacking lo cubre en profundidad con Claude.

2. Tool poisoning (envenenamiento de herramientas)

Cuando un servidor MCP se conecta, lo primero que hace es declarar qué herramientas ofrece, cada una con un nombre y una descripción. El modelo lee esas descripciones para saber cuándo usar cada herramienta.

Aquí está el truco: si el servidor es malicioso, esa descripción puede contener instrucciones ocultas dirigidas al modelo. Y el modelo las procesa como parte de su contexto de sistema, no como datos externos.

Un estudio académico publicado en 2025 revisó mil ochocientos noventa y nueve servidores públicos y encontró que aproximadamente el cinco coma cinco por ciento presentaban señales de tool poisoning. La descripción de la herramienta se convierte así en un canal de ataque invisible para el usuario final.

Curso recomendado

GenIA aplicado a Ciberseguridad

Prompt Engineering práctico para tareas de seguridad ofensiva y defensiva. Aprende a explotar y a defenderte.

3. Rug pulls (redefinición silenciosa)

El término rug pull viene del mundo cripto y significa jalar la alfombra. En seguridad MCP se traduce como redefinición silenciosa. Funciona así:

• Instalas un servidor MCP que se comporta perfectamente durante días o semanas.
• El autor lanza una actualización que cambia la definición interna de una o varias herramientas.
• El agente ejecuta el nuevo comportamiento sin nueva aprobación.

Ejemplo sectoral: en retail, un servidor MCP para gestión de inventario cambia su función "listar productos" para exfiltrar precios de compra internos a un endpoint del competidor. El usuario nunca aprobó ese nuevo comportamiento, pero tampoco tiene forma de saber que cambió.

4. Tool shadowing y ataques cross-server

Esta categoría agrupa dos ataques relacionados.

Tool shadowing (sombreado de herramientas): un servidor malicioso registra una herramienta con nombre parecido al de una legítima para interceptar llamadas. El modelo cree que está invocando la herramienta original.

Ataques cross-server (entre servidores): un servidor comprometido no ataca directamente al usuario. Ataca al modelo para que use mal otro servidor conectado. Por ejemplo, un servidor malicioso de tareas convence al modelo de enviar información sensible usando el servidor legítimo de correo.

Los estudios de 2026 muestran una tasa de propagación cross-server del 72,4 % cuando hay múltiples servidores comprometidos. Basta con que uno caiga para que los demás se conviertan en armas.

5. La trifecta letal de Simon Willison

Publicada por el investigador Simon Willison en abril de 2025, la trifecta letal no es un ataque específico. Es un patrón que describe cuándo un agente se vuelve explotable. Ocurre cuando reúne tres capacidades al mismo tiempo:

+-----------------------------------+
|  1. Acceso a datos privados       |
+-----------------------------------+
|  2. Exposición a datos externos   |
|     no confiables                 |
+-----------------------------------+
|  3. Capacidad de comunicación     |
|     hacia el exterior             |
+-----------------------------------+

Con las tres presentes, un atacante puede leer los datos privados a través del canal externo. La única defensa real es romper una de las tres patas. Este patrón es hoy el modelo mental estándar para evaluar el riesgo de cualquier agente que integre servidores MCP.

Casos reales de ataques a servidores MCP #

Claude Code — CVE-2025-59536 (febrero 2026)

En febrero de 2026, Check Point Research publicó un análisis sobre Claude Code, la herramienta oficial de codificación de Anthropic. La vulnerabilidad, catalogada como CVE-2025-59536 con puntuación CVSS de 8,7, permite la siguiente cadena de ataque:

1. Un atacante crea un repositorio en GitHub que contiene un archivo .claude/settings.json.
2. Ese archivo define un Hook, un comando que Claude Code ejecuta automáticamente en ciertos eventos.
3. Cuando el desarrollador abre el repositorio, el Hook corre antes de que aparezca el diálogo de confianza.
4. Resultado: ejecución remota de código en la máquina del desarrollador.

Las siglas en juego: CVE significa Common Vulnerabilities and Exposures, en español Vulnerabilidades y Exposiciones Comunes. CVSS significa Common Vulnerability Scoring System, en español Sistema Común de Puntuación de Vulnerabilidades. RCE significa Remote Code Execution, en español Ejecución Remota de Código.

Curso recomendado

Claude Code Seguro: Programa con IA sin Riesgos de Seguridad

Aprende a programar con Claude Code y asistentes de IA blindando tu entorno de trabajo contra inyecciones de prompts, hooks maliciosos y ejecución indebida de comandos.

Servidor Git MCP oficial de Anthropic (enero 2026)

En enero de 2026, el investigador Yarden Porat, de la empresa Cyata, publicó una cadena de exploits contra el servidor Git MCP oficial de Anthropic. Se trata del servidor de referencia mantenido por la propia empresa que creó el protocolo.

La cadena involucra tres vulnerabilidades:

• CVE-2025-68143 — path traversal, la capacidad de salirse del directorio permitido.
• CVE-2025-68144 — argument injection, inyección de argumentos en línea de comandos.
• CVE-2025-68145 — bypass del alcance del repositorio, que permite tocar código fuera del proyecto autorizado.

Combinadas, permiten ejecución remota de código, y la cadena se dispara únicamente con un prompt injection. La lección es directa: si la implementación de referencia oficial contenía estos fallos, cualquier servidor MCP de terceros con menos recursos debe considerarse sospechoso por defecto.

Ruta profesional

Hacking Ético Ofensivo — Red Team

Aprende a encontrar cadenas de exploits como estas antes que los atacantes. +43 horas de práctica.

El gusano Shai-Hulud evoluciona hacia MCP

Shai-Hulud es un gusano informático que comenzó en el ecosistema npm, el gestor de paquetes de Node.js, robando credenciales de desarrolladores. En 2026 evolucionó. Los investigadores de OX Security documentaron variantes que se propagan usando servidores MCP maliciosos como vector primario.

En vez de infectar solo bibliotecas de código, ahora infecta las herramientas que los agentes de inteligencia artificial usan a diario. El impacto es sistémico: se comprometen cadenas de suministro completas de agentes en cascada. Un desarrollador instala un servidor MCP aparentemente inofensivo, y a partir de ahí el gusano roba credenciales, se propaga a otros proyectos, y potencialmente infecta los servidores MCP que ese mismo desarrollador publica.

Estadísticas de vulnerabilidades en servidores MCP #

Las cifras del panorama actual son públicas y no dejan espacio para la interpretación:

Métrica	Cifra	Fuente
Servidores vulnerables a inyección de comandos	43 %	Equixly (2025-2026)
Servidores con operaciones de archivo vulnerables a path traversal	82 %	Endor Labs (2.614 servidores)
Servidores vulnerables a SSRF	36,7 %	BlueRock Security (7.000+ servidores)
Servidores con vulnerabilidades críticas	33 %	Enkrypt AI (1.000 servidores)
Servidores con al menos un hallazgo de seguridad	66 %	AgentSeal (1.808 servidores)
Tasa de propagación cross-server	72,4 %	Investigación 2026

SSRF significa Server-Side Request Forgery, en español Falsificación de Solicitudes del Lado del Servidor. Es un ataque donde el servidor termina haciendo peticiones a direcciones web que el atacante controla.

La conclusión que se desprende es incómoda pero honesta: la mayoría de los servidores MCP en producción hoy tienen problemas de seguridad relevantes.

Cómo proteger los servidores MCP: la pila de defensa de 5 capas #

La comunidad convergió en un modelo de defensa por capas. Ninguna capa por sí sola es suficiente. Combinadas, cada capa reduce el radio de impacto aproximadamente a la mitad. En producción se recomienda tener al menos tres capas activas al mismo tiempo.

Capa 1: Lista aprobada de servidores

Regla base: ningún servidor MCP se conecta a un agente productivo sin pasar por un proceso de validación previa.

Criterios mínimos:

• Origen verificado. El registro oficial de MCP, lanzado en el primer trimestre de 2026, incluye firmas y verificación de proveedor. Los registros comunitarios y las instalaciones directas desde repositorios de GitHub no tienen verificación consistente, y son la vía de instalación más común.
• Auditoría de código o revisión reproducible. Alguien tiene que leer lo que hace el servidor antes de conectarlo.
• Versión anclada. Nunca instalar con la etiqueta latest. Siempre fijar la versión exacta y validar cada actualización.
• Registro interno con la lista de servidores permitidos por cada equipo.

Sin lista blanca, no hay perímetro.

Capa 2: Aislamiento en contenedores

Cada servidor MCP debe correr dentro de un entorno aislado del sistema principal. Los requisitos mínimos son:

• Sistema de archivos de solo lectura salvo las rutas específicas que el servidor necesita.
• Sin acceso a la red por defecto. Internet se otorga por medio de una allowlist (lista blanca) explícita de dominios permitidos.
• Sin acceso a variables de entorno de otros servicios, para evitar filtración de credenciales cruzadas.
• Límites duros de CPU y memoria.

Recomendación adicional: usar contenedores efímeros que se destruyen al terminar la sesión, para que ningún estado sobreviva entre ejecuciones. Si un servidor cae, el daño queda dentro del contenedor.

Capa 3: OAuth con Resource Indicators

OAuth significa Open Authorization, en español Autorización Abierta. Es el estándar por el que un servicio otorga acceso limitado a una aplicación sin compartir la contraseña.

Resource Indicators (Indicadores de Recurso) es un complemento definido en el estándar RFC 8707. Su función es vincular cada token de acceso a un recurso específico. En otras palabras, un token emitido para trabajar con GitHub no debe funcionar contra Google Drive, aunque el servidor lo intente reutilizar.

La regla que gobierna esta capa es la regla de mínimo privilegio:

1. Un token por cada servidor conectado.
2. Alcance limitado únicamente a las acciones estrictamente necesarias.
3. Tiempo de vida corto, de minutos u horas, no de días.
4. Revocación automática cuando el servidor se desconecta.

Sin mínimo privilegio, el radio de impacto de cualquier ataque se multiplica. Este es el terreno donde brilla la disciplina de Analista GRC: gobernar quién accede a qué y con qué permisos.

Capa 4: Observabilidad runtime

Runtime se traduce como tiempo de ejecución. Esta capa exige registrar obligatoriamente:

• Cada llamada a una herramienta, con la entrada completa y la salida completa. No solo el resultado visible al usuario.
• El contexto del modelo antes y después de la llamada.
• El origen de cada instrucción que el modelo procesa: si vino del usuario, si vino como respuesta de una herramienta, o si estaba en el prompt del sistema.

Regla crítica: los registros no pueden almacenarse dentro de la aplicación. Deben almacenarse en la infraestructura, controlada por el equipo de seguridad. Un agente comprometido tiene acceso al mismo entorno que la aplicación y por tanto puede alterar sus propios registros de aplicación. Solo los registros que viven fuera del alcance del agente son confiables.

Curso recomendado

Automatización de Ciberseguridad con n8n e IA

Construye tu propio SIEM y SOAR con n8n + IA. Observabilidad y respuesta automatizada para agentes.

Capa 5: Human-in-the-loop

Human-in-the-loop se traduce como humano en el circuito. La idea es que ciertas acciones nunca deben ejecutarse sin una aprobación humana explícita en el momento.

Lista mínima de acciones que siempre requieren aprobación:

• Envío de correos o cualquier mensaje hacia el exterior.
• Escritura en sistemas de archivos productivos.
• Ejecución de comandos de shell.
• Transferencias de datos hacia dominios externos.
• Cambios en configuración de OAuth o secretos.

La inteligencia artificial es copiloto, nunca autopiloto. El agente propone. El humano aprueba.

Esa separación es lo que evita que un prompt injection se convierta en un incidente irreversible. Para llevar este enfoque a nivel empresarial, la formación Evaluación de Riesgos y Ciberseguridad de la IA profundiza en marcos de trabajo y controles corporativos.

Framework de gobernanza

Domina el NIST AI RMF Framework

Gobernanza y gestión de riesgos en IA. El marco oficial para organizar todo lo anterior.

Qué problemas de seguridad MCP aún no tienen solución #

La honestidad técnica exige reconocer lo siguiente:

• Prompt injection a través de salidas de herramientas. Es un problema abierto en toda la industria de inteligencia artificial. Las defensas a nivel de modelo lo mitigan, pero no lo eliminan.
• Inferencia de intenciones entre servidores. Ninguna defensa publicada previene por completo que un servidor engañe al modelo para abusar de otro servidor conectado. El mínimo privilegio limita el daño, pero no impide el ataque.
• Verificación de servidores en registros comunitarios. No existe un proceso homogéneo, y la mayoría de instalaciones siguen viniendo de repositorios sin firmar.

La consecuencia práctica es esta: la defensa real vive en la arquitectura del sistema, no en el modelo. Un modelo más listo no arregla una arquitectura que confía ciegamente en sus herramientas.

Preguntas frecuentes sobre seguridad MCP #

¿Qué significa MCP en ciberseguridad?

MCP significa Model Context Protocol (Protocolo de Contexto de Modelo). Es un estándar abierto creado por Anthropic para conectar modelos de inteligencia artificial con herramientas externas. En ciberseguridad, MCP importa porque cada servidor conectado a un agente representa código de terceros ejecutándose con permisos delegados, y por tanto un nuevo vector de ataque.

¿Todos los servidores MCP son inseguros?

No, pero la mayoría de los que se han analizado en 2025-2026 presenta alguna vulnerabilidad relevante. Los estudios publicados muestran que entre el 33 % y el 66 % de los servidores auditados tienen hallazgos de seguridad, dependiendo del criterio. La recomendación es no conectar un servidor MCP a producción sin auditarlo previamente, independientemente de su origen.

¿Se puede usar MCP en producción de forma segura?

Sí, siempre que se aplique la pila de defensa por capas: lista aprobada de servidores, aislamiento en contenedores, OAuth con Resource Indicators, observabilidad runtime y human-in-the-loop para acciones sensibles. Con al menos tres capas activas al mismo tiempo, el radio de impacto de cualquier incidente queda acotado.

¿Cuál es el ataque más común contra servidores MCP?

El más frecuente es la inyección de comandos, que afecta al 43 % de los servidores probados por Equixly. El más difícil de mitigar es el prompt injection a través de respuestas de herramientas, porque no tiene solución completa a nivel de modelo.

¿MCP tiene relación con el OWASP Top 10 para LLM?

Sí. Varias de las clases de ataque específicas de MCP corresponden directamente a categorías del OWASP Top 10 para Aplicaciones LLM, especialmente LLM01: Prompt Injection, LLM05: Supply Chain Vulnerabilities y LLM08: Excessive Agency. La disciplina emergente de seguridad MCP se apoya fuertemente en ese marco.

¿Cómo puedo empezar a auditar un servidor MCP?

El punto de partida es revisar el código fuente del servidor, validar el origen del repositorio, comprobar la firma cuando exista, listar los permisos que solicita, probar sus herramientas en un entorno aislado, y monitorizar el tráfico saliente durante la ejecución. Cualquier comportamiento no declarado en la documentación debe considerarse una señal de alarma.

Conclusión: la defensa vive en la arquitectura #

Si tuvieras que resumir todo este panorama en una sola diapositiva para un CISO (Chief Information Security Officer, Director de Seguridad de la Información), la frase sería la siguiente:

Cada servidor MCP conectado a tu agente de inteligencia artificial es tres cosas al mismo tiempo: código de terceros que estás ejecutando, un endpoint externo en el que estás confiando, y un canal por donde entran instrucciones directas al contexto de tu modelo. El radio de impacto de cualquier incidente es igual a la suma de los permisos de todos los servidores conectados.

Esa es la conversación que hay que tener antes de que ocurra el próximo incidente, no después. La seguridad en servidores MCP dejó de ser un problema teórico en 2026. Los casos reales están publicados, las estadísticas son públicas, y la pila de defensa está probada. Lo que falta ahora es adoptarla antes de que un incidente lo haga por ti.

Recursos para profundizar

• modelcontextprotocol.io — especificación oficial y mejores prácticas.
• Check Point Research — análisis técnico de la vulnerabilidad de Claude Code.
• OX Security — advisory de Shai-Hulud y de la RCE en el SDK oficial de MCP.
• Invariant Labs — investigación pionera sobre tool poisoning.
• Simon Willison — formulación original de la trifecta letal.
• OWASP GenAI Security Project — Top 10 para Aplicaciones LLM.