Stream Vessel: OAuth por usuario contra el phishing

Un 95,8% de los servidores MCP con OAuth acepta cualquier dirección de retorno

Un estudio de mayo de 2026 que probó 119 servidores MCP con OAuth habilitado encontró endpoints de registro abiertos en 114 de ellos (95,8%), y que esos endpoints "aceptan valores arbitrarios de redirect_uri de solicitantes anónimos". Para un founder que conecta un agente propio a los datos de sus clientes, eso significa que la pantalla de aprobación puede estar autorizando que las llaves viajen a un destino que nadie validó.

Stream Vessel, el servicio que da a cada usuario su propio bucket de S3 con acceso de lectura, escritura y borrado a través de un servidor MCP, publicó el diseño con el que cerró ese agujero en su propio servidor: mantener la lista blanca del operador y sumar, encima, una lista de direcciones de confianza por usuario que se decide al iniciar sesión, no al registrarse.

Qué es un redirect URI y por qué decide quién entra

Un Model Context Protocol (MCP) es el estándar con el que una aplicación de IA o un agente se conecta a herramientas y datos externos. Cuando ese agente necesita permiso sobre tus archivos, usa el flujo OAuth estándar: se registra, abre el navegador, tú apruebas y recibe un token.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El punto débil está en el medio. Al registrarse, el agente declara su redirect URI: la dirección a la que el navegador vuelve tras tu aprobación, llevando un código de autorización de un solo uso que el agente canjea por un token. Si tu agente vive en https://agente.tuhost.com/callback y el servidor solo acepta direcciones de su lista blanca —Claude, ChatGPT, Cursor, VS Code y pocas más—, la respuesta es invalid_redirect_uri y el flujo muere en el primer paso.

Ese candado no es capricho: esa lista es la dirección a la que el correo entregará las llaves de tu casa. Sin ella, cualquiera registra un cliente falso llamado "Claude" y se lleva el código a su propio dominio. El servidor queda entre dos males: cerrado para ti o inseguro para todos.

Los dos fallos son comunes. Del lado cerrado, usuarios de Cursor reportaron en la comunidad de desarrolladores de Atlassian el error "The redirect URI is not allowed, the URL is not part of Atlassian whitelisted domains for registered MCP Clients". Del lado abierto está el 95,8% del estudio.

El ataque: un enlace, un clic, el bucket de otro

Con un servidor que acepta cualquier registro y cualquier dirección de retorno, un atacante sin cuenta puede tomar el acceso de un usuario en cuatro pasos:

Registra un cliente llamado "Claude" cuyo redirect URI apunta a https://evil.example/cb. El registro abierto es anónimo por diseño.
Envía al usuario conectado un enlace /oauth/authorize que parece normal: "Reconecta tu almacenamiento con Claude".
El usuario ve la pantalla de consentimiento real, en el dominio real, dentro de su sesión real, y aprueba.
El código aterriza en evil.example. El atacante lo canjea por un token y ahora es el usuario.

PKCE no ayuda: solo permite que el cliente que inició el flujo lo termine, y el atacante inició este. El nombre del cliente es autodeclarado y no prueba nada. La pantalla muestra el host de destino, pero claude-connect.app pasa el examen a simple vista.

No es hipotético. En enero de 2026, Obsidian Security reportó esta cadena contra el servidor MCP de Square: el autorregistro aceptaba cualquier dirección de retorno y un clic exponía el perfil de un comerciante, sus transacciones y sus datos bancarios. En palabras de los investigadores, "cualquier usuario que hubiera autorizado antes el servidor MCP de Square era vulnerable". El arreglo de Square, señalan, solo aplicó a clientes registrados después.

El mismo patrón apareció en un proxy MCP delante del inicio de sesión único de una empresa, con un token de acceso de 24 horas y uno de refresco de 14 días por clic. Y en abril de 2026 llegó el caso de n8n: su CVE-2026-42230 enviaba a los usuarios que denegaban el consentimiento directo a la dirección registrada por el atacante.

Hay un problema más silencioso. Cuando una petición falla una validación después de que su dirección fue aceptada, el error se envía a esa dirección. Un servidor que acepta cualquier dirección es, además, un redirector abierto en su propio dominio: un enlace de autorización manipulado rebota a los visitantes a cualquier sitio bajo tu nombre de host. RFC 9700 describe exactamente ese caso.

Qué dice el estándar y qué hacen los servidores

La especificación de MCP nombra el riesgo y deja la política a cada servidor. Sus consideraciones de seguridad dicen que los servidores de autorización DEBEN validar redirect URIs exactos, DEBERÍAN redirigir automáticamente solo a una URI en la que confíen, y PUEDEN informar al usuario y dejar que decida. Las dos últimas frases son de RFC 9700, palabra por palabra. Qué significa "confiar" queda abierto.

El registro también cambia. La página de registro de clientes del 28 de julio de 2026 deprecia el Dynamic Client Registration (un cliente que se registra solo por API, sin humano) en favor de los Client ID Metadata Documents (CIMD), donde el id del cliente es una URL HTTPS a un documento que lista sus redirect URIs. CIMD dice quién publica un cliente, no si este usuario quería conectarlo.

El grupo de trabajo de OAuth ya pasó por aquí. En un hilo de diciembre de 2025 en la lista de la IETF, Warren Parad sostuvo que el registro no autenticado convierte a un servidor de autorización MCP en un redirector abierto. La respuesta citada de Aaron Parecki apunta a RFC 9700 §4.11.2, que parte exactamente de ese escenario.

En la práctica los servidores se sientan en uno de dos polos:

Enfoque	Ejemplo	Quién puede conectarse	Exposición
Lista fija del operador	Servidor MCP de Postgres de pgEdge: el autorregistro está activo, pero la URI debe estar en su lista	Solo los clientes listados; cualquier otro exige cambiar la configuración	Baja
Lo que el cliente registró	114 de los 119 servidores del estudio de mayo de 2026	Cualquier cliente	Alta: el ataque de arriba

Loopback significa localhost o 127.0.0.1: una app en la máquina del propio usuario esperando que el navegador vuelva.

El primer polo también cuesta usuarios reales, y los clientes no lo van a arreglar por ti. Un issue de Claude Code de junio de 2026 reporta que las organizaciones con listas de coincidencia exacta no pueden iniciar sesión desde Claude Code, porque su host y ruta http://localhost:<puerto>/callback son fijos. Se cerró como "no planificado" en julio de 2026. El servidor tiene que moverse.

El diseño de Stream Vessel: confianza por usuario, decidida al iniciar sesión

Que el usuario avale la dirección de su propia app no es nuevo. GitHub hace que el desarrollador cree una app OAuth y escriba su callback. La opción de pre-registro de la especificación MCP describe una página donde el usuario registra un cliente a mano. Y una organización puede añadir dominios de confianza al servidor MCP de Atlassian. Ninguna encaja con un cliente que se registra solo y de forma anónima.

La jugada clave es cuándo corre la validación. El registro ocurre antes de que nadie inicie sesión, así que no puede saber qué lista consultar. Por eso el registro acepta cualquier URI HTTPS y la decisión espera a la página de autorización, donde el usuario ya se conoce.

Una regla sostiene todas las ramas: ningún código y ningún error se redirige a una dirección que no esté en la lista de todas las cuentas o en la de este usuario. Antes del inicio de sesión no aplica la lista de nadie, así que incluso los errores de validación de la propia librería OAuth esperan al login y un rechazo es una página en el host propio. Eso cierra el agujero de redirector abierto junto con el de phishing.

Siete reglas, cada una nacida de intentar romper la versión anterior:

Solo la sesión del navegador del usuario cambia la lista, nunca una app ni un token de API. Un token robado no puede ampliar a dónde van los códigos.
Añadir desde la página de rechazo exige escribir el host a mano. La página muestra el host, la dirección completa como texto plano (nunca como enlace), la cuenta a la que se uniría y una advertencia. "Confiar y continuar" queda deshabilitado hasta que escribas el host.
La pantalla de consentimiento nombra el redirect de este inicio de sesión y por qué está permitido: en la lista blanca, loopback, o "confiaste en esta dirección tú mismo". Un cliente puede registrar varias direcciones y poner claude.ai junto a la suya; la pantalla muestra solo la que aplica.
Cada adición se notifica por email y queda auditada. El correo abre con el host y evita que la dirección completa se convierta en enlace.
Quitar una dirección corta la app incluso a mitad del inicio de sesión: revoca cada permiso concedido por esa dirección y descarta los códigos aprobados pero no canjeados.
Se rechazan los hosts que el navegador y el servidor leen distinto. Un parser puede leer good.example%2eevil.example como un host literal mientras el navegador va a good.example.evil.example.
Coincidencia exacta: sin comodines, sin prefijos y sin flexibilidad de puertos tipo loopback.

Qué no detiene, y qué descartaron

No detiene a un ingeniero social decidido: un usuario convencido de escribir el host del atacante y aprobar queda phishado, elija el nivel que elija. El diseño lo acota en lugar de prevenirlo: el host tecleado, las advertencias, el email, la desconexión instantánea al quitar la dirección y una pantalla de consentimiento que arranca en solo lectura.

También descartaron opciones. El binding de dominio de CIMD (el host del redirect debe coincidir con el del client id) prueba quién publica el cliente, no que este usuario quisiera conectarlo. Un nivel de "cliente no verificado" con techo más bajo sigue estando a un clic de un enlace de phishing. Y el límite de acceso de escritura para direcciones confiadas por el usuario se eliminó: quienes conectan sus propios agentes querían acceso completo.

Qué significa esto para tu startup

Si tu producto expone un servidor MCP, o si construyes uno interno para tus agentes, la lección no es "añade una lista blanca" sino dónde la evalúas. Estas acciones puedes ejecutarlas esta semana:

Mueve la validación del registro a la autorización. Decide a dónde pueden ir los códigos cuando ya sabes qué usuario está firmando, no cuando un cliente anónimo se registra.
Valida también los errores. Antes de redirigir cualquier respuesta —incluidos los errores de PKCE o de scope—, comprueba la dirección contra tu regla y, si falla, responde con una página en tu propio host. Cloudflare publicó el CVE-2025-4143 en mayo de 2025 por validar solo en el canje del token.
Muestra el host del redirect en la pantalla de consentimiento y di por qué está permitido. El estudio de mayo de 2026 encontró que el 60,5% de los servidores probados no lo muestra, aunque la especificación lo exige para clientes con documento de metadatos.
Haz que ampliar la lista sea un acto deliberado, fuera del flujo de inicio de sesión o detrás de una confirmación escrita a mano.
Notifica por email cada dirección añadida y haz que quitarla revoque permisos y códigos en vuelo. Un código vive alrededor de un minuto; sin esto, uno en tránsito se convierte en permiso después de la remoción.

El contexto ayuda a dimensionar la urgencia. TechTimes reporta que el registro oficial de MCP superaba los 9.600 servidores en un conteo de mayo de 2026, y que un análisis de BlueRock Security sobre más de 7.000 servidores MCP escaneados encontró un 36,7% vulnerable a server-side request forgery y un 41% sin autenticación alguna. El informe State of AI Security 2026 de Cisco, citado por el mismo medio, señala que solo el 29% de las organizaciones se siente preparada para asegurar IA agéntica.

La superficie no deja de crecer. Ars Technica documentó que el investigador Syed Anas Mohiuddin encontró la misma clase de fallo en implementaciones de MCP de Google, JPMorgan Chase, Weaviate, Rapid7, la dirección digital interministerial del gobierno francés y el gobierno federal de Estados Unidos. En paralelo, investigadores de Microsoft describieron una campaña de phishing que abusa de la lógica de redirección de OAuth para llevar a usuarios de gobiernos y sector público desde páginas de login legítimas hasta infraestructura propia, según Help Net Security.

Conclusión

El redirect URI no es un detalle de configuración: es la frontera donde una aprobación deja de ser un gesto y se convierte en una garantía. Un servidor MCP que acepta cualquier dirección convierte tu pantalla de consentimiento en un decorado convincente.

La propuesta de Stream Vessel —lista del operador intacta, más una lista corta por usuario decidida al iniciar sesión— no elimina el phishing, pero lo acota a un acto deliberado y auditable. Si tu startup conecta agentes a datos de clientes, ese es el estándar mínimo que deberías exigirte antes de que alguien lo exija por ti.