Seguridad de MCP STDIO, qué significa para ti la historia de OX Security

El 15 de abril de 2026, OX Security publicó un post de blog que entre investigadores de seguridad se conoce como la "Mother of all AI Supply Chain Attacks". Seis fuentes independientes confirmaron los hallazgos, entre ellas The Hacker News, Infosecurity Magazine, SecurityWeek y Tom's Hardware. Anthropic clasificó la vulnerabilidad como "expected behavior", diciendo que la sanitización es responsabilidad del desarrollador. Eso no es una cita con función protectora, es justo el punto que sostiene la discusión.

Si estás leyendo este playbook, probablemente has oído que los servidores MCP son inseguros, y quieres saber si tienes que cambiar algo ahora. La respuesta corta es, como consumidor que instala servidores MCP probablemente nada dramático, como builder de tu propio servidor MCP sí importa.

Qué encontró OX Security

El transporte MCP STDIO es la variante estándar en la que los servidores MCP se arrancan en local como subproceso. Los SDK de Anthropic en Python, TypeScript, Java y Rust ejecutan comandos del OS al arrancar el servidor y pasan los argumentos. OX mostró que estos argumentos en muchas implementaciones de servidor de producción se convierten directamente en llamadas de shell, y que incluso la sanitización conforme a best practices no cierra la brecha.

Los números del post original: 150 millones de descargas mensuales de SDK, 7.000 servidores MCP publicados públicamente, una estimación de hasta 200.000 instancias vulnerables. Hay al menos 11 CVEs asignados. La lista incluye LiteLLM, LangChain-Chatchat, LangFlow (CVE-2026-40933), Flowise, Windsurf (CVE-2026-30615), Bisheng, Upsonic, DocsGPT, Agent Zero, Fay Framework y GPT Researcher. Son frameworks que usan miles de builds, no hype de Reddit.

El hallazgo más importante no es la lista, sino el análisis de seguimiento de OX. Incluso frameworks que incorporaron sanitización de forma explícita (Flowise CVE-2026-40933, Upsonic CVE-2026-30625) fueron sorteados. Python y Node permiten trucos de shell vía argumentos que no se atrapan con una validación de whitelist ingenua. Ese es el punto en el que Anthropic dice "expected behavior".

¿Estás afectado?, tres casos claros

Caso 1, instalas servidores MCP en Claude Desktop o Claude Code. Eres consumidor. El riesgo es bajo mientras solo instales servidores MCP que conoces tú mismo o que vienen de fuentes confiables (releases oficiales de Anthropic, proyectos OSS establecidos, el StudioMeyer Marketplace). Se vuelve realmente peligroso cuando instalas servidores MCP ajenos desde forks o repos desconocidos, porque un servidor malicioso puede ejecutar comandos arbitrarios en tu sistema al arrancar.

Medidas concretas que deberías tomar hoy. Mira tu ~/.claude/settings.json y lista los servidores MCP instalados. Para cada uno que no venga de ti o de una fuente oficial, pregúntate si conoces de verdad al proveedor. En la duda, desinstala. Para cada servidor MCP nuevo que no venga de una fuente de confianza, lee la línea command:. Si ahí pone npx -y irgendwer/mcp-server, estás descargando código ajeno desde npm y ejecutándolo en el siguiente arranque de Claude. Esa es la misma cuestión de confianza que con los paquetes npm, ni más ni menos.

Caso 2, construyes un servidor MCP para ti o tu equipo. Eres builder, el riesgo es medio. Si tu servidor no toma argumentos de fuera, sino que solo ofrece tools cableadas con esquemas de input validados con zod, estás bien. Pero si en algún sitio llamas child_process.exec() o shell=True desde un string de argumento de tool, tienes exactamente la vulnerabilidad que encontró OX. Fix obligatorio, usa execFile o spawn con un array de argumentos en lugar de exec, y valida cada string de argumento contra una allowlist estricta en lugar de una blocklist.

Caso 3, publicas servidores MCP en un marketplace o registry. Eres distribuidor, el riesgo es alto y también afecta a tus usuarios. Aquí aplica además: releases firmados (npm provenance), límites de auth claros (sin acceso root al filesystem sin confirmación explícita del usuario), y un security statement documentado en el README que describa qué argumentos acepta tu servidor y cómo se validan.

Qué puedes comprobar hoy, cinco minutos

Si tienes tu propio servidor MCP, busca en el código tres patrones.

Búsqueda uno: llamadas a child_process.exec() con argumentos interpolados. El patrón en TypeScript es normalmente un template string como some-cli ${userInput} directamente en exec(...). Cada hit es un problema potencial. La solución es execFile("some-cli", [userInput]) con un array de argumentos explícito.

Búsqueda dos: Python subprocess.run() o subprocess.Popen() con shell=True. La recomendación estándar es shell=False y una lista en lugar de un string. Si necesitas shell=True porque usas pipes o redirects, escapa los user inputs explícitamente con shlex.quote().

Búsqueda tres: tool handlers que toman rutas y las pasan a fs.readFile, fs.writeFile o similar. Obligatorio es una validación de ruta contra path traversal (segmentos .., rutas absolutas que no están en tu allowed base dir, NUL bytes, Windows drive letters). En TypeScript path.resolve() más un check startsWith(allowedBase) es el estándar.

El statement de Anthropic y qué significa realmente

En reacción a la historia de OX, Anthropic aclaró que los servidores STDIO tienen el mismo contexto de seguridad que la aplicación que los arranca, y que la sanitización es responsabilidad del desarrollador del servidor. Eso es técnicamente correcto, pero insatisfactorio si como usuario final instalas servidores MCP desde un marketplace y no puedes inspeccionar el código fuente.

La consecuencia práctica, los servidores MCP están hoy en la misma clase de confianza que los paquetes npm, las extensiones de VSCode o cualquier tool CLI que instales. Solo porque un servidor esté listado en un marketplace no significa que haya sido auditado. Los marketplaces de Anthropic no hacen code review, ese no es su rol. El rol que no está cubierto, alguien que revise los servidores antes del listing, podría a medio plazo asumirlo los grandes marketplaces o un organismo independiente. Actualmente no está cubierto.

Recomendación de práctica para tu setup

Si trabajas hoy con MCP, ordena tus servidores en tres categorías.

Categoría uno, los servidores propios de Anthropic (filesystem, fetch, sequential-thinking) y los tuyos. Nivel de confianza alto.

Categoría dos, servidores de proyectos OSS establecidos con una comunidad activa y un maintainer visible (memory server de StudioMeyer, GitHub MCP de github/github-mcp-server, sentry, postgres). Nivel de confianza medio, lee el README, comprueba si hay security statement y CI.

Categoría tres, todo lo demás. Nivel de confianza bajo. No instalar sin un spot check del código fuente.

Si construyes tu propio servidor, tómate 30 minutos y recorre las tres búsquedas de arriba. Si encuentras algo, arréglalo hoy y prueba con un argumento de tool deliberadamente malicioso ("; ls -la" o $(whoami)) si el servidor lo ejecuta o lo rechaza. Si el servidor lo ejecuta, tienes exactamente el patrón que describe OX.

Qué sigue

Si quieres construir tu primer servidor MCP y tener esto en cuenta, el playbook "erster-mcp-server-in-90-minuten" empieza desde cero y hace la sanitización bien desde el principio. Si quieres publicar, "mcp-server-publishen" cubre distribución + señales de confianza. Para aspectos de compliance DACH (encargo de tratamiento, clasificación del EU AI Act), el playbook "dach-legal-eu-ai-act-und-dsgvo" tiene un bloque fresco sobre compliance de seguridad de MCP.

Fuentes principales si quieres profundizar, el post original de OX (ox.security/blog/the-mother-of-all-ai-supply-chains), el análisis de seguimiento sobre Flowise y Upsonic, más las entradas CVE para CVE-2026-40933 (LangFlow) y CVE-2026-30615 (Windsurf) como ejemplos concretos de reproducción.