Llevo unas semanas estudiando MCP (Model Context Protocol) y quiero compartir lo que voy aprendiendo porque creo que es un tema que está creciendo así como la seguridad en los propios modelos LLM también sed debería tener en el radar.

No soy ningún experto en esto, estoy aprendiendo sobre la marcha, pero justamente por eso creo que puedo explicarlo de una forma que gente que tampoco sea experta la entienda, como yo vamos.

Si trabajas en blue team, governance o simplemente te interesa entender por dónde van los tiros de la seguridad en IA, esto es para ti.

Qué es MCP y por qué importa

MCP es un protocolo abierto creado por Anthropic (los de Claude) a finales de 2024. La idea es simple, crear un estándar para que los modelos de lenguaje (LLMs) puedan conectarse con herramientas externas tales como bases de datos, APIs, sistemas de ficheros, servicios en la nube, lo que sea.

Por poner un ejemplo piensa en el MCP como si fuera un USB que se enchufa a la IA. Antes, cada herramienta de IA tenía su propia forma de conectarse a servicios externos. Ahora, con MCP, existe un protocolo común que cualquier LLM puede usar para hablar con cualquier herramienta.

Hasta aquí guay , poniendo orden , añadiendo funcionalidades , pero claro , ¿Dónde está problema? Que estamos conectando modelos de lenguaje que por naturaleza no son deterministas directamente con sistemas que ejecutan comandos, leen ficheros y acceden a datos sensibles. Y lo estamos haciendo a una velocidad que la seguridad no puede seguir.

Cómo funciona MCP

La arquitectura de MCP tiene tres piezas:

  • Host: la aplicación donde vive el LLM (Claude Desktop, VS Code con Copilot, un IDE con agente integrado…)
  • Cliente MCP: vive dentro del host y se encarga de hablar con los servidores MCP
  • Servidor MCP: expone herramientas (tools), recursos (resources) y prompts que el LLM puede usar (quedaros con estos tres conceptos ya que son claves)

El flujo es así , al final tú le pides algo al LLM y este decide que necesita una herramienta , posteriormente el cliente MCP llama al servidor MCP correspondiente y el servidor ejecuta la acción, el cuál devuelve el resultado al LLM y por último el LLM te responde.

La comunicación se hace por JSON-RPC 2.0, normalmente sobre STDIO (entrada/salida estándar) para servidores locales, o HTTP con SSE (Server-Sent Events) para servidores remotos.

Hasta aquí todo claro. Ahora viene lo que realmente preocupa.

Por qué MCP es un riesgo

Cuando empecé a leer sobre la seguridad de MCP me sorprendió lo rápido que la cosa se ha puesto seria. Solo entre enero y abril de 2026 se han registrado más de 40 CVEs contra implementaciones de MCP. Un CVE nuevo cada cuatro días, lo cuál es una burrada.

Y no estamos hablando de servidores que nadie usa. El CVE-2026-33032 (CVSS 9.8) afectó a nginx-ui, una herramienta con más de 2.600 instancias expuestas públicamente. El fallo era que el endpoint de MCP no pedía autenticación para ejecutar comandos así, sin más.

La NSA publicó en mayo de 2026 un informe específico sobre seguridad en MCP. Cuando la NSA publica un documento sobre un protocolo que tiene menos de dos años de vida, sabes que la cosa va en serio.

Los datos son bastante claros sobre dónde están los problemas:

  • El 43% de las vulnerabilidades son inyección de comandos (shell/exec injection)
  • El 20% son fallos en la infraestructura de herramientas
  • El 13% son bypass de autenticación
  • El 10% son path traversal
  • El 14% restante son SSRF, supply chain y otros

Conforme voy leyendo papers, CVEs y advisories, (por si os interesa , tengo montados agentes en github actions en este mismo blog donde los genero automáticamente tanto diariamente como semanalmentee) voy identificando patrones. Estos son los vectores de ataque principales que he encontrado hasta ahora:

1. Inyección de comandos por STDIO

Este es el grande , la final como hemos comentado antes MCP usa STDIO como transporte principal y el protocolo no sanitiza los comandos que se ejecutan como subprocesos. Es una decisión de diseño: el servidor MCP recibe una petición y la ejecuta como comando del sistema.

El problema es que si el input no se sanitiza correctamente , y según los estudios, el 82% de las 2.614 implementaciones analizadas son vulnerables a path traversal un atacante puede inyectar comandos arbitrarios.

Lo peor es que Anthropic ha dicho que esto es “comportamiento esperado” y que la responsabilidad de sanitizar es del desarrollador que implementa el servidor. Eso, desde el punto de vista de seguridad, es un problema de diseño.

2. Tool poisoning

Un servidor MCP malicioso puede ofrecer herramientas que parecen legítimas pero que en realidad exfiltran datos o ejecutan código, al final , el LLM no tiene forma de verificar que la herramienta hace lo que dice que hace.

Un caso real que pasó en febrero de 2026, vamos , hace unos meses, unos atacantes clonaron el proyecto Oura MCP , crearon un repositorio falso con contribuidores inventados, y distribuyeron una versión con malware StealC que robaba credenciales y contraseñas del navegador. (De hecho , cosas parecidas pasan en hugging face, algunos lo concoeréis)

3. Context poisoning

Cuando un agente trabaja con múltiples herramientas, comparte contexto entre ellas. Si un atacante puede manipular ese contexto compartido (por ejemplo, inyectando datos en una respuesta que otra herramienta consume), puede influir en todo el flujo de ejecución del agente.

4. Supply chain a través de registries

Los registries de MCP se han convertido en un vector importante. En octubre de 2025, un investigador encontró un path traversal en Smithery(para los que no lo sepáis es uno de los principales directorios de servidores MCP publicados, registroos etc…) que le dio acceso a un token de Fly.io con control sobre más de 3.000 aplicaciones, la mayoría servidores MCP alojados. Desde ahí podía interceptar las credenciales que los usuarios pasaban a través de los servidores MCP.

5. Rug pull attacks

Una herramienta MCP puede cambiar su definición después de haber sido instalada. Es decir, un atacante publica una herramienta legítima, espera a que la gente la instale y la apruebe, y luego cambia la definición para hacer algo malicioso. Como no hay verificación de integridad en las definiciones de herramientas, el cambio pasa desapercibido. Por ejemplo , esto pasa mucho con apps en dispositivos móviless como algunos sabréis, los malos compran una aplicación con buena reputación y en la actualización te meten el bicho , por que al haber tantas aplicaciones los escaneos en la publicación de actualizaciones apenas se tienen en cuenta en comparación con la publicación nueva de las mismas.

Mi plan de estudio:

  1. Terminar el curso de Certified MCP Security Expert (CMCPSE)
  2. Terminar la lectura del libro “MCP Seguro Guia práctica de Desarrollo” de cr0hn y mindcrypt
  3. Montar un lab con servidores MCP vulnerables para trastear: he visto que hay un repositorio de Appsecco con servidores MCP vulnerables para practicar
  4. Auditar servidores MCP reales usando un checklist basado en las recomendaciones de la NSA distintos CVEs que haay publicados
  5. Entender cómo gobernar MCP en un entorno enterprise cómo hacer inventario de servidores MCP, quién puede desplegar, qué permisos tienen, cómo se monitorizan
  6. Documentar todo aquí para que me sirva de asentamientoo de conocimientos

Al final , si trabajas en un entorno Microsoft 365 como yo, esto te afecta directamente. Copilot Studio, los agentes de Microsoft, y cada vez más herramientas del ecosistema están adoptando MCP y como con todo esto de la IA vamos tarde, sacando tiempo de donde no tenemos

Os dejo unos cuantos recursos que he recopilado para empezar a estudiar toda esto aparte del libro y la certificación que he mencionado antes

Esto es solo el principio. Iré publicando lo que vaya aprendiendo conforme avance con el curso, libro lab y eso. Si estás en el mismo camino o tienes experiencia con MCP, me encantaría saber qué estás viendo tú.

Nos vemos en el siguiente post!!!!