Vulnerabilidad en el MCP de Anthropic permite ejecución remota de código y amenaza la cadena de suministro de IA
Una vulnerabilidad crítica en el Protocolo de Contexto de Modelo (MCP, por sus siglas en inglés) está poniendo en riesgo toda la cadena de suministro de inteligencia artificial — y lo peor es que el problema no surgió de un error de programación descuidado, sino de una decisión deliberada de diseño.
Investigadores de OX Security identificaron la falla directamente en el SDK oficial de Anthropic, la empresa detrás de Claude. Esto significa que el problema no está en un plugin de terceros ni en alguna configuración mal hecha por un desarrollador. Está en el código base que todo el mundo usa como referencia. 😬
Y las cifras asustan un poco:
- Más de 7.000 servidores públicos expuestos
- Más de 150 millones de descargas afectadas
- Proyectos conocidos como LiteLLM, LangChain, LangFlow, Flowise, LettaAI y LangBot en la lista de afectados
La falla permite la ejecución remota de código (RCE) en cualquier sistema que ejecute una implementación vulnerable del MCP, dando a los atacantes acceso directo a datos sensibles, claves de API, historiales de conversaciones y bases de datos internas.
No es exagerado decir que este es uno de los escenarios más preocupantes para quienes trabajan con ciberseguridad en entornos de IA actualmente.
¿Y la respuesta de Anthropic sobre todo esto? Bueno, sorprendió a mucha gente — y no de la forma que se esperaría. 👇
Qué es el MCP y por qué importa tanto
El Protocolo de Contexto de Modelo es, esencialmente, el pegamento que conecta modelos de inteligencia artificial con herramientas externas, bases de datos, APIs y sistemas corporativos. Piénsalo así: si el modelo de lenguaje es el cerebro, el MCP es el sistema nervioso que permite que ese cerebro interactúe con el mundo que lo rodea.
Fue creado por Anthropic para estandarizar la forma en que los asistentes de IA se comunican con recursos externos, y rápidamente se convirtió en uno de los estándares más adoptados en el ecosistema de desarrollo de IA. La idea era buena — tener un protocolo único, bien documentado y mantenido por una empresa seria del sector.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
El problema es que, cuanto más se expande un estándar, mayor es el impacto cuando algo sale mal en él. Y fue exactamente eso lo que pasó aquí. La adopción masiva del protocolo de contexto de modelo por proyectos como LiteLLM, LangChain, LangFlow y Flowise transformó una falla puntual en un problema de escala gigantesca. Cada uno de esos proyectos tiene sus propias bases de usuarios, sus propios entornos de producción y sus propias integraciones con sistemas críticos. Cuando todos beben de la misma fuente comprometida, el radio de daño se multiplica de forma exponencial.
Otro punto importante es entender que el MCP no es una tecnología oscura o experimental. Ya está funcionando en entornos de producción reales, en empresas de diferentes tamaños, conectado a sistemas con datos sensibles de clientes, contratos, propiedad intelectual y mucho más. La falla identificada por OX Security, por lo tanto, no es un problema teórico o de laboratorio. Es una vulnerabilidad activa, con vector de ataque real, en sistemas que están operando ahora mismo mientras lees este texto.
Cómo funciona la vulnerabilidad en la práctica
Ahora vamos a lo que realmente importa: el mecanismo técnico detrás de esta falla. El problema está en los valores predeterminados inseguros de cómo la configuración del MCP funciona a través de la interfaz de transporte STDIO (standard input/output, o entrada y salida estándar). En términos más accesibles, el protocolo de Anthropic ofrece un camino directo de configuración para ejecución de comandos a través de la interfaz STDIO en todas sus implementaciones, independientemente del lenguaje de programación utilizado — ya sea Python, TypeScript, Java o Rust.
De forma simplificada, ese código fue diseñado para iniciar un servidor STDIO local y devolver el control de la comunicación al modelo de lenguaje. Pero en la práctica, como explicaron los investigadores Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok y Roni Bar de OX Security, termina permitiendo que cualquier persona ejecute cualquier comando arbitrario en el sistema operativo. Si el comando logra crear un servidor STDIO, retorna normalmente. Si recibe un comando diferente, retorna un error — pero solo después de que el comando ya fue ejecutado. Es decir, el daño ya está hecho antes de que aparezca cualquier mensaje de fallo.
Esto significa que, sin necesidad de credenciales, sin necesidad de estar dentro de la red de la empresa y sin dejar rastros obvios, alguien malintencionado puede obtener acceso al entorno de ejecución de la aplicación.
Lo que hace esto aún más grave es el tipo de dato que queda expuesto. Las aplicaciones que utilizan el protocolo de contexto de modelo normalmente están conectadas a fuentes ricas de información. Claves de API de otros servicios, tokens de autenticación, historiales de conversaciones de usuarios, conexiones con bases de datos internas — todo eso queda potencialmente accesible desde el momento en que un atacante logra ejecutar código en el servidor. Ni siquiera es necesario hacer un movimiento lateral dentro de la red corporativa. La propia naturaleza del MCP, que fue diseñado para dar al modelo acceso amplio a recursos externos, termina funcionando como un amplificador del daño causado por la explotación de la falla.
Las vulnerabilidades descubiertas y los proyectos afectados
La investigación de OX Security reveló 10 vulnerabilidades específicas, distribuidas por proyectos ampliamente utilizados en la comunidad de IA. Todas ellas encajan en cuatro grandes categorías de ataque:
- Inyección de comando autenticada y no autenticada vía MCP STDIO
- Inyección de comando no autenticada vía configuración directa de STDIO, con bypass de mecanismos de protección
- Inyección de comando no autenticada vía edición de configuración del MCP a través de inyección de prompt zero-click
- Inyección de comando no autenticada a través de marketplaces del MCP vía solicitudes de red que activan configuraciones ocultas de STDIO
Los CVEs (identificadores de vulnerabilidades) registrados incluyen fallas en proyectos bastante conocidos:
- CVE-2025-65720 — GPT Researcher
- CVE-2026-30623 — LiteLLM (ya corregido)
- CVE-2026-30624 — Agent Zero
- CVE-2026-30618 — Fay Framework
- CVE-2026-33224 — Bisheng (ya corregido)
- CVE-2026-30617 — Langchain-Chatchat
- CVE-2026-33224 — Jaaz
- CVE-2026-30625 — Upsonic
- CVE-2026-30615 — Windsurf
- CVE-2026-26015 — DocsGPT (ya corregido)
- CVE-2026-40933 — Flowise
Un detalle que llama la atención es que vulnerabilidades basadas en el mismo problema central ya venían siendo reportadas de forma independiente a lo largo del último año. Entre ellas están fallas en MCP Inspector (CVE-2025-49596), LibreChat (CVE-2026-22252), WeKnora (CVE-2026-22688), @akoskm/create-mcp-server-stdio (CVE-2025-54994) e incluso en Cursor (CVE-2025-54136). Esto demuestra que el patrón problemático ya estaba dando señales desde hace tiempo, pero nadie conectó los puntos hasta ahora. 👀
La respuesta de Anthropic y lo que revela sobre el ecosistema de IA
Aquí es donde la historia se pone realmente divisiva dentro de la comunidad de ciberseguridad. Anthropic, al ser notificada sobre la vulnerabilidad, se negó a modificar la arquitectura del protocolo. La empresa clasificó el comportamiento como esperado — es decir, en la visión de Anthropic, el MCP está funcionando como fue diseñado para funcionar.
Esta posición generó bastante debate. Mientras algunos de los proveedores de proyectos afectados ya lanzaron correcciones para sus implementaciones específicas, la falla permanece presente en la implementación de referencia del MCP de Anthropic. En la práctica, esto significa que los desarrolladores que crean nuevas aplicaciones usando el SDK oficial siguen heredando los riesgos de ejecución de código sin saberlo.
Esta situación plantea una discusión importante sobre la madurez del ecosistema de inteligencia artificial en relación con las prácticas de ciberseguridad. El desarrollo de herramientas de IA avanzó a una velocidad impresionante en los últimos años, y proyectos como el MCP son reflejo de eso. Pero velocidad y seguridad muchas veces caminan en sentidos opuestos cuando no hay procesos robustos de revisión de arquitectura antes de que una tecnología sea lanzada para adopción masiva.
La vulnerabilidad identificada no es resultado de un bug accidental, sino de una decisión de diseño que no tuvo en cuenta adecuadamente los vectores de ataque posibles en entornos hostiles. Esto apunta a un problema estructural que va más allá del MCP y que afecta cómo la industria de IA piensa — o deja de pensar — en seguridad desde el inicio del ciclo de desarrollo.
Por qué esto es un evento de cadena de suministro y no solo un CVE más
OX Security se encargó de enfatizar un punto que merece destaque: esto no es simplemente otra vulnerabilidad aislada. Es un evento de cadena de suministro.
Como los propios investigadores lo expresaron: una decisión arquitectónica, tomada una única vez, se propagó silenciosamente a cada lenguaje soportado, cada biblioteca downstream y cada proyecto que confió en que el protocolo era lo que aparentaba ser.
Este efecto cascada es exactamente lo que transforma una falla técnica en un problema sistémico. Cuando un SDK oficial, mantenido por una de las mayores empresas de IA del mundo, lleva una vulnerabilidad de diseño que permite ejecución remota de código, cada desarrollador que importa ese SDK a su proyecto está, sin saberlo, importando también el riesgo. Y cuando esos proyectos son a su vez utilizados como dependencias por otros proyectos, el problema se multiplica exponencialmente — creando una red de exposición que se vuelve cada vez más difícil de rastrear y remediar.
Herramientas que usamos a diario
Los investigadores de OX Security fueron directos en su conclusión: transferir la responsabilidad a los implementadores no transfiere el riesgo. Solo oscurece quién lo creó. Esa frase resume bien la tensión que existe hoy en el ecosistema de inteligencia artificial cuando el tema es la responsabilidad sobre la seguridad.
Qué hacer para protegerse
Para los equipos de seguridad que trabajan en empresas que adoptaron soluciones basadas en el protocolo de contexto de modelo, el mensaje práctico es claro. Los investigadores recomiendan una serie de medidas que pueden ayudar a mitigar los riesgos mientras no llega una corrección arquitectónica definitiva:
- Bloquear el acceso público por IP a servicios sensibles conectados al MCP
- Monitorear las invocaciones de herramientas del MCP en tiempo real para detectar comportamientos anómalos
- Ejecutar servicios habilitados con MCP en sandbox, aislándolos del resto de la infraestructura
- Tratar cualquier entrada de configuración externa del MCP como no confiable, aplicando validación rigurosa
- Instalar servidores MCP solo de fuentes verificadas y mantener un control estricto sobre las actualizaciones
Además de esas medidas defensivas inmediatas, vale la pena verificar qué versión del SDK está en uso en cada proyecto y comprobar si los proyectos específicos que tu organización utiliza — como LangChain, LiteLLM, LangFlow, Flowise o cualquier otro — ya han puesto a disposición parches para las vulnerabilidades listadas. Tres de los proyectos afectados (LiteLLM, Bisheng y DocsGPT) ya lanzaron correcciones, pero los demás siguen siendo vulnerables al momento de la publicación de este análisis.
La ejecución remota de código es, históricamente, una de las clases de vulnerabilidad con mayor potencial de daño real — y cuando aparece en una capa de infraestructura tan central como el MCP, el esfuerzo de respuesta necesita ser proporcional a la exposición. 🔒
El mensaje que queda para la industria de IA
Este descubrimiento de OX Security sirve como un recordatorio importante para todo el ecosistema de inteligencia artificial. La carrera por lanzar nuevos protocolos, herramientas e integraciones no puede atropellar los fundamentos de ciberseguridad que la industria del software tardó décadas en construir. Cuando una empresa con el peso y la influencia de Anthropic define un estándar que es adoptado por miles de proyectos y millones de usuarios, la responsabilidad sobre la seguridad arquitectónica de ese estándar no puede ser delegada a quienes están al final de la cadena.
Los desarrolladores que construyen aplicaciones con IA necesitan estar atentos a estos riesgos e incorporar prácticas de seguridad desde el inicio de sus proyectos. Y las empresas que mantienen protocolos ampliamente adoptados necesitan tratar las vulnerabilidades de diseño con la misma seriedad que tratan los bugs funcionales — especialmente cuando el vector de ataque es tan poderoso como la ejecución remota de código.
El mundo de la inteligencia artificial está evolucionando demasiado rápido como para que la seguridad sea tratada como un problema de segunda categoría. Y esta vulnerabilidad en el MCP es una prueba concreta de que las consecuencias de ignorar este principio pueden afectar literalmente a millones de sistemas alrededor del mundo.
