Actualizan SDK de Python MCP a 1.30.0/2.2.0 para corregir vulnerabilidad de credenciales OAuth

Los mantenedores del SDK oficial de Python para el Model Context Protocol (MCP) han corregido una vulnerabilidad que permitía a un servidor MCP malicioso engañar a un cliente y hacer que entregara credenciales OAuth válidas usadas para iniciar sesión en un servicio real. En las versiones afectadas, el cliente enviaba al atacante su client secret, el authorization code y la clave PKCE (proof key), elementos suficientes para que el atacante solicitara un token de acceso con los permisos que la aplicación había recibido.

De forma técnica, el problema surge en la fase en que un cliente MCP pide al servidor con el que se conecta la ubicación de su servicio de autorización (authorization server). En las versiones vulnerables, el SDK no comprobaba de forma fiable que la URL o el emisor (issuer) del servidor de autorización coincidiera con el que el cliente esperaba antes de seguir el intercambio OAuth. Un servidor malicioso podía responder apuntando al endpoint de token controlado por el atacante —o falsificar metadatos que nombraran al servicio legítimo mientras dirigían las solicitudes a otro lado— y así recibir el secreto de cliente, el código de autorización y el valor PKCE. La entrega del valor PKCE elimina la protección que impide reutilizar un código de autorización interceptado.

Cycode, la firma que informó y demostró el problema, realizó un intercambio de prueba y mostró que el token resultante llevaba los mismos permisos que los autorizados originalmente para la aplicación. El advisory del SDK sitúa la gravedad en 7.5 para los proveedores que operan sin presencia humana (machine-to-machine) y en 6.5 para el proveedor interactivo, donde alguien todavía debe aprobar el inicio de sesión. Las correcciones aparecen en las versiones 1.30.0 (rama 1.x) y 2.2.0 (rama 2.x) del SDK; los cambios fueron incluidos en notas de versión publicadas el 7 de septiembre y el aviso de seguridad se difundió el 28 de septiembre, el mismo día en que Cycode publicó su análisis.

Hechos confirmados: el SDK oficial de Python para MCP envió client secret, authorization code y el PKCE proof key a un endpoint controlado por un servidor MCP malicioso en versiones anteriores a 1.30.0/2.2.0; Cycode demostró el intercambio en laboratorio; la corrección está en 1.30.0 y 2.2.0; la advertencia sobre el comportamiento apareció primero como un cambio de comportamiento en las notas de versión; no había CVE asignado al 29 de septiembre; no se han reportado exploits en el terreno según el advisory y el informe de Cycode.

Qué implementaciones y roles resultan afectados: están en riesgo las aplicaciones que usan el SDK como MCP client sobre HTTP y que emplean uno de estos proveedores OAuth integrados: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider o el proveedor obsoleto RFC7523OAuthClientProvider de la serie 1.x. Para que exista la exposición, el cliente debe poder conectarse a un servidor MCP que no controle totalmente (por ejemplo, servidores de terceros). No están afectadas las MCP servers construidas con el SDK, los clientes locales (stdio) ni los clientes que adjunten sus propios tokens manualmente.

Consecuencias prácticas: con las credenciales robadas un atacante puede intercambiarlas por un token de acceso válido en el servicio de autenticación legítimo y actuar con los permisos concedidos a la aplicación. El client secret suele ser de larga duración, por lo que la exposición permanece efectiva hasta que se rote el secreto. En escenarios machine-to-machine esto puede permitir accesos automatizados sin necesidad de interacción humana; en el caso del flujo interactivo, la página de inicio de sesión aprobada por el usuario puede ser genuina y no mostrar señales visibles de manipulación, por lo que la víctima no percibe nada anómalo durante la autorización.

Pasos concretos e inmediatos que deben tomar los responsables: primero, actualizar el SDK a las versiones corregidas: 1.30.0 para la rama 1.x o 2.2.0 para la 2.x. Segundo, para usuarios de ClientCredentialsOAuthProvider o PrivateKeyJWTOAuthProvider, además de actualizar deben proporcionar explícitamente el parámetro issuer= que vincule esas credenciales al servicio de autorización al que pertenecen; sin ese parámetro las credenciales seguirán aceptando la dirección que les indique el servidor MCP. El proveedor obsoleto RFC7523OAuthClientProvider no admite issuer= y debe sustituirse por uno de los otros dos. Tercero, después de la actualización, eliminar una sola vez cualquier registro de cliente OAuth almacenado localmente por versiones antiguas, porque esos registros no estaban unidos a un issuer y permanecerían inseguros. Finalmente, si existe la posibilidad de que un cliente ya se haya conectado a un servidor no confiable, rotar inmediatamente el client secret y revocar tokens y autorizaciones en el servicio de identidad correspondiente.

Como medidas adicionales de mitigación temporal: evite conectar clientes MCP a servidores que no controle o no pueda auditar; habilite controles de red que limiten destinos de token endpoints a los servicios legítimos; registre y revise intercambios OAuth y excepciones de issuer en logs de auditoría para detectar actividad anómala. Consulte la documentación del proveedor de identidad para procedimientos de rotación y revocación de clientes y tokens.

Limitaciones y áreas de incertidumbre: no hay indicios públicos de que la vulnerabilidad haya sido explotada en entornos de producción hasta la fecha de los informes; sin embargo, la falta de reportes no garantiza que no exista abuso no detectado. Tampoco se había asignado un CVE al 29 de septiembre —esto podría cambiar si los mantenedores o terceros registran el fallo en la base de CVE más adelante. La evaluación de impacto en sistemas concretos dependerá de cómo cada organización gestione secretos, registros de cliente y control de servidores MCP externos.

Para entender mejor por qué esta vulnerabilidad es especialmente peligrosa conviene repasar el modelo OAuth: el RFC 6749 de OAuth 2.0 y los mecanismos PKCE están diseñados para que un código de autorización no sea reutilizable por un tercero. Si el cliente entrega voluntariamente la clave PKCE al atacante, esa barrera queda anulada. Para información técnica y recomendaciones sobre el manejo de advertencias en Python (por ejemplo, la deprecación que puede ocultarse por defecto en la 1.30.0), consulte la documentación oficial de advertencias de Python en docs.python.org. El informe técnico y la demostración de la compañía que reportó el problema está disponible en la web de Cycode: Cycode.

En resumen: si su aplicación usa el SDK oficial de MCP como cliente y confía en servidores MCP que no controla, actualice cuanto antes, configure el issuer cuando corresponda, revoque y rote credenciales si existe exposición potencial, y revise sus registros y políticas de conexión a servidores externos. Estas acciones concretas son las únicas que reducen el riesgo de que un servidor MCP malicioso convierta una interacción legítima en un compromiso de credenciales OAuth.