Los SDK oficiales de MCP para Python y TypeScript corrigieron un problema por el que determinados clientes OAuth podían enviar credenciales a un servidor de autorización elegido por un servidor MCP malicioso o comprometido. Actualizar el paquete no resuelve todas las configuraciones: hay proveedores que necesitan declarar el emisor esperado y registros antiguos que siguen sin estar vinculados a él.
Los avisos oficiales son del 28 de septiembre de 2026 en Python y del 30 de septiembre en TypeScript. Recuperamos el asunto el 5 de noviembre tras descubrir la explicación técnica que el investigador publicó el 2 de noviembre. No son parches recién anunciados el día 3, fecha de la newsletter que nos llevó a ellos.
El servidor de herramientas no debe elegir el destino de un secreto existente
MCP, Model Context Protocol, conecta aplicaciones de IA con herramientas y datos. Algunos clientes se conectan por HTTP y utilizan OAuth para autorizar el acceso. El fallo descrito está en esa parte del cliente, no en cualquier uso del protocolo.
El issuer identifica al servidor de autorización que emitió o al que pertenecen las credenciales. Puede ser distinto del servidor MCP. Los avisos explican que faltaban comprobaciones del emisor o una vinculación suficiente entre ese emisor y las credenciales guardadas o preconfiguradas.
Como ejemplo hipotético, un agente utiliza credenciales de un servicio corporativo y después se conecta a otro servidor MCP. Si este último anuncia un servidor de autorización controlado por un atacante, un cliente afectado puede reutilizar allí información que pertenecía al primero. Es una ilustración del riesgo documentado, no una prueba ejecutada por Puntoes.
En Python, los datos expuestos pueden incluir un secreto de cliente, un código de autorización y su verificador PKCE —una protección del intercambio de código—, o una aserción firmada. En TypeScript, el aviso incluye tokens de renovación, secretos y aserciones, según el flujo. Una aserción firmada no es la clave privada con la que se firma.
Qué paquetes revisar
El encabezado del aviso de Python identifica mcp desde 1.9.1 hasta antes de 1.30.0, y desde 2.0.0a1 hasta antes de 2.2.0. Las versiones corregidas son 1.30.0 y 2.2.0, respectivamente. La exposición concreta depende del proveedor OAuth y de la vía de descubrimiento utilizada.
En TypeScript figuran @modelcontextprotocol/sdk desde 1.12.0 hasta antes de 1.31.0, y @modelcontextprotocol/client desde 2.0.0 hasta antes de 2.2.0. Las correcciones son 1.31.0 y 2.2.0. Si se importa directamente @modelcontextprotocol/core en la rama 2.x, el aviso pide también 2.2.0 o posterior.
Conviene comprobar el paquete realmente desplegado y su rama antes de planificar la actualización. Estos números no son una indicación de mezclar las dependencias 1.x y 2.x sin revisar compatibilidad.
Tres capas de la reparación
Primero, la configuración del proveedor. En Python, ClientCredentialsOAuthProvider y PrivateKeyJWTOAuthProvider necesitan issuer= con el emisor legítimo. Sin él siguen aceptando el servidor de autorización anunciado. En 1.30.0 la advertencia es una DeprecationWarning, normalmente oculta. El proveedor obsoleto RFC7523OAuthClientProvider de 1.x no tiene esa opción y debe sustituirse.
En TypeScript, los proveedores incluidos que enumera el aviso necesitan expectedIssuer. Un proveedor propio debe conservar issuer al guardar tokens e información del cliente. No basta con que el código de la dependencia conozca ese campo si el almacenamiento de la aplicación lo elimina.
Segundo, las credenciales ya guardadas. Los registros anteriores pueden carecer de emisor. Los avisos indican vincularlos al emisor legítimo conocido o limpiar el estado OAuth correspondiente para repetir el registro o la autorización. Esa operación debe acotarse y coordinarse: puede interrumpir sesiones y no exige borrar indiscriminadamente todos los secretos del sistema.
Tercero, la posible exposición previa. Si un cliente afectado pudo conectarse a un servidor no fiable, los mantenedores recomiendan rotar los secretos o claves de firma pertinentes y revocar los tokens. Instalar el parche no recupera un secreto que ya se haya enviado.
Qué no cubre esta conclusión
Los avisos excluyen los servidores construidos con estos SDK y los clientes por entrada y salida estándar, stdio. El de Python también excluye los clientes que adjuntan sus propios tokens o cabeceras sin utilizar el proveedor OAuth afectado. No describen una ejecución remota de código ni un compromiso universal de los agentes MCP.
TypeScript señala además rutas no cubiertas por el arreglo: llamadas directas a refreshAuthorization() o exchangeAuthorization(), nuevas autorizaciones interactivas y la rama 2.x con skipIssuerMetadataValidation: true. Hay que revisar esas condiciones por separado.
La lección coincide con nuestro antecedente sobre parches y configuración en Strands, LangGraph, FastMCP y MLflow, pero son avisos diferentes. Aquí la comprobación útil une versión, proveedor, emisor y almacenamiento. Las fuentes consultadas no acreditan víctimas concretas en producción; tampoco hemos realizado una prueba de explotación.