Reutilizar instancias de servidor MCP filtra datos entre clientes
Un fallo de diseño en el SDK de TypeScript oficial del Model Context Protocol permitía que un servidor o transporte compartido enrutara los resultados de herramientas, notificaciones y peticiones de sampling de un cliente hacia otro. Corregido en 1.26.0.
¿Qué es esto?
El 4 de febrero de 2026, un mantenedor del SDK de TypeScript oficial del Model Context Protocol (MCP) publicó un aviso de seguridad sobre una fuga de datos entre clientes en @modelcontextprotocol/sdk. No es un payload ni una inyección: es un error de concurrencia en la forma en que el SDK enruta las respuestas. Cuando una única instancia de servidor o de transporte HTTP se comparte entre varios clientes conectados, un cliente puede recibir datos destinados a otro: resultados de herramientas, contenidos de recursos, notificaciones de progreso y peticiones de sampling o de elicitation pueden entregarse a la conexión equivocada.
El aviso afecta a las versiones 1.10.0 a 1.25.3 del SDK y está corregido en 1.26.0. Tiene una puntuación de 7,1 (alta) y se clasifica como condición de carrera (CWE-362). Lo señalamos porque el patrón vulnerable —un solo objeto servidor que atiende todas las peticiones— es exactamente como muchos desarrolladores montan por primera vez un servidor MCP, y porque MCP es hoy el tejido conectivo entre los agentes LLM y las herramientas empresariales. Este artículo es un resumen defensivo; no reproduce ningún exploit, porque ninguno es necesario para comprender el fallo.
Cómo funciona
El aviso describe dos problemas distintos pero relacionados, y un despliegue puede sufrir uno, el otro o ambos.
El primero es la reutilización del transporte. El transporte HTTP en streaming del SDK mantiene una tabla interna que asocia un identificador de petición JSON-RPC con el flujo HTTP que espera esa respuesta. Los clientes MCP generan sus identificadores con un contador que empieza en cero y se incrementa. Así, dos clientes que se conectan de forma independiente envían ambos el identificador 0, luego 1, luego 2. Si una sola instancia de transporte los atiende, la entrada del segundo cliente sobrescribe la del primero en la tabla, y la respuesta se escribe en el flujo equivocado. Todos los tipos de petición quedan expuestos —llamadas a herramientas, lecturas de recursos, obtención de prompts— y no se requiere ninguna función iniciada por el servidor para provocarlo.
El segundo es la reutilización del servidor (protocolo). Cuando un único objeto servidor se conecta a varios transportes, uno por cliente, la capa de protocolo mantiene una única referencia al «transporte actual», y cada nueva conexión la sobrescribe silenciosamente. Las respuestas finales suelen enrutarse correctamente, porque la referencia se captura cuando llega la petición, pero todo lo que se envía durante el procesamiento —notificaciones de progreso, llamadas de sampling al modelo, prompts de elicitation o notificaciones espontáneas del servidor— pasa por la referencia compartida y puede acabar en la conexión de otro cliente.
La causa común es un estado mutable compartido sin aislamiento por cliente, que solo se manifiesta bajo concurrencia. La configuración más expuesta es el modo stateless, donde un servidor se instancia sin generador de sesión y se reutiliza entre peticiones para ahorrar asignaciones —un atajo de rendimiento habitual que se convierte en una ruptura de frontera de datos en cuanto dos usuarios están activos a la vez.
Por qué importa
Los servidores MCP se sitúan cada vez más delante de datos reales: almacenes de archivos, bases de datos, sistemas de tickets, API internas y las credenciales que esas herramientas transportan. Una respuesta mal enrutada no es, por tanto, un defecto cosmético: puede entregar a un inquilino los resultados de consulta, contenidos de documentos o mensajes de error de otro inquilino. En un despliegue multiusuario, eso cruza una frontera de seguridad que el operador suponía garantizada por el framework.
La exposición es amplia precisamente porque el error reside en el SDK de referencia y no en un único producto. Cualquier servidor MCP alojado construido sobre las versiones afectadas y que atienda clientes concurrentes puede verse afectado, y el desencadenante es la carga ordinaria, no un ataque diseñado. La baja probabilidad de explotación medida refleja que un atacante no puede elegir de forma fiable qué datos recibe, pero una fuga accidental entre inquilinos bajo tráfico normal es en sí misma un problema de confidencialidad y de cumplimiento, con independencia de que alguien intente explotarla activamente.
Defensas
Actualice el SDK a la versión 1.26.0 o posterior. La corrección no disimula la carrera: convierte el enrutamiento erróneo silencioso en errores ruidosos e inmediatos —conectar un protocolo ya conectado ahora lanza una excepción, y un transporte stateless se niega a atender más de una petición—, de modo que las configuraciones incorrectas fallan en modo cerrado en lugar de filtrar.
Si no puede actualizar de inmediato, cree una nueva instancia de servidor y de transporte por conexión. En modo stateless, instáncielos dentro del manejador de la petición y destrúyalos después; en modo stateful, asocie un nuevo servidor y transporte al identificador de sesión y almacénelos por sesión. No comparta nunca un único objeto servidor entre sesiones si sus herramientas envían notificaciones de progreso, sampling o elicitation durante la ejecución.
Audite la topología de su despliegue. Pregúntese con precisión: ¿se reutiliza un único objeto servidor o transporte entre peticiones, y pueden dos clientes estar en curso a la vez? Si es así, coincide con el patrón vulnerable independientemente de la versión del SDK, y debería confirmar la presencia de las salvaguardas de ejecución.
Trate el aislamiento entre inquilinos como algo que se verifica, no que se supone. Añada pruebas de integración que hagan pasar a dos clientes concurrentes por el mismo servidor y comprueben que cada uno recibe solo sus propias respuestas, así como telemetría capaz de detectar una respuesta que llega a una sesión inesperada. La lección general sobrevive a esta única referencia: en la infraestructura de agentes, el estado por cliente debe ser por cliente por construcción, y «reutilizar el objeto para ir más rápido» es una decisión de frontera de datos, no solo de rendimiento.
Estado
| Elemento | Detalle |
|---|---|
| Componente | @modelcontextprotocol/sdk (SDK de TypeScript de MCP) |
| Aviso | GHSA-345p-7cg4-v4c7 / CVE-2026-25536, publicado el 4 de febrero de 2026 |
| Afectado | 1.10.0 a 1.25.3 |
| Corregido | 1.26.0 |
| Clase | Condición de carrera (CWE-362), enrutamiento erróneo de respuestas entre clientes |
| Severidad | 7,1 (alta); impacto de confidencialidad alto, probabilidad de explotación baja |
| Explotación | Sin evidencia pública de explotación |