sistema: OPERATIVO
← volver a todos los hacks
AGENTS CRITICAL

Transporte STDIO de MCP: la decisión de diseño que se convirtió en 11 CVE y 200 000 agentes expuestos

El 16 de abril de 2026, OX Security reveló que el transporte STDIO del MCP de Anthropic ejecuta cualquier comando que reciba. Anthropic lo calificó como «por diseño». La cascada ha producido once CVE en seis semanas.

2026-05-27 // 8 min affects: model-context-protocol, mcp-python-sdk, mcp-typescript-sdk, mcp-java-sdk, mcp-rust-sdk, litellm, langflow, flowise, upsonic

¿De qué se trata?

El 16 de abril de 2026, OX Security publicó The Mother of All AI Supply Chains, una divulgación coordinada de una vulnerabilidad sistémica en el Model Context Protocol (MCP) — el estándar abierto que Anthropic introdujo en 2024 para permitir que los LLM se comuniquen con herramientas externas. El defecto no reside en una implementación aislada. Está en el transporte STDIO mismo, el mecanismo por defecto que MCP utiliza para conectar un agente a una herramienta local: el campo command de la configuración de un servidor MCP se entrega tal cual a subprocess y se ejecuta en el host sin validación, sin saneamiento, sin frontera de ejecución entre configuración y comando.

OX escaneó el ecosistema y encontró aproximadamente 7 000 servidores MCP accesibles públicamente con el transporte STDIO activo. Extrapolando, los investigadores estiman unas 200 000 instancias vulnerables en total en los despliegues autoalojados, con más de 150 millones de descargas en la cadena de suministro afectada. La divulgación fue recogida ese mismo día por The Register, a finales de abril por VentureBeat y The Hacker News, y por el Cloud Security Alliance en una nota de investigación fechada el 23 de abril de 2026. Anthropic confirmó el comportamiento y se negó a modificar el protocolo, calificando la ejecución STDIO como un «secure default» y situando el saneamiento de entradas bajo la responsabilidad del desarrollador.

En seis semanas, el defecto ha generado al menos once CVE en frameworks aguas abajo, incluyendo CVE-2026-30623 en LiteLLM, además de advisories en LangFlow, Flowise, LangChain y Cursor.

Cómo funciona

El transporte STDIO de MCP es un fino envoltorio alrededor de subprocess. Un agente lee una configuración de servidor que contiene un campo command, la entrega a StdioServerParameters y lanza el proceso indicado para intercambiar mensajes JSON-RPC sobre la entrada y salida estándar. El contrato es: «el comando debe ser un lanzador de confianza». En la práctica, el campo es tratado como dato por todas las capas anteriores que lo manipulan.

# Estructura conceptual — meramente ilustrativa, no un exploit.
# Fuente: advisory de OX Security, nota CSA.

# Configuración de servidor MCP consumida por el agente:
#   transport: "stdio"
#   command:   "<cadena controlada por el atacante>"
#   args:      [...]
#
# Llega a StdioServerParameters en cada SDK oficial
# (Python / TypeScript / Java / Rust) y se lanza como
# subproceso en el host del agente. Sin lista blanca,
# sin escape de shell, sin sandbox por defecto.

OX identificó cuatro familias de explotación sobre este primitivo. La primera es la inyección de comandos sin autenticación a través de las interfaces web de los frameworks: tanto LangFlow como LiteLLM exponían endpoints de creación de servidores MCP en los que el valor de command llegaba sin cambios al lanzador STDIO. La segunda es el bypass de listas blancas: los frameworks que sí intentaron restringir command a un conjunto conocido (Flowise, Upsonic) entregaron listas blancas evitables con rutas absolutas, smuggling de argumentos o intérpretes alternativos. La tercera es la distribución de paquetes maliciosos por los registros de MCP: OX envió un paquete de prueba benigno a once registros y nueve lo aceptaron sin revisión de seguridad, lo que significa que un atacante puede publicar un servidor cuyo command es hostil por construcción. La cuarta es la manipulación de configuración: cualquier usuario con permiso para añadir un servidor MCP a una pasarela multi-tenant puede, por definición, ejecutar código bajo la identidad de la pasarela.

El punto clave es que ninguna de estas vías requiere romper el protocolo. El transporte STDIO funciona exactamente como está documentado; la superficie de ataque es la distancia entre «el desarrollador saneará su configuración» y lo que hacen los despliegues reales.

Por qué importa

La cuestión STDIO de MCP es el ejemplo público más nítido, hoy en día, de una disputa protocolo versus producto en seguridad de LLM. La postura de Anthropic — STDIO es un transporte, no una frontera de privilegios; el desarrollador es responsable del comando que se ejecuta — es defendible en el plano del protocolo. La realidad aguas abajo, documentada por OX en despliegues productivos, es que cientos de miles de instalaciones tomaron el comportamiento documentado por defecto y lo construyeron directamente en infraestructura expuesta a la web.

Tres consecuencias ya son visibles. Primero, el mismo primitivo sigue generando CVE. Cualquier framework que envuelva MCP y acepte entrada de usuario cerca del campo command está a una ruta de configuración de un RCE, y cabe esperar más entradas en la lista antes de que termine el año. Segundo, los registros de MCP son ahora un vector creíble de cadena de suministro: un atacante ya no necesita comprometer el equipo de un desarrollador para introducir código en su agente; basta con enviar un paquete a un registro permisivo. Tercero, la respuesta del protocolo establece un precedente: un default publicado que entrega RCE de fábrica, dejando la carga de uso seguro en cada implementador, no es una postura que ningún otro estándar de transporte haya logrado en años recientes.

Para los equipos que hoy operan frameworks de agentes autoalojados, la implicación práctica es que la configuración de un servidor MCP forma parte de su superficie de ataque y debe tratarse como código.

Defensas

No hay un parche único que aplicar. Las mitigaciones se reparten en cuatro capas, todas aplicables sin esperar a Anthropic.

La primera capa es una lista blanca de comandos, siguiendo el modelo de MCP_STDIO_ALLOWED_COMMANDS de LiteLLM (entregada en v1.83.6-nightly, estabilizada en v1.83.7). El conjunto autorizado debe ser la lista mínima de lanzadores conocidos que su entorno realmente necesite — por ejemplo npx, uvx, python, python3, node, docker, deno — y la comprobación debe rechazar rutas absolutas, smuggling de argumentos e intérpretes indirectos. La lista hace el trabajo evidente, pero también obliga a una revisión de código cada vez que se solicita una nueva entrada.

La segunda capa es el aislamiento de procesos. Los servidores MCP deben ejecutarse dentro de una sandbox: contenedor sin montaje del sistema de archivos del host, usuario sin privilegios, filtros syscall, sin red saliente salvo necesidad explícita, identidad distinta a la de la pasarela. Si el comando lanzado resulta ser hostil, el radio del daño se colapsa a la sandbox.

La tercera capa es la higiene de registros. Trate los registros de paquetes MCP como trata npm o PyPI: fije versiones, prefiera paquetes firmados, mantenga un mirror interno para producción, revise los campos command y args antes de instalar, y nunca permita la actualización automática de paquetes de servidor MCP en una pasarela productiva.

La cuarta capa es el control de red y de acceso. Las pasarelas MCP, instancias de n8n, tableros de LangFlow y herramientas similares no tienen razón para estar en una IP pública sin autenticación. Sitúelas detrás de una VPN o de un proxy inverso autenticado, registre cada invocación de herramienta MCP con la identidad llamante y alerte ante cualquier cambio en la configuración de un servidor MCP.

Un paso adicional y de bajo coste es suscribirse a la cascada. Las once CVE ya publicadas comparten causa raíz; cualquier framework del que dependa y que envuelva MCP es candidato a la siguiente entrada. Siga los advisories de OX Security, la nota del CSA Labs y, directamente, a los proveedores afectados.

Estado de la situación

ElementoReferenciaFechaNotas
Divulgación inicial de OX Security«The Mother of All AI Supply Chains»2026-04-16~7 000 servidores públicos, ~200 000 extrapolados
Cobertura de prensaThe Register2026-04-16Postura «by design» de Anthropic reportada
Síntesis de la cascadaThe Hacker News2026-04«Anthropic MCP Design Vulnerability Enables RCE»
Nota de investigaciónCloud Security Alliance Labs2026-04-23Encuadre de cadena de suministro sistémica
Advisory de LiteLLMCVE-2026-306232026-04Parcheado en v1.83.7-stable; lista blanca añadida
Advisory ampliadoSeguimiento de OX Security2026-0511 CVE catalogados, cuatro familias de explotación
Postura de AnthropicMantenedores de la especificación MCP2026-04Sin cambio de protocolo previsto

El transporte STDIO de MCP es hoy el ejemplo público canónico de una decisión de diseño que sobrevive a cada parche individual. Trate el campo de configuración como código no confiable, no como dato, y dé por hecho que la cascada aún no ha terminado.

Sources