Cycode detecta un fallo de toma de cuentas en el SDK de Python de MCP

Este lunes 28 de septiembre, Security Boulevard informó de que Cycode, firma especializada en seguridad de aplicaciones, ha encontrado una vulnerabilidad de toma de control de cuentas (account takeover) en el SDK oficial de Python del Model Context Protocol, la librería que Anthropic mantiene para construir servidores y clientes MCP en ese lenguaje.

No hablamos de un servidor concreto publicado por un tercero, sino de la base sobre la que se levanta una parte importante de ellos. Esa diferencia es la que convierte la noticia en lectura obligada para cualquiera que tenga servidores MCP en producción.

Por qué un fallo en el SDK pesa más

El SDK de Python es la vía más habitual para escribir servidores MCP en Python. Desde que FastMCP se integró en el paquete oficial, montar un servidor con unas pocas funciones decoradas es cuestión de minutos, y eso ha multiplicado los proyectos que dependen de él, directamente o a través de otros frameworks de agentes.

Cuando la vulnerabilidad vive en el SDK, cada servidor construido sobre el componente afectado la hereda sin que su autor haya escrito una sola línea defectuosa. Y un account takeover, por definición, toca la capa de identidad: quién es el usuario al otro lado y qué credenciales maneja el servidor en su nombre. En MCP esa capa es especialmente delicada, porque la especificación del protocolo apoya la autorización de los servidores remotos en OAuth 2.1, y esos servidores suelen custodiar tokens con acceso a repositorios, CRMs, bases de datos o buzones de correo.

Para el detalle técnico del hallazgo conviene ir a la pieza original y cruzarla con los avisos de seguridad del repositorio oficial, que es donde se documentan las versiones afectadas y la corrección.

No es el primer aviso en el ecosistema

MCP cumplirá dos años en noviembre y la lista de hallazgos crece al ritmo de su adopción. Durante 2025, Oligo Security documentó una ejecución remota de código en MCP Inspector, la herramienta oficial de depuración, y JFrog hizo lo propio con mcp-remote, un proxy muy usado para conectar clientes locales con servidores remotos. El patrón se repite: piezas pensadas como infraestructura auxiliar que acaban expuestas en contextos para los que no se diseñaron.

La diferencia con este caso es el nivel. Aquí no se trata de una utilidad de desarrollo, sino del código sobre el que corren los propios servidores.

A quién afecta y qué revisar

A falta de conocer el alcance exacto en cada despliegue, el perfil más expuesto es el de los equipos que publican servidores MCP remotos por HTTP con autenticación de usuarios, sobre todo si son multiusuario. Un servidor local por stdio que solo usa una persona en su máquina tiene otro perfil de riesgo, aunque también debe actualizarse.

Esto es lo que haríamos hoy mismo:

1. Inventariar dónde aparece el paquete `mcp`. Revisar lockfiles (`uv.lock`, `poetry.lock`, `requirements.txt`) y dependencias transitivas, porque muchos frameworks lo arrastran sin que figure en el manifiesto principal.
2. Actualizar a la versión corregida que indique el aviso oficial y redesplegar. Cambiar el lockfile sin reiniciar el servicio no arregla nada.
3. Si el servidor estaba expuesto a internet, revocar y rotar los tokens OAuth y las credenciales de terceros que custodia.
4. Revisar los logs de autenticación en busca de sesiones o emisiones de tokens que no encajen con el uso normal.
5. En Claude Code, repasar con `claude mcp list` qué servidores hay configurados y retirar los que ya no se usan. Cada servidor olvidado es un punto más que parchear.

El precio de la sencillez

MCP ha cuajado porque conectar un modelo con una herramienta externa es fácil. Esa misma facilidad hace que muchos servidores lleguen a producción con la configuración por defecto del SDK y sin una revisión de seguridad propia. Cuando el fallo está en la librería común, el impacto se reparte entre todos a la vez, y la velocidad de respuesta depende de saber qué tienes desplegado.

En ElephantPink tratamos cada servidor MCP como una API pública más: dependencias fijadas, alertas de seguridad activas y tokens de vida corta. No evita que aparezcan fallos como este, pero convierte la respuesta en una tarde de trabajo en lugar de una semana.