Seguridad en servidores MCP: lo que enseñan dos meses de avisos

La seguridad MCP de un servidor es lo que impide que una petición, un cliente o una página web hagan con él algo que su dueño no autorizó, como agotarlo, desviar sus credenciales o ejecutar sus herramientas sin permiso. Entre agosto y principios de octubre de 2026, la mayoría de los SDK oficiales y varios servidores populares publicaron avisos. Leídos juntos, dibujan los mismos pocos fallos una y otra vez.

Aquí los tienes ordenados por patrón, con lo que cambia al actualizar los SDK de TypeScript y Python y una checklist para revisar tu servidor.

Resumen: tres patrones en los SDK y uno fuera

En los SDK oficiales se repiten tres familias de fallos en todos los lenguajes:

1. Denegación de servicio por lecturas sin límite: cuerpos HTTP, eventos SSE y líneas de stdio que se leen enteros en memoria.
2. Confusión del servidor de autorización en OAuth: el cliente no valida bien el issuer ni el resource y acaba entregando credenciales a quien no debe.
3. Redirecciones entre orígenes que reenvían cabeceras a otro dominio.

Fuera de los SDK, en servidores y gateways de terceros, el patrón más repetido es otro: DNS rebinding contra transportes HTTP locales que no validan Origin ni Host.

Estos son los avisos de los SDK oficiales del periodo, en orden cronológico:

Fecha	SDK	Severidad	Qué falla	CVE	Aviso
14 de agosto de 2026	PHP	Alta	DoS por un buffer SSE sin límite	CVE-2026-53965	GHSA-7m52-jw36-44r3
15 de agosto de 2026	Ruby	Media	SSRF a hosts privados en el descubrimiento OAuth	—	GHSA-4m5j-jjfc-97gx
19 de agosto de 2026	Java	Alta y media	Lecturas sin límite en el cuerpo HTTP del servidor (CWE-770) y en el SSE del cliente	—	v2.0.1
3 de septiembre de 2026	Kotlin	Alta y media	DoS sin autenticación en Streamable HTTP al saltarse el límite de tamaño de petición; memoria sin límite en el cliente	CVE-2026-63658, CVE-2026-63657	avisos de Kotlin
16 y 17 de septiembre de 2026	Rust (rmcp)	Alta, alta y media	Falta validar resource en el descubrimiento OAuth; fuga de sesiones que permite DoS; un tercer aviso. El 2 de octubre, otro sobre URLs resource_metadata controladas por el servidor	CVE-2026-63127, CVE-2026-63128, CVE-2026-64684	GHSA-33f5-2c5q-wgwj, GHSA-9pj6-vhgr-3mwh
28 de septiembre a 2 de octubre de 2026	Python	Altas y medias	Credenciales OAuth enviadas a un servidor de autorización elegido por el servidor MCP; $ref remotos al validar outputSchema; sesiones nunca liberadas; cuerpos sin límite; redirecciones entre orígenes	CVE-2026-59951	avisos de Python
30 de septiembre a 2 de octubre de 2026	TypeScript	Altas y media	El mismo fallo de credenciales OAuth; tareas experimentales no ligadas a la sesión que las creó; redirecciones entre orígenes	—	avisos de TypeScript

Python y TypeScript publicaron sus avisos de forma coordinada y los corrigen en sus versiones 2.2.0 y 2.3.0 (TypeScript, Python).

Denegación de servicio por lecturas sin límite

Es la familia más extendida. La abrió PHP el 14 de agosto con un buffer SSE que crecía sin tope. Java publicó el 19 de agosto las versiones 2.0.1, 1.1.4 y 0.18.4, que acotan las lecturas en HTTP y stdio (v2.0.1). Kotlin siguió el 3 de septiembre. La variante de memoria que no se libera aparece en rmcp (fuga de sesiones) y en Python (sesiones que nunca se liberaban, CVE-2026-59951).

Otros SDK se endurecieron sin esperar a un aviso. Go 1.8.0 (14 de septiembre) limita la profundidad del JSON, el tamaño de los eventos SSE y el de las líneas de stdio (release). Python 2.1.0 (24 de agosto) aplica su límite de 4 MiB por petición también a SSE y a OAuth (release).

En la práctica, si usas el transporte del SDK actualizado, los límites ya vienen puestos. Si tienes un proxy, un gateway o un transporte propio, cada lectura de la red necesita un tope: cuerpo, evento, línea y profundidad. Y cada estructura que crece por cliente necesita caducidad y un máximo.

En su guía de seguridad para herramientas, la especificación 2026-07-28 pide a los servidores validar entradas y limitar la tasa. Un límite de tamaño es la forma más barata de empezar.

Confusión del servidor de autorización en OAuth

En un servidor MCP protegido, el cliente descubre a qué servidor de autorización tiene que ir a partir de lo que le indica el propio servidor MCP. Si el cliente no comprueba esa información, un servidor MCP malicioso o comprometido puede señalar un servidor de autorización que no es el legítimo y recibir credenciales que no le corresponden.

Python y TypeScript corrigieron justo eso a finales de septiembre. Su cliente OAuth podía enviar credenciales a un servidor de autorización elegido por el servidor MCP, y los dos lo calificaron de severidad alta. En rmcp, el fallo equivalente era no validar el campo resource en el descubrimiento (CVE-2026-63127, GHSA-33f5-2c5q-wgwj). En Ruby, el descubrimiento OAuth permitía SSRF hacia hosts privados.

La especificación 2026-07-28 ya tiene las piezas para evitarlo:

• El issuer de la metadata del servidor de autorización MUST ser idéntico al identificador con el que se construyó la URL well-known. Si no lo es, el cliente no la usa.
• Las credenciales MUST quedar asociadas al servidor de autorización que las emitió, indexadas por su issuer (SEP-2352), y no se reutilizan si este cambia.
• El cliente valida el parámetro iss de la respuesta de autorización (RFC 9207, SEP-2468) contra el issuer guardado antes de enviar el código a ningún token endpoint, sin normalizar nada.

En el SDK de TypeScript, la 2.2.0 (28 de septiembre) añade expectedIssuer y depreca construir ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider y CrossAppAccessProvider sin él. La 2.3.0 (2 de octubre) añade expectedResource (releases).

Este fallo vive en el lado cliente. Te afecta si tu servicio actúa también como cliente MCP, es decir, si es un gateway, un agente o un servidor que llama a otros.

En el lado servidor, implementar la identificación del emisor ya tiene efecto práctico. Desde el 21 de agosto, ChatGPT acepta su client ID de tipo CIMD en servidores que implementan la identificación del emisor de RFC 9207 (changelog de OpenAI). Quién soporta qué está en MCP 2.0 en producción.

Redirecciones entre orígenes

Python y TypeScript seguían redirecciones HTTP hacia otro origen reenviando las cabeceras de la petición original. Los dos lo marcaron como severidad media. La corrección cambia un comportamiento por defecto: Python 2.2.0 y TypeScript 2.3.0 solo siguen redirecciones al mismo origen (Python, TypeScript).

Esto afecta a quien mantiene un servidor. Si moviste tu endpoint MCP a otro dominio y dejaste una redirección en la URL antigua, los clientes con estos SDK dejarán de seguirla. Publica la URL final.

DNS rebinding en servidores locales

Un servidor MCP local con transporte HTTP suele no pedir autenticación porque “solo es accesible desde aquí”. El DNS rebinding rompe esa suposición: una página web que visitas consigue que tu navegador envíe peticiones a ese servidor local, y si este no comprueba Origin y Host, no las distingue de las de tu cliente MCP.

El caso más claro del periodo es mysql-mcp-server: su transporte SSE no validaba Origin ni Host, y eso permitía ejecutar SQL sin autenticación. El aviso es del 11 de septiembre y tiene CVSS 10 (CVE-2026-59971, GHSA-rqfv-2mw9-78g2).

En la GitHub Advisory Database, el patrón aparece en el periodo en al menos cinco proyectos. Entre ellos:

• @zereight/mcp-gitlab, con tres avisos críticos el 15 y el 16 de septiembre por SSRF, DNS rebinding y una lectura de ficheros que expone el token de acceso personal.
• @bytebase/dbhub: DNS rebinding con ejecución de SQL, crítico, el 24 de septiembre.

La especificación 2026-07-28 es explícita para Streamable HTTP. Los servidores MUST validar la cabecera Origin y responder 403 Forbidden si está presente y no es válida. En local, SHOULD escuchar solo en 127.0.0.1. Cómo se cumple depende de cómo montes el servidor:

• TypeScript. createMcpExpressApp() valida Host y Origin por defecto al enlazar a 127.0.0.1. Si enlazas a 0.0.0.0, tienes que pasarle allowedHosts. createMcpHandler no valida Host, Origin ni tokens: si lo montas en tu propio framework, esa validación es tuya.
• Python. El SDK oficial escucha por defecto en 127.0.0.1. Para desplegar fuera de localhost, su guía de despliegue indica configurar TransportSecuritySettings con allowed_hosts y allowed_origins.
• Cloudflare. Si usas el createMcpHandler de Workers en un dominio propio con CORS comodín, tienes que configurar allowedHostnames y allowedOriginHostnames de forma explícita.

Otros avisos graves en servidores de terceros

Lo más grave del periodo, según la GitHub Advisory Database:

• mcp-atlassian: unos 25 avisos el 22 de septiembre, entre ellos un bypass de autenticación en el transporte HTTP con CVSS 10 (CVE-2026-77244), lecturas arbitrarias de ficheros y SSRF (GHSA-wrhw-j3f9-8vc6).
• IBM mcp-contextforge-gateway: escape del sandbox de RestrictedPython, CVSS 10, el 24 de agosto (CVE-2026-53710, GHSA-xm98-3vcf-fph7), además de SSTI con ejecución remota de código y SSRF por un TOCTOU de DNS.
• Chainlit: inyección de comandos a través del transporte stdio de MCP, CVSS 9.8, el 25 de agosto (CVE-2026-45018).
• ToolHive (Stacklok): contenedores MCP que alcanzaban servicios del host (CVE-2026-58197), el 18 de septiembre.
• Obot: SSRF y robo de tokens por registro dinámico de clientes, también el 18 de septiembre.
• chrome-devtools-mcp: validatePath() no resolvía los enlaces simbólicos antes de comprobar la ruta, el 17 de agosto (CVE-2026-53766).

Qué cambia al actualizar el SDK de TypeScript o Python

Las últimas versiones estables antes del corte son TypeScript 2.3.0 y Python 2.3.0, las dos del 2 de octubre. Además de corregir los avisos, cambian comportamientos por defecto que pueden romper configuraciones laxas (TypeScript, Python, Python 2.1.0):

SDK y versión	Fecha	Cambio	Qué revisar
Python 2.1.0	24 de agosto de 2026	Deja de enviar al cliente el texto de las excepciones inesperadas; el límite de 4 MiB por petición se aplica también a SSE y OAuth	Si tus clientes dependían de ese texto para depurar, devuelve errores explícitos desde tus herramientas
Python 2.2.0	7 de septiembre de 2026	Redirecciones solo al mismo origen; las sesiones legadas inactivas caducan (30 minutos, máximo 10 000)	Endpoints que redirigen a otro dominio; clientes con handshake que esperan sesiones largas
Python 2.3.0	2 de octubre de 2026	Valida x-mcp-header al registrar herramientas	Herramientas que declaran esa cabecera
TypeScript 2.1.0	23 de septiembre de 2026	Scope challenges por primitiva (403 insufficient_scope)	Que tus scopes cubran cada herramienta, recurso o prompt que expones
TypeScript 2.2.0	28 de septiembre de 2026	expectedIssuer; deprecación de los proveedores de credenciales sin él; listas completas siguiendo el cursor	Proveedores OAuth de tus clientes y gateways
TypeScript 2.3.0	2 de octubre de 2026	“One server per request”; redirecciones solo al mismo origen; maxToolInputElements; expectedResource	Estado compartido entre peticiones; URLs con redirección

Sobre “one server per request”: si ya sirves 2026-07-28 con createMcpHandler(factory), pasas una fábrica y no una instancia. Registra herramientas y recursos dentro de la fábrica y deja fuera solo lo que de verdad deba compartirse entre peticiones, como pools de conexiones o cachés.

La rama 1.x también tuvo versiones en el periodo (TypeScript 1.30.1, 1.31.0 y 1.32.0; Python 1.29.1 y 1.30.0), pero no hemos comprobado qué avisos corrige cada una. Si sigues en ella, míralo en los avisos de cada repositorio.

Herramientas de gobierno: shadow MCP y WriteGuard

Parte de la seguridad está fuera del código del servidor: consiste en saber qué servidores se usan y qué hacen. Cloudflare sacó dos productos para eso en agosto.

• WriteGuard, en beta privada desde el 5 de agosto: políticas, atribución y auditoría de las herramientas de escritura en servidores MCP (blog de Cloudflare).
• Detección de shadow MCP, el 14 de agosto: Cloudflare Gateway reconoce el tráfico MCP por la cabecera MCP-Protocol-Version, lo muestra en un panel y permite bloquear las conexiones que no pasan por un Portal (blog de Cloudflare).

Con Cloudflare o sin él, la pregunta es la misma: ¿tienes un inventario de los servidores MCP a los que se conectan tus agentes?

La infraestructura del propio proyecto también tuvo avisos. El 6 de agosto, el MCP Registry corrigió en la v1.8.1 una toma de espacios de nombres. Quien tuviera permiso de escritura en el repositorio <org>.github.io podía publicar bajo io.github.<org>/* (PR #1506). El 23 de agosto salió otro aviso, de severidad alta, por inyección de comandos en un workflow de los SEPs (GHSA-7fx6-5m9f-89wg). Afectaba a la gobernanza, no al protocolo.

OWASP: estado del MCP Top 10

El OWASP MCP Top 10 no se movió en el periodo. Su página dice que está en “Phase 3 – Beta Release and Pilot Testing” y anuncia “Next Release in October 2026”. Las categorías van de MCP01:2025 a MCP10:2025, y la MCP06 se llama ahora “Intent Flow Subversion”. El repositorio no tiene commits desde el 29 de julio (OWASP MCP Top 10). A 3 de octubre, la versión anunciada para octubre no se ha publicado.

Lo que OWASP sí publicó, el 2 de septiembre, fue el Top 10 para aplicaciones LLM 2026 y la donación del Agent Control Standard, a través del OWASP GenAI Security Project. Ese anuncio no menciona MCP (OWASP GenAI).

Checklist para tu servidor MCP

Cada punto sale de uno de los avisos o de un requisito de la especificación 2026-07-28 citados arriba.

Transporte

• En local, el servidor escucha en 127.0.0.1, no en 0.0.0.0.
• Valida Origin (403 si no es válido) y Host, aunque sea local y no tenga autenticación. Si montas createMcpHandler en tu propio framework, la validación la pones tú.
• Hay tope para el tamaño del cuerpo, de cada evento SSE, de cada línea de stdio y para la profundidad del JSON.
• Las sesiones que mantengas para clientes con handshake caducan y tienen un máximo.
• Tu endpoint publicado es la URL final, sin redirecciones a otro dominio.

Autorización

• Aplicas control de acceso por primitiva, no solo a la entrada del servidor.
• Si tu servicio actúa como cliente MCP: fija expectedIssuer y expectedResource (TypeScript) o su equivalente, valida iss y asocia las credenciales al issuer que las emitió.
• Al validar esquemas, no resuelves $ref remotos.

Herramientas

• Los errores que devuelves al cliente no incluyen el texto de excepciones inesperadas.
• Si una herramienta recibe rutas, resuelve los enlaces simbólicos antes de comprobar que la ruta cae dentro de lo permitido.
• Ninguna entrada del cliente acaba sin sanear en un comando del sistema, también cuando el transporte es stdio.
• No confías en un sandbox de lenguaje como única barrera para ejecutar código.

Operación

• Usas TypeScript 2.3.0 o Python 2.3.0, o la versión del periodo de tu SDK que corrige sus avisos.
• Revisas los avisos de tus dependencias MCP en la GitHub Advisory Database, no solo los del SDK.
• Tienes inventario de los servidores MCP que usan tus agentes y registro de las herramientas de escritura.

En el curso, la lección “Seguridad avanzada” del nivel Experto trabaja el modelo de amenazas de MCP y las defensas en profundidad, y “APIs externas y autorización” del nivel Avanzado recorre OAuth 2.1 de extremo a extremo. Las dos están en el temario.

Dos lecturas relacionadas: cómo saber qué ofrece un servidor remoto antes de conectarte a él está en Server Cards y AI Catalog, y por qué una herramienta no debería completar un pago sin el usuario, en WebMCP en tiendas y pagos.