La vulnerabilidad OAuth en MCP que roba cuentas con un click

En pocas palabras: Stream Vessel resolvió el dilema dejando que cada usuario autorice hasta 10 redirect URIs propios para su cuenta, validados recién en /authorize una vez logueado, no durante el registro anónimo del cliente MCP, que sigue aceptando cualquier dirección.

Stream Vessel publicó el 4 de noviembre de 2026 un esquema que deja que cada usuario de un servidor MCP autorice hasta 10 direcciones de redirect propias, después de que un estudio de mayo de 2026, citado por Stream Vessel, encontrara que 114 de 119 servidores OAuth-MCP probados (95,8%) aceptaban cualquier redirect_uri sin validarlo, un agujero que ya sirvió para tomar cuentas con un solo click.

El Model Context Protocol (MCP) es un estándar abierto, impulsado por Anthropic, que conecta agentes de inteligencia artificial con servicios externos (Slack, un bucket de S3, GitHub) a través de servidores que exponen “herramientas” y usan OAuth 2.1 para autenticar. Una vulnerabilidad OAuth en MCP aparece cuando ese servidor acepta cualquier redirect_uri en el registro dinámico de clientes: ahí un atacante puede interceptar el código de autorización y quedarse con la cuenta de otro usuario sin que la víctima note nada raro.

¿Cómo funciona el ataque que roba tokens registrando un redirect_uri falso en MCP?

El ataque funciona en cuatro pasos: el atacante registra un cliente anónimo llamado “Claude” con un redirect_uri propio, le manda a la víctima un link de autorización con apariencia legítima, la víctima aprueba en la pantalla real del servidor, y el código de autorización termina en el servidor del atacante en vez de en el cliente auténtico.

Ponele que un servidor MCP deja que cualquiera se registre sin autenticarse (eso es Dynamic Client Registration, DCR, abierto). El atacante no necesita cuenta en ese servidor: solo se registra como cliente, declara que su redirect_uri es https://evil.example/cb y le pone de nombre “Claude” (nada le impide ponerle el nombre que quiera, porque es autodeclarado y no prueba nada). Después manda un link del tipo “Reconectá tu storage a Claude” apuntando al endpoint /oauth/authorize del servidor real. Para más detalles técnicos, mirá las diferencias entre API y MCP.

La víctima ve la pantalla de consentimiento verdadera, en el dominio verdadero, dentro de su propia sesión, y aprieta Aprobar. El código de autorización, que dura en general alrededor de un minuto, viaja al redirect_uri que declaró el atacante en el paso uno. Con ese código, el atacante lo cambia por un token y pasa a operar como si fuera la víctima.

¿Y PKCE no se supone que evita esto? No en este caso. PKCE protege al cliente que arrancó el flujo de autorización, y acá quien arranca el flujo es el atacante, no la víctima. El nombre visible del cliente tampoco ayuda: es un campo que declara el que se registra, y la pantalla de consentimiento puede mostrar un host parecido al real (claude-connect.app pasa de largo en una mirada rápida) sin que haya ninguna verificación detrás.

¿Por qué un whitelist fijo de redirect URIs no alcanza para proteger a todos los usuarios?

Un whitelist fijo, controlado por el operador del servidor, baja mucho el riesgo de phishing pero deja afuera a cualquier cliente que no esté en esa lista, y agregar uno nuevo depende de que alguien edite un archivo de configuración a mano. La otra punta, dejar el registro abierto a cualquier redirect_uri, resuelve el problema de acceso pero abre la puerta descripta arriba.

Los dos extremos generan fricción real. En la comunidad de desarrolladores de Atlassian hay reportes, incluido uno de Cursor, con el error “The redirect URI is not allowed, the URL is not part of Atlassian whitelisted domains for registered MCP Clients”. El servidor MCP de GitHub exige que cada aplicación tenga su propia GitHub App u OAuth App registrada; si no, el usuario cae a un token de acceso personal, que es más trabajo manual y menos granular.

Los clientes tampoco van a arreglar esto por su cuenta. Un issue de Claude Code de junio de 2026 reporta que organizaciones con whitelist de coincidencia exacta no pueden iniciar sesión desde Claude Code porque su host y puerto de callback (http://localhost:<puerto>/callback) son fijos. Anthropic lo cerró como “not planned” en julio de 2026. La pelota queda del lado del servidor. Esto se conecta con lo que analizamos en los CVEs recientes en servidores MCP.

Enfoque	Ejemplo	Quién puede conectarse	Riesgo de phishing
Whitelist fijo del operador	pgEdge Postgres MCP server: self-registration habilitado, pero el redirect_uri tiene que estar en la lista (callback de Claude y dos URIs loopback por defecto)	Solo clientes listados; cualquier otro necesita un cambio de configuración	Bajo
Registro abierto, cualquier redirect_uri	114 de 119 servidores probados en el estudio de mayo de 2026 citado por Stream Vessel	Cualquier cliente, sin restricción	Alto: habilita el ataque de un click descripto arriba

¿Qué casos reales de este ataque se reportaron en 2026?

El caso más documentado de 2026 es el del servidor MCP de Square, reportado por Obsidian Security en enero de ese año: el self-registration aceptaba cualquier dirección de redirect, y un solo click exponía perfil, transacciones y datos bancarios del comerciante. Los investigadores escribieron que “cualquier usuario que había autorizado previamente el servidor MCP de Square estaba vulnerable”, y marcaron algo importante: el arreglo de Square solo cubrió a los clientes registrados después del fix, no a los anteriores.

Hubo más. Otros investigadores documentaron la misma cadena contra un proxy MCP ubicado frente al single sign-on de una empresa, donde cada click valía un token de acceso de 24 horas y un refresh token de 14 días. En varios programas de bug bounty, al principio, algunos equipos de seguridad lo descartaron como “ingeniería social” (comillas necesarias: la víctima nunca sale del dominio de confianza, no hay página falsa ni formulario de login clonado, lo cual es justamente lo que hace que el argumento de “social engineering” no cierre).

Un detalle que pasa desapercibido: n8n sufrió el CVE-2026-42230 en abril de 2026, donde el flujo redirigía al atacante incluso cuando el usuario apretaba “Rechazar” en la pantalla de consentimiento. Es decir, rechazar tampoco te salvaba.

¿Cómo resuelve Stream Vessel el problema dejando que cada usuario confíe en sus propios clientes?

Stream Vessel mantiene el whitelist del operador y el loopback para clientes locales sin cambios, y agrega una capa nueva: cada usuario puede marcar como confiables hasta 10 direcciones https exactas, propias, desde la página MCP de su cuenta. La validación no corre en el registro, sino en /authorize, momento en que el usuario ya está identificado y el servidor sabe a qué lista consultar.

Ese orden es la clave de todo el diseño: registrar antes de saber quién firma no tiene sentido si la decisión de confianza depende de la cuenta, así que el registro queda abierto a cualquier URI https, pero ningún código (y ningún error) se redirige a una dirección que no esté en la lista del operador o en la lista propia del usuario. Eso cierra también el hueco del open redirect, porque hasta los errores de validación de OAuth (un PKCE mal armado, un scope desconocido) esperan al login antes de mandar nada a cualquier lado. En cómo gestionar incidentes en entornos MCP profundizamos sobre esto.

Las siete salvaguardas que agregaron, según el posteo técnico de Alexander Loginov, son:

• Solo la sesión del navegador del usuario cambia la lista. Un token robado de una app o una API no alcanza para agregar direcciones nuevas.
• Agregar una dirección exige tipear el host a mano. El botón “Confiar y continuar” queda deshabilitado hasta que el usuario escribe el host completo, así que un click desde un mail de phishing no alcanza.
• La pantalla de consentimiento muestra el redirect de esa sesión y por qué está permitido (en la lista del operador, loopback, o “confiaste en esta dirección el 3 de noviembre de 2026”).
• Cada alta manda un email con el host en texto plano, nunca como link clickeable, la cuenta y la fecha. Es el aviso que una víctima de phishing normalmente nunca recibe.
• Sacar una dirección de la lista corta el acceso al instante, incluso a mitad de un login en curso, y revoca cualquier grant ya aprobado por esa vía.
• Los hosts con lecturas ambiguas quedan afuera. Direcciones como good.example%2eevil.example, que el navegador y el parser del servidor pueden leer distinto, se rechazan directamente en el registro.
• El match es exacto. Sin wildcards, sin coincidencia de prefijo, sin flexibilidad de puerto para direcciones que no sean loopback.

Ojo con algo: esto no frena a un ingeniero social con tiempo y paciencia. Si convencés a alguien de tipear el host del atacante a mano y aprobarlo, el usuario queda igual de expuesto. Stream Vessel no dice haber resuelto el phishing dirigido; dice haber acotado la ventana para el click automático, que es un problema distinto y mucho más común.

¿Qué checklist debe seguir un desarrollador para asegurar su propio servidor MCP?

Si estás armando o manteniendo un servidor MCP propio, la vulnerabilidad OAuth en MCP que vimos hasta acá se evita con cuatro decisiones de diseño, no con un parche aislado.

• Decidí a dónde pueden ir los códigos en /authorize, no en el registro. El registro pasa antes de que el usuario inicie sesión, así que ahí no hay forma de saber qué lista consultar.
• Validá toda respuesta contra esa regla, errores incluidos, antes de redirigir cualquier cosa. Hacelo en authorize, no solo en el intercambio final del token: el workers-oauth-provider de Cloudflare sufrió el CVE-2025-4143 en mayo de 2025 justamente por validar solo en esa última etapa.
• Mostrá el host del redirect de esta sesión puntual en la pantalla de consentimiento y explicá por qué está permitido (whitelist, loopback, o confianza agregada por el propio usuario).
• Hacé que ampliar la lista de confianza sea un acto deliberado, fuera del flujo normal de login, con una confirmación explícita.

Si tu servidor MCP corre sobre tu propia infraestructura (un VPS, un bucket, lo que sea), elegir dónde alojarlo también importa: para cargas de este tipo conviene un proveedor con buen soporte técnico en español, como donweb.com, antes que ahorrar unos pesos en un hosting genérico sin acompañamiento.

Errores comunes al configurar OAuth en servidores MCP

• Dejar el registro dinámico (DCR) totalmente abierto porque “así lo usa todo el mundo”. Según Obsidian Security, de 660 endpoints de Authorization Server analizados, solo 27 (4%) soportaban DCR de forma nativa; la mayoría de los problemas aparecen justo donde alguien activó DCR sin pensar en validación.
• Mostrar un consentimiento genérico que dice “MCP Server quiere acceso” sin nombre ni host real. Eso hace imposible que el usuario distinga un cliente legítimo de uno falso con nombre copiado.
• Confiar en que PKCE alcanza para todo. PKCE evita que un tercero complete un flujo que no inició, pero no evita que el atacante inicie su propio flujo y haga que la víctima lo complete por error.
• Arreglar el bug solo para clientes nuevos y dejar expuestos a los que ya autorizaron antes. Fue exactamente lo que pasó con el fix de Square, según Obsidian Security.

Preguntas Frecuentes

¿Qué es un ataque de redirect URI en OAuth?

Es un ataque donde alguien registra un cliente OAuth con una dirección de redirect propia y consigue que una víctima apruebe un flujo de autorización legítimo, de modo que el código de autorización termina en manos del atacante en lugar del cliente real. Funciona porque el servidor no valida contra quién realmente debería recibir ese código, solo contra lo que el cliente declaró al registrarse.

¿Cómo protege Stream Vessel a los usuarios de MCP contra el phishing?

Stream Vessel deja que cada usuario agregue hasta 10 redirect URIs propias de confianza desde su sesión web, y valida esa lista recién en /authorize, cuando el usuario ya está logueado, no en el registro anónimo. Cada alta requiere tipear el host a mano, manda un email de aviso y se puede revocar al instante, cortando cualquier grant en curso. Sobre eso hablamos en un esquema de autenticación centralizada con OAuth.

¿Por qué los servidores MCP no deberían aceptar cualquier redirect_uri?

Porque un servidor que acepta cualquier redirect_uri en el registro permite que un atacante sin cuenta propia registre un cliente falso y robe el código de autorización de otro usuario con un solo click. Un estudio de mayo de 2026 encontró esta falla en 114 de 119 servidores OAuth-MCP probados.

¿Qué pasó con el servidor MCP de Square en 2026?

Obsidian Security reportó en enero de 2026 que el servidor MCP de Square aceptaba cualquier dirección de redirect en el self-registration, lo que exponía el perfil, las transacciones y los datos bancarios de cualquier merchant que hubiera autorizado el servidor antes. Square arregló el registro para clientes nuevos, pero los usuarios que ya habían dado permiso siguieron expuestos.

¿Cómo configurar un servidor MCP seguro con OAuth?

Un servidor MCP seguro valida el redirect_uri en el momento de autorizar, no en el registro, muestra el host real del cliente en la pantalla de consentimiento y nunca redirige errores a direcciones no verificadas. Si necesitás registro dinámico abierto, combinalo con una lista de confianza por usuario, como hizo Stream Vessel, en vez de dejar el registro totalmente libre.

Conclusión

La vulnerabilidad OAuth en MCP que expusieron SickSec en enero de 2026 y Obsidian Security con el caso Square no es un bug aislado de un fabricante: es una consecuencia directa de cómo la mayoría de los servidores implementó el registro dinámico de clientes sin pensar en quién firma el consentimiento. El esquema de Stream Vessel, publicado el 4 de noviembre de 2026, no inventa una solución mágica, pero sí mueve la validación al momento correcto: cuando el usuario ya está identificado, no cuando un desconocido se registra.

Si mantenés un servidor MCP propio, la tarea concreta es chica: revisá si tu endpoint de registro acepta cualquier redirect_uri, y si la respuesta es sí, movés la validación a /authorize antes de que alguien la mueva por vos con un reporte de bug bounty.

Fuentes

• Stream Vessel – Letting users trust their own MCP clients, without opening a phishing hole
• Obsidian Security – When MCP Meets OAuth: Common Pitfalls Leading to One-Click Account Takeover
• Model Context Protocol – Security Considerations de la especificación de autorización
• SickSec – ATO via Open MCP DCR