En el Python SDK oficial para Model Context Protocol (MCP), un estándar abierto para conectar aplicaciones de IA con herramientas y datos externos, se ha descubierto una vulnerabilidad de alta gravedad. Un servidor MCP malicioso podía redirigir las credenciales OAuth de la aplicación cliente (client secret, código de autorización y verificador PKCE) hacia un endpoint controlado por el atacante y, a continuación, obtener un token de acceso válido del servidor de autorización legítimo. Los fallos se han corregido en las versiones 1.30.0 y 2.2.0, pero para dos de los proveedores afectados la actualización por sí sola no basta: es necesario configurar adicionalmente el parámetro issuer=.
Esencia de la vulnerabilidad y mecanismo de ataque
Según el aviso de seguridad oficial (GHSA-qx49-fqc8-xw99), el problema radica en una validación insuficiente de la autenticidad de los datos (CWE-345) y una protección insuficiente de las credenciales (CWE-522). Cuando el cliente MCP inicia la autenticación OAuth, solicita al servidor MCP información sobre el servidor de autorización. En las versiones vulnerables, el SDK no validaba la respuesta recibida, lo que permitía al servidor malicioso:
- especificar su propio servidor de autorización en los metadatos del recurso protegido;
- no publicar metadatos del recurso protegido y, en su lugar, proporcionar metadatos en los que el emisor indicado sea el servidor de autorización legítimo, pero los tokens se envíen en realidad al endpoint del atacante.
Como resultado, el cliente entregaba al atacante el client_secret, el código de autorización y el verificador PKCE code_verifier, un valor de un solo uso destinado a impedir la reutilización de un código de autorización interceptado. La entrega del verificador neutraliza por completo esta protección. El secret del cliente es de larga duración y sigue siendo válido hasta que se fuerce su rotación.
Para el proveedor interactivo OAuthClientProvider, el usuario aún debe confirmar el inicio de sesión, pero, como señala la empresa Cycode, que descubrió la vulnerabilidad, la página de confirmación es la página de inicio de sesión legítima del servicio: visualmente no hay nada sospechoso. Dos proveedores para la interacción entre máquinas (ClientCredentialsOAuthProvider y PrivateKeyJWTOAuthProvider) no requieren participación humana en absoluto.
Versiones y configuraciones afectadas
El paquete vulnerable es mcp (pip). Versiones afectadas:
- 1.9.1 — 1.29.1: falta de comprobación del emisor y de vinculación de credenciales en todas las rutas;
- 2.0.0 — 2.1.1: las comprobaciones no se realizan al usar la ruta de reserva obsoleta (cuando el servidor no publica metadatos del recurso protegido) o al responder con
403 insufficient_scope; - Todas las versiones alfa desde 2.0.0a1 hasta versiones anteriores a 2.2.0.
La aplicación es vulnerable cuando se cumplen simultáneamente dos condiciones: utiliza el SDK como cliente MCP sobre HTTP con uno de los manejadores OAuth (OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider o el obsoleto RFC7523OAuthClientProvider) y puede conectarse a un servidor MCP que el operador no controla completamente, disponiendo al mismo tiempo de credenciales para un servidor de autorización legítimo.
No se ven afectados: los servidores MCP construidos sobre el SDK; los clientes que utilizan conexión local (stdio); los clientes que adjuntan por su cuenta los tokens o cabeceras.
Evaluación de gravedad
El aviso asigna a la vulnerabilidad una puntuación CVSS 7.5 (High) para los proveedores que operan sin intervención humana. Para el OAuthClientProvider interactivo, donde se requiere confirmación del usuario, la puntuación es de 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N). En el momento de la publicación del aviso aún no se había asignado identificador CVE.
Ni el aviso de seguridad ni el informe de Cycode contienen datos sobre explotación activa de la vulnerabilidad.
Evaluación del impacto
La vulnerabilidad supone el mayor riesgo para las organizaciones que despliegan aplicaciones de IA basadas en MCP que se conectan a servidores MCP de terceros a través de HTTP y utilizan OAuth para la autenticación. El escenario con proveedores entre máquinas es especialmente crítico: el ataque está completamente automatizado y no requiere ingeniería social. El token de acceso obtenido por el atacante hereda todos los permisos concedidos a la aplicación, lo que puede desembocar en la plena toma de control de la cuenta en el servicio legítimo.
Recomendaciones de mitigación
Actualizar el paquete es un paso necesario, pero no siempre suficiente. El procedimiento completo es:
- Actualice el paquete a la versión 1.30.0 (rama 1.x) o a la versión 2.2.0 (rama 2.x). En las versiones corregidas, el cliente determina el servidor de autorización esperado antes de recibir cualquier metadato y rechaza los que no coincidan.
- Para
ClientCredentialsOAuthProvideryPrivateKeyJWTOAuthProvider, es obligatorio pasar el parámetroissuer=con la dirección del servidor de autorización legítimo (por ejemplo,issuer="https://auth.example.com"). Sin este parámetro, los proveedores actualizados siguen obedeciendo al servidor de autorización especificado por el servidor MCP. En la versión 1.30.0, la advertencia sobre la ausencia deissuer=se emite como una advertencia estándar de deprecación que Python oculta por defecto, por lo que es fácil pasarla por alto. - El obsoleto
RFC7523OAuthClientProviderno admite el parámetroissuer=. Es necesario migrar a uno de los otros dos proveedores. - Limpie los registros OAuth almacenados una sola vez tras la actualización. Los registros creados antes de la corrección no están vinculados a un servidor de autorización concreto y permanecerán en ese estado.
- Si el cliente pudo conectarse a un servidor MCP no confiable, rote el secret del cliente y revoque sus tokens en el servidor de autorización.
Para las versiones anteriores a las corregidas, la única medida es conectar los clientes OAuth exclusivamente a servidores MCP de confianza.
Cronología de divulgación
Las correcciones con validación del emisor se incorporaron a las versiones 1.30.0 y 2.2.0 del 7 de septiembre de 2026 y se describieron en las notas de la versión como un cambio de comportamiento, no como una corrección de seguridad. El aviso de seguridad se publicó el 28 de septiembre, el mismo día en que Cycode difundió su análisis. En el aviso figuran ocho personas como informantes del problema, incluido el investigador de Cycode.
Las organizaciones que utilicen MCP Python SDK para clientes HTTP con autenticación OAuth deben actualizar inmediatamente el paquete a la versión 1.30.0 o 2.2.0, asegurarse de que el parámetro issuer= esté configurado para los proveedores entre máquinas, limpiar los registros antiguos y, si existe sospecha de compromiso, rotar los secretos. El intervalo de tres semanas entre la publicación del parche y la del aviso implica que algunos usuarios pudieron actualizar sin ser conscientes de la criticidad del cambio.
