MCPocalipsis: 30 CVEs contra servidores MCP en 2026

Durante 2025, el Model Context Protocol (MCP) pasó de curiosidad a estándar de facto para conectar modelos de IA con herramientas, bases de datos y APIs. En 2026 llegó la factura: entre enero y febrero se reportaron más de 30 CVEs contra servidores MCP en 60 días, la cadencia siguió y para agosto el conteo supera los 40. No son bugs exóticos: son ejecución de comandos por default, servidores sin autenticación y credenciales viajando en texto plano. Si tenés un agente en producción, esto te toca directo.

El Model Context Protocol es un protocolo abierto —creado por Anthropic y hoy bajo gobernanza de la Linux Foundation— que estandariza cómo un modelo de lenguaje descubre e invoca herramientas externas (archivos, shell, HTTP, bases de datos). Un "servidor MCP" expone esas herramientas; un "cliente MCP" (el agente o el IDE) las consume. La ola de CVEs de 2026 ataca justamente esa capa de servidor: inyección de comandos, falta de autenticación y robo de tokens OAuth.

¿Por qué aparecieron tantos CVEs en los servidores MCP de golpe?

MCPocalipsis: 30 CVEs en 60 días y tus claves en la mira

Porque la falla es de diseño, no de un producto puntual. El transporte STDIO —el canal por default de MCP— nace de arrancar subprocesos y pasarles strings de comando sin sanitizar, así que la ejecución de comandos es prácticamente la interfaz nativa del protocolo. Ese patrón se copió desde los SDKs de referencia hacia miles de proyectos que confiaron en la implementación oficial, y cada copia arrastró el mismo agujero.

La escala del arrastre quedó documentada. Según el informe "Mother of All AI Supply Chains" de Ox Security (abril de 2026), el problema afecta a paquetes con unos 150 millones de descargas acumuladas, con más de 7.000 servidores MCP accesibles públicamente y hasta 200.000 instancias potencialmente vulnerables. La raíz, coinciden los reportes, no fueron zero-days sofisticados sino validación de input ausente, autenticación inexistente y confianza ciega en las descripciones de las herramientas.

Anthropic mantiene que el comportamiento de STDIO es "by design" (por diseño) y funciona como un "secure default", y que la sanitización de la entrada es responsabilidad del desarrollador, según recogió The Hacker News. Ese es exactamente el punto en disputa: un default que asume que todos los que lo copian van a hacer bien la tarea.

¿Qué tipo de fallas son las más comunes en servidores MCP?

La mayoría son inyección de comandos y falta de autenticación, no vulnerabilidades raras. El análisis que reunió los primeros 30 CVEs (enero-febrero de 2026) —discutido a fondo en Hacker News— y las estadísticas recopiladas por Practical DevSecOps muestran un patrón repetido:

Categoría	Peso aproximado
Inyección de shell/exec	43%
Fallas de infraestructura de tooling	20%
Bypass de autenticación	13%
Path traversal	10%

Path traversal casi universal. Sobre 2.614 implementaciones relevadas, el 82% resultó vulnerable a recorrido de rutas, lo que permite leer o escribir archivos fuera del directorio previsto.
Servidores sin ninguna autenticación. Un escaneo de 560 servidores encontró que el 38% no tenía autenticación alguna; cualquiera que llegue al puerto puede invocar las herramientas expuestas.
El caso testigo: CVE-2025-6514. Un RCE en el paquete mcp-remote, con CVSS 9.6, afectó a más de 437.000 descargas: un cliente que se conectaba a un servidor malicioso terminaba ejecutando código arbitrario.
El diagnóstico de julio. De acuerdo con el paper "Exposed by Design" (julio de 2026), sobre 640 servidores de producción auditados el 91,8% carecía de OAuth y 687 instancias exponían herramientas de shell sin restricciones.

¿Cómo terminan robando tus credenciales con un servidor MCP?

Por dos vías principales: interceptando el flujo OAuth y colándose en tus herramientas de confianza (tool poisoning). Un authorization_endpoint malicioso puede capturar los tokens durante la autenticación, antes incluso de que se establezca la sesión. Y como buena parte de los servidores usa endpoints HTTP en texto plano, los tokens, las API keys y los metadatos de sesión quedan expuestos a intercepción en tránsito.

La foto de cómo se guardan esas credenciales es peor que la de cómo viajan. En auditorías sobre más de 5.200 servidores, solo el 8,5% usaba OAuth, el 53% dependía de API keys estáticas o tokens de acceso personal y el 79% pasaba las claves por variables de entorno —donde cualquier herramienta con acceso a exec puede leerlas—. En paralelo, Censys detectó 12.520 servicios MCP expuestos públicamente, cerca del 40% sin autenticar.

El vector más ruidoso de mediados de 2026 fue el tool poisoning. En junio, la campaña del worm Miasma sembró archivos de configuración MCP adversariales en 73 repositorios de GitHub: cualquier desarrollador que clonaba uno de esos repos y lo abría en un IDE vulnerable disparaba un payload que cosechaba credenciales de forma automática. La gracia siniestra es que no explota un bug del servidor: weaponiza la propia herramienta que el agente ya considera confiable.

¿Qué cambió en agosto de 2026?

Se pasó del "problema técnico" al "problema de gobernanza". El MCP Dev Summit de Seúl (13-14 de agosto de 2026) transformó una reunión de rutina en una confrontación de alto voltaje, con más de 21.000 instancias MCP expuestas a internet y cerca del 92% de los servidores de producción auditados sin OAuth básico sobre la mesa, según Forkast.

La gobernanza salió del control de un solo vendor. El protocolo pasó a la Linux Foundation, bajo la Agentic AI Foundation (AAIF), para que las decisiones de diseño —incluida la de STDIO— dejen de depender de una sola empresa.
Entraron los reguladores. El AI Security Center de la NSA publicó en junio de 2026 consideraciones de diseño seguro para MCP, apuntando a serialización, fronteras de confianza y riesgos de confianza implícita.
La spec empuja a OAuth 2.1. La especificación de autorización de MCP exige OAuth 2.1, que obliga a PKCE en todos los clientes, elimina el implicit grant y endurece el manejo de redirect_uri.

¿Qué podés hacer HOY para blindar tu servidor MCP?

Lo más rentable es cerrar la exposición y sacar las credenciales del alcance del agente, en ese orden. Ninguna de estas medidas requiere esperar a un parche del protocolo:

Sacá el servidor de internet. Un servidor MCP casi nunca necesita estar público. Atalo a 127.0.0.1 o a una red privada y ponelo detrás de un reverse proxy con TLS; si tenés que exponerlo, que sea sobre HTTPS, nunca HTTP plano.
Exigí autenticación siempre. Implementá OAuth 2.1 con PKCE o, como mínimo, un gateway con tokens de vida corta. Cero endpoints anónimos: si no hay auth, cualquiera que descubra el puerto es tu nuevo administrador.
No pases secretos por variables de entorno. Usá un gestor de secretos con rotación e inyección efímera en vez de dejar API keys largas en el env del proceso, que cualquier herramienta con exec puede volcar.
Restringí las herramientas peligrosas. Deshabilitá o encajoná (sandbox/allowlist) las herramientas de shell y filesystem. Corré el servidor en un contenedor sin privilegios, con usuario no-root y filesystem de solo lectura donde se pueda.
Desconfiá de configuraciones MCP de terceros. Revisá los archivos de configuración de repos ajenos antes de abrirlos en tu IDE y desactivá la auto-ejecución de herramientas: así se propagó Miasma.
Fijá y auditá las descripciones de las tools. Tratá las descripciones como código no confiable, pineá versiones de los servidores que consumís y logueá cada invocación para detectar tool poisoning.

Si venís de un incidente o sospechás exposición, dos temas que ya cubrimos en el blog aplican directo acá: "Rotar claves y tokens después de una exposición accidental" y "Gestionar Secretos en CI/CD con OIDC y Vault para evitar credenciales permanentes". Son la contención inmediata mientras endurecés el servidor MCP.

Preguntas frecuentes

¿Tengo que dejar de usar MCP?

No. MCP sigue siendo el estándar para agentes y el problema es de configuración, no del concepto. Lo que hay que abandonar es el default inseguro: servidores públicos, sin auth y con shell habilitada. Con OAuth, red privada y herramientas restringidas, el riesgo baja drásticamente.

¿Alcanza con poner OAuth?

No alcanza por sí solo. OAuth 2.1 cierra el robo de credenciales por endpoints anónimos, pero no frena la inyección de comandos ni el tool poisoning. Necesitás además sandboxear las herramientas peligrosas, validar inputs y no confiar ciegamente en descripciones de tools de terceros.

¿Cómo sé si mi servidor MCP está expuesto a internet?

Chequeá a qué interfaz está bindeado el proceso. Si escucha en 0.0.0.0 y el puerto es alcanzable desde afuera, está expuesto. Escaneá tu propio rango con una herramienta de descubrimiento y confirmá que el servidor solo responde en localhost o en la red interna, no en la IP pública.

¿Qué es exactamente un ataque de tool poisoning?

Es inyectar instrucciones o herramientas maliciosas en el contexto que el agente considera confiable, para que ejecute acciones no deseadas —como filtrar credenciales— creyendo que usa una tool legítima. No explota un bug del servidor: abusa de la confianza implícita del agente en las descripciones y configuraciones de las herramientas.

¿Los CVEs afectan solo a servidores propios o también a los que consumo?

A los dos. Casos como CVE-2025-6514 en mcp-remote demuestran que un cliente que se conecta a un servidor malicioso también puede terminar ejecutando código. Pineá versiones, revisá los servidores de terceros que consumís y actualizá los SDKs de MCP apenas salen parches.