El MCP Python SDK tiene un fallo que permite a un servidor malicioso desviar tus credenciales OAuth: actualiza a 1.30.0 o 2.2.0 y pasa después issuer=

Nuestro veredicto: si creas clientes MCP en Python con el MCP Python SDK oficial (no figura en nuestro directorio) y te conectas por HTTP a servidores que no controlas, actualiza hoy. En dos de los cuatro proveedores afectados, actualizar no cambia nada por sí solo: además tienes que pasar issuer=. Los mantenedores lo califican de gravedad alta, CVSS 7,5. No se ha informado de ningún ataque.

Qué ha pasado

El 28 de septiembre de 2026, los mantenedores del SDK publicaron el aviso GHSA-qx49-fqc8-xw99, titulado «OAuth client could send credentials to an authorization server chosen by the MCP server» (el cliente OAuth podía enviar credenciales a un servidor de autorización elegido por el servidor MCP). Según el aviso, el issuer de los metadatos del servidor de autorización no se validaba en todas las rutas de descubrimiento, y las credenciales de cliente almacenadas o preaprovisionadas no estaban vinculadas al servidor de autorización al que pertenecen. Por tanto, un servidor MCP malicioso podía dirigir las credenciales de un cliente hacia un endpoint bajo su control. The Hacker News detalla qué queda expuesto: el secreto de cliente, el código de autorización y la clave de prueba PKCE.

• Gravedad: CVSS 3.1 7,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) para los proveedores máquina a máquina, y 6,5 para el proveedor interactivo, que requiere la aprobación del usuario. No se ha asignado ningún CVE.
• Proveedores afectados: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider y el obsoleto RFC7523OAuthClientProvider de la rama 1.x.
• Versiones afectadas: mcp de la 1.9.1 a la 1.29.1, y de la 2.0.0 a la 2.1.1.
• Corregido en: mcp 1.30.0 y 2.2.0.
• No afectados: los servidores MCP creados con el SDK, los clientes stdio y los clientes que adjuntan sus propios tokens o cabeceras.
• Explotación: ni el aviso ni Cycode informan de ningún ataque, según The Hacker News.

Por qué importa

La corrección se publicó el 7 de septiembre de 2026, tres semanas antes del aviso, según The Hacker News. Es posible que una actualización rutinaria ya la haya incorporado, y eso genera una falsa sensación de seguridad: solo te protegía en el proveedor interactivo.

ClientCredentialsOAuthProvider y PrivateKeyJWTOAuthProvider son los proveedores máquina a máquina y guardan secretos de cliente y claves privadas de larga duración. En esos dos, el código parcheado vincula las credenciales solo si pasas un argumento issuer= que nombre el servidor de autorización al que pertenecen. Si lo omites, obtienes un aviso de obsolescencia y ninguna protección. Clientes desatendidos con secretos de larga duración, protegidos solo por un aviso que nadie lee: eso es lo que justifica un parche fuera de calendario.

Qué cambia para ti

1. Actualiza mcp a 1.30.0 (1.x) o 2.2.0 (2.x).
2. En ClientCredentialsOAuthProvider y PrivateKeyJWTOAuthProvider, pasa issuer= de forma explícita, por ejemplo issuer="https://auth.example.com". Será obligatorio en la 3.0.
3. Si usas RFC7523OAuthClientProvider, abandónalo: no tiene la opción issuer=.
4. Borra una vez los registros OAuth almacenados, para que los clientes se registren de nuevo con vinculación al issuer.
5. Si un cliente pudo llegar a un servidor MCP que no sea de confianza, rota sus secretos de cliente en el servidor de autorización y revoca sus tokens.

Ninguna herramienta de nuestro directorio es el propio SDK. Si ejecutas un agente o un gateway en Python que habla MCP por HTTP, comprueba qué versión del SDK tiene fijada.

Preguntas frecuentes

¿Me afecta si solo creo servidores MCP? No. El aviso indica que los servidores MCP creados con el SDK no están afectados, igual que los clientes stdio.

Ya actualicé en septiembre. ¿Estoy a salvo? Solo en el OAuthClientProvider interactivo. En los dos proveedores máquina a máquina sigues expuesto hasta que pases issuer=.

¿Hay un CVE que seguir? No. Sigue el caso como GHSA-qx49-fqc8-xw99.