Falla Crítica de Ejecución de Comandos Expone 200.000 Servidores de Agentes de IA en el Protocolo MCP de Anthropic

El Problema: Una Falla Arquitectónica Crítica en el Protocolo de Contexto del Modelo

200.000 servidores de agentes de IA. Esa es la escalofriante estimación de instancias vulnerables que utilizan el transporte STDIO del Protocolo de Contexto del Modelo (MCP) de Anthropic, según una reciente investigación de OX Security. Lo que Anthropic llama una "característica" del diseño, la comunidad de seguridad lo ha identificado como una puerta abierta para la ejecución arbitraria de comandos, exponiendo una infraestructura crítica de IA en todo el mundo. Este no es un simple error de codificación; es una vulnerabilidad arquitectónica inherente a la especificación misma del protocolo.

Anthropic presentó el MCP como el estándar abierto para la comunicación entre agentes de IA y herramientas. Su rápida adopción fue notable: OpenAI lo incorporó en marzo de 2025, Google DeepMind siguió su ejemplo, y Anthropic donó el MCP a la Linux Foundation en diciembre de 2025, con descargas superando los 150 millones. Sin embargo, en medio de esta proliferación, cuatro investigadores de OX Security —Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok y Roni Bar— descubrieron un problema fundamental.

El núcleo del problema reside en el transporte STDIO de MCP, que es el predeterminado para conectar un agente de IA a una herramienta local. Este mecanismo, por diseño, ejecuta cualquier comando del sistema operativo que recibe, sin ninguna sanitización o límite de ejecución entre la configuración y el comando. Un comando malicioso, incluso si devuelve un error, ya se ha ejecutado. Lo más alarmante es que la cadena de herramientas del desarrollador no levanta ninguna bandera, dejando a las implementaciones con una falsa sensación de seguridad.

El Impacto Generalizado: 200.000 Instancias Expuestas y CVEs Críticos

Los investigadores de OX Security no solo identificaron el fallo, sino que también escanearon el ecosistema, encontrando 7.000 servidores con IPs públicas y transporte STDIO activo. Extrapolando a partir de esta proporción, estimaron un total de 200.000 instancias vulnerables. Para demostrar la gravedad, confirmaron la ejecución arbitraria de comandos en seis plataformas de producción en vivo con clientes de pago. La investigación resultó en la asignación de más de 10 CVEs clasificados como altos o críticos, afectando a plataformas como LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher, Agent Zero, LettaAI, entre otros.

"Esta investigación expuso una brecha impactante en la seguridad de la infraestructura fundamental de la IA."

Kevin Curran, miembro sénior del IEEE y profesor de ciberseguridad en la Universidad de Ulster.

La postura de Anthropic, según OX, es que este comportamiento es "por diseño" y que la sanitización de entradas es responsabilidad del desarrollador. Sin embargo, Anthropic solo ha declarado explícitamente que el comportamiento es "esperado" y no ha emitido una declaración pública independiente ni ha respondido a las solicitudes de comentarios. OX Security argumenta que esperar que 200.000 desarrolladores saniticen correctamente las entradas es precisamente el problema, una "falla distribuida" en palabras de Carter Rees, vicepresidente de IA y Aprendizaje Automático en Reputation.

Comprendiendo los Vectores de Explotación

OX Security identificó cuatro familias principales de explotación, cada una con implicaciones graves:

1. Inyección de comandos no autenticada a través de interfaces web de frameworks de IA: Demostrada contra LangFlow y LiteLLM, donde un atacante puede ejecutar comandos arbitrarios sin autenticación previa.
2. Bypass de listas blancas en herramientas con control de comandos: Demostrado contra Flowise y Upsonic, donde OX Security eludió las listas blancas de comandos mediante la inyección de argumentos (ej. npx -c). Esto demuestra que las listas blancas por sí solas no son suficientes.
3. Inyección de prompts de cero clic en IDEs de codificación de IA: Donde HTML malicioso puede modificar archivos de configuración locales de MCP. Windsurf (CVE-2026-30615) fue el único IDE donde la explotación no requirió interacción del usuario, pero Cursor (CVE-2025-54136), Claude Code y Gemini-CLI son vulnerables a esta familia, requiriendo en algunos casos una interacción que no implica consentimiento informado.
4. Distribución de paquetes maliciosos a través de registros MCP: OX Security presentó una prueba de concepto benigna a 11 registros, y nueve la aceptaron sin revisión de seguridad, abriendo la puerta a la instalación de backdoors a través de fuentes supuestamente fiables.

La familia de IDEs es particularmente preocupante, ya que afecta directamente a las estaciones de trabajo de los desarrolladores, no solo a los servidores. Un desarrollador que visita un sitio web controlado por un atacante podría ver su archivo de configuración local de MCP modificado. En el caso de Windsurf, el cambio se ejecuta inmediatamente sin solicitud de aprobación, mientras que otros como Cursor pueden presentar un cambio de configuración que, al ser aprobado sin entender las consecuencias de ejecución, no constituye un consentimiento informado.

La Solución: Pasos de Remediación Inmediata

A pesar del debate sobre la responsabilidad arquitectónica, la realidad operativa exige acción inmediata. Merritt Baer, CISO de Enkrypt AI y ex CISO adjunta de AWS, advirtió en enero que los "valores predeterminados inseguros" del MCP conducirían precisamente a este resultado. La Alianza de Seguridad en la Nube confirmó de forma independiente los hallazgos de OX y recomendó tratar la infraestructura conectada a MCP como una amenaza activa y sin parchear. La siguiente secuencia de remediación para el "lunes por la mañana" es crucial para cualquier director de seguridad:

Enumeración: Conocer su Superficie de Ataque

El primer paso es identificar y enumerar cada despliegue de servidor MCP en entornos de desarrollo, staging y producción. Esto incluye buscar archivos de configuración MCP (mcp.json, mcp_config.json) en directorios de inicio de desarrolladores y rutas de configuración de IDEs (como ~/.cursor/, ~/.codeium/windsurf/, ~/.config/claude-code/). También es vital listar los procesos en ejecución que coincidan con los binarios del servidor MCP y señalar cualquier uso del transporte STDIO con accesibilidad IP pública. OX encontró 7.000 en IPs públicas; su entorno podría tener muchas más instancias no identificadas.

Aplicación de Parches: Abordar Puntos de Entrada Específicos

Aunque no es una solución definitiva para el problema subyacente del protocolo, aplicar los parches disponibles es un paso necesario. Fije cada producto afectado a su versión parcheada. Por ejemplo, LiteLLM v1.83.7-stable incluye la corrección para CVE-2026-30623. DocsGPT, Flowise y Bisheng también han enviado correcciones. Windsurf y Langchain-Chatchat aún están en estado "reportado" a partir del 1 de mayo de 2026. Cursor fue parcheado contra una divulgación relacionada anterior (CVE-2025-54136), pero hereda el mismo valor predeterminado del protocolo. Verifique los avisos de cada proveedor antes de ejecutar este paso.

Sandboxing: Imponer Aislamiento a Nivel de Proceso

La capacidad de saltarse listas blancas de comandos, como se demostró en Flowise/Upsonic, subraya la necesidad de un aislamiento más robusto. Aísle cada servicio habilitado para MCP del sistema operativo anfitrión. Nunca conceda a un servidor acceso completo al disco o privilegios de ejecución de shell. Esto debe ser una política de denegación por defecto, permitiendo solo lo estrictamente necesario. Las listas blancas solas no son una defensa suficiente.

Auditoría de Registros: Prevenir Ataques a la Cadena de Suministro

La alarmante revelación de que nueve de 11 registros MCP aceptaron una prueba de concepto maliciosa de OX sin revisión de seguridad, destaca un grave riesgo en la cadena de suministro. Audite cada servidor MCP instalado desde un registro de terceros. Utilice registros con procesos documentados de revisión de seguridad y elimine cualquier servidor MCP cuyo origen no pueda verificar o que no cumpla con los estándares de seguridad.

Tratar la Configuración STDIO como No Confiable: El Cambio Fundamental

Este paso es el más crítico y sobrevive a cualquier parche futuro o producto. Dado que el valor predeterminado a nivel de protocolo no ha cambiado, cada definición de servidor STDIO es una superficie de ejecución de comandos. Trátela de la misma manera que trata la entrada del usuario en una consulta de base de datos: asuma que es hostil hasta que se valide exhaustivamente. Implemente una política de denegación por defecto, utilice listas blancas estrictas para cualquier comando permitido, y asegúrese de que todos los procesos se ejecuten en entornos con sandbox. Como señaló Carter Rees, "MCP stdio es una superficie de ejecución privilegiada, no un conector. Los equipos empresariales deberían tratarlo como acceso de shell de producción".

Conclusión: Actuar Ahora, Debatir Después

La exposición de su infraestructura no puede esperar a que se resuelva el debate entre Anthropic y OX Security sobre dónde recae la responsabilidad de asegurar el transporte STDIO de MCP. Ese desacuerdo no se resolverá esta semana. Lo que sí se puede resolver esta semana es si sus despliegues de MCP están enumerados, parcheados, aislados y tratados como las superficies de ejecución no confiables que son. La advertencia de Merritt Baer sobre los valores predeterminados inseguros se ha materializado. OX ha documentado 200.000 servidores ejecutándose con un campo de configuración que funciona como una superficie de ejecución. La pregunta no es quién tiene razón, sino cuáles de sus servidores están expuestos.