Hay una forma de evaluar la madurez de seguridad de un ecosistema: mirar qué tan bien protegida está la implementación de referencia. No el código de un tercero, no el proyecto experimental de un developer entusiasta que publicó algo un sábado por la tarde. El código oficial. El que mantiene la organización que diseñó el protocolo. El que aparece primero en la documentación y que los demás, inevitablemente, van a copiar.
En el ecosistema MCP de Anthropic, la respuesta llegó en forma de CVE.
Entre mediados de 2024 y principios de 2025, investigadores de Cyata descubrieron vulnerabilidades críticas en mcp-server-git, el servidor Git MCP oficial mantenido por Anthropic. Las fallas eran explotables mediante inyección de prompt con argumentos controlados por atacantes. Una de ellas derivó en CVE-2025-49596, una vulnerabilidad de ejecución remota de código con puntuación CVSS de 9.4, uno de los primeros RCE críticos documentados en el ecosistema MCP.
Que haya bugs no es la noticia. Software es software, y el software tiene errores. Lo significativo es dónde aparecieron, y lo que eso dice sobre cómo se está construyendo esta capa de infraestructura.
El código de ejemplo se convierte en infraestructura crítica
MCP —Model Context Protocol— es el intento de Anthropic de resolver un problema genuino: cómo permitir que los LLMs interactúen con sistemas externos de forma estructurada. Introducido en noviembre de 2024, define un protocolo donde servidores ligeros exponen funcionalidades —sistemas de archivos, APIs, bases de datos, utilidades de desarrollo como Git— y los modelos las consumen a través de clientes. La idea tiene sentido. Un estándar abierto, modular, que evita que cada integración sea una solución ad hoc. Sobre el papel, razonable.
El problema es la velocidad. La adopción de MCP ha sido extraordinariamente rápida, y esa velocidad ha tenido un coste concreto: código concebido como referencia técnica se ha convertido en infraestructura de producción antes de haber pasado por el ciclo de endurecimiento que ese rol requiere. Los desarrolladores lo han tomado como base, lo han desplegado, lo han integrado en productos. Y el modelo de confianza implícito —si lo mantiene Anthropic, algo de rigor tendrá— ha funcionado como una garantía que nadie había otorgado explícitamente.
Según la investigación de Cyata, mcp-server-git no valida adecuadamente las rutas de repositorio ni sanitiza los argumentos pasados a comandos Git. El resultado es que un atacante puede dirigir al servidor a operar en cualquier directorio del sistema, no solo en el repositorio definido en su configuración. El diagnóstico sobre el patrón más amplio es directo: en la prisa por llevar estas herramientas al mercado —y en parte por miedo a restringir demasiado a los usuarios— las soluciones de IA conectadas han llegado a producción con frecuencia sin las barreras de protección necesarias.
Lo que convierte esto en algo más que un incidente de seguridad puntual es la observación de Shahar Tal, CEO de Cyata: «Este es el servidor Git MCP canónico, el que se espera que los desarrolladores copien. Si las barreras de seguridad se rompen incluso en la implementación de referencia, es una señal de que todo el ecosistema MCP necesita un escrutinio más profundo.» No está hablando de un proyecto mal mantenido. Está hablando del estándar.
El fallo que no es un bug
Pero incluso con código perfectamente validado y bien sanitizado, quedaría el problema de fondo. Y este es más difícil de parchear porque no está en el código. Está en la arquitectura.
La característica fundamental de los modelos de lenguaje es también su principal superficie de ataque: usan el mismo canal para recibir comandos y para procesar los datos sobre los que operan. Un LLM distingue entre «instrucción» y «contenido a analizar» únicamente por contexto. No hay separación arquitectónica entre los dos canales. No hay equivalente al ring 0 de los procesadores, ni a la separación entre espacio de usuario y espacio de kernel. Todo llega como texto. Todo se procesa como texto.
Esto tiene una consecuencia directa que los propios investigadores formulan sin ambigüedades: aunque se pueden dificultar las inyecciones y añadir defensas en capas, es imposible resolver el problema completamente dada la arquitectura LLM actual. MCP nació, por tanto, con una contradicción interna que ninguna actualización de seguridad va a eliminar: es infraestructura diseñada para ejecutar acciones reales sobre sistemas reales, construida sobre un sustrato que no puede distinguir de manera confiable entre instrucción legítima y manipulación adversarial.
El vector de ataque resultante es casi elegante en su simplicidad. No hacen falta credenciales robadas. No hace falta acceso directo a la red. No hace falta interacción con el sistema objetivo. Basta con que el modelo lea contenido controlado por el atacante: un README malicioso, una descripción de issue envenenada, una página web comprometida. El contenido hace el trabajo. La superficie de ataque no es el servidor, ni la red, ni el sistema operativo. La superficie de ataque es cualquier texto que el modelo pueda leer.
Esto es lo que hace que las vulnerabilidades en mcp-server-git sean interesantes más allá de su puntuación CVSS. Demuestran, en condiciones reales y en código de producción, que la combinación de MCP con LLMs crea una cadena de explotación que no tiene un buen equivalente en la seguridad tradicional. Los modelos mentales heredados —validar entradas, escapar parámetros, aplicar principio de mínimo privilegio— son necesarios pero insuficientes.
La contradicción que la industria prefiere no nombrar
El sector está apostando con fuerza por sistemas agénticos: modelos que no solo responden preguntas sino que ejecutan acciones en sistemas reales. Gestionan calendarios, escriben código, hacen commits, envían emails, interactúan con APIs. La promesa es automatización con criterio, no solo automatización. Y MCP es la infraestructura sobre la que se construye buena parte de esa promesa.
El problema es que esa apuesta se está haciendo antes de haber resuelto el problema de fondo. Como señaló Tal en su análisis, «esta investigación muestra cómo las suposiciones tradicionales sobre los límites de confianza colapsan una vez que los LLMs se colocan en el bucle de decisión.» No es hipérbole. Es una descripción precisa de lo que ocurre cuando introduces en una cadena de decisión un componente que puede ser manipulado a través de su interfaz de uso normal.
Las mitigaciones recomendadas existen y tienen sentido: privilegio mínimo, validación de salida, sandboxing, confirmación humana para acciones de alto riesgo. Todas razonables. Ninguna resuelve el problema de raíz, y la última introduce una contradicción que pocas organizaciones se detienen a nombrar en voz alta: si cada acción relevante requiere confirmación humana, la autonomía del agente se vacía. Te queda un asistente que propone y un humano que aprueba, que es básicamente el flujo de trabajo que ya existía antes.
La imagen que mejor captura el problema es esta: construir un sistema de control de acceso donde el guardia puede ser convencido mediante conversación de entregar las llaves. Puedes entrenar mejor al guardia. Puedes darle protocolos más estrictos. Puedes añadir un segundo guardia. Pero el problema estructural es que es un guardia que entiende lenguaje natural y puede ser persuadido. Eso no se resuelve con más entrenamiento. Se resuelve cambiando la arquitectura, y eso no está disponible todavía.
Lo que estas vulnerabilidades revelan no es incompetencia de Anthropic. Es algo más incómodo: que estamos desplegando sistemas agénticos en producción antes de haber resuelto cómo hacer que un LLM distinga de manera confiable entre «el usuario me pide hacer X» y «alguien inyectó texto que me hace creer que el usuario me pide hacer X». En arquitecturas tradicionales, esa distinción es trivial. En LLMs actuales, sigue siendo un problema abierto, con papers activos, sin solución consensuada, y sin horizonte claro de cuándo la habrá.
Mientras no se resuelva, cada nuevo servidor MCP que se despliega, cada nueva integración agéntica que se lanza, hereda ese problema. No como deuda técnica futura. Como condición de operación presente. Y la mayoría de los equipos que los están desplegando probablemente no lo saben, porque la documentación no lo dice con esa claridad, y el código de referencia, como hemos visto, tampoco lo resuelve.
Fuentes: Cyata Research · CVE-2025-49596 · Documentación MCP de Anthropic