Servidores MCP remotos: 40 % sin autenticación, OAuth roto en el resto

What is this?

Un artículo de arXiv de mayo de 2026, A First Measurement Study on Authentication Security in Real-World Remote MCP Servers (cs.CR, 2605.22333), es el primer análisis a gran escala de la capa de autenticación de los servidores Model Context Protocol remotos: los programas accesibles por red que exponen herramientas (consultas a bases de datos, llamadas a API, acceso a ficheros) a los agentes LLM. La mayoría de la investigación previa se centraba en la inyección de prompts y el tool poisoning; este trabajo aborda la cuestión de capa de protocolo: quién tiene permiso para conectarse.

La medición principal es contundente. De 7973 servidores MCP remotos validados y activos, 3233 (40,55 %) exponen su interfaz de herramientas sin autenticación alguna: cualquier cliente puede invocar herramientas o lanzar llamadas a API sin presentar una credencial. En el resto, OAuth es el mecanismo dominante (2428 servidores), y cuando los autores probaron manualmente un subconjunto totalmente reproducible de 119 servidores OAuth, todos presentaban al menos un fallo de autenticación — 325 fallos en total. Nueve fueron lo bastante graves para recibir un identificador CVE tras divulgación responsable (la serie CVE-2026-26384 a CVE-2026-26390). Esto complementa el escaneo de calidad de código VIPER-MCP y los recuentos de exposición más amplios: estos servidores no solo son vulnerables y están sobreexpuestos, sino que su puerta de entrada suele estar abierta.

How it works

La especificación MCP hizo obligatorio OAuth 2.1 con PKCE para los transportes HTTP en su revisión del 26 de marzo de 2025, y la versión del 25 de noviembre de 2025 priorizó los Client ID Metadata Documents manteniendo el Dynamic Client Registration (DCR) como respaldo de compatibilidad. En la práctica, los servidores remotos dependen del DCR porque deben aceptar clientes heterogéneos —IDE, CLI, aplicaciones de escritorio, agentes en la nube— imposibles de preregistrar a mano. El artículo destila tres rasgos recurrentes de estos despliegues y construye en torno a ellos una taxonomía de nueve tipos de fallos en cuatro categorías. Descrita al nivel del mecanismo, no del payload:

Category                          Representative flaw            Effect
--------------------------------  ----------------------------  ---------------------------
C1 Dynamic Client Registration    Malicious DCR binding         Anonymous registrant submits
   (96.6% of tested servers)      (F1, 95.8%)                   an attacker redirect_uri and
                                                                gets a valid client_id back.
C3 Open Client Environment        PKCE downgrade (F5, 68.1%)    Server accepts a missing or
   (85.7% of tested servers)                                    "plain" code_challenge,
                                                                nullifying PKCE binding.
C2 Delegated Authorization        Layer inconsistency (F3)      PKCE enforced on the first
   (15.1% of tested servers)      Nested context pollution (F4) hop but dropped on the
                                                                upstream hop; unvalidated
                                                                redirect_uri inside `state`.
C4 Common OAuth misconfig         Standard OAuth hygiene gaps   Reuse/replay of codes, weak
                                                                state/CSRF handling.

El fallo dominante es el más simple: un endpoint DCR que acepta cualquier redirect_uri de un registrante no autenticado. El atacante registra un cliente que apunta a un servidor bajo su control, construye una URL de autorización con ese callback y, mediante ingeniería social, induce a una víctima a completar el flujo de consentimiento. El código de autorización se entrega entonces al atacante, que lo canjea por un token de acceso y toma el control de la sesión MCP de la víctima —y, a través de la autorización delegada, de las cuentas de servicio anteriores—. Cuando un servidor además permite omitir PKCE, robar el código basta por sí solo. No se requiere ningún cliente MCP malicioso; el atacante solo necesita enviar peticiones HTTP a endpoints públicos y alojar una página. Aquí no se reproduce ningún exploit funcional: la referencia es el artículo y las CVE asignadas.

Why it matters

El MCP remoto se está convirtiendo en el tejido conector entre los agentes y los sistemas reales, lo que hace que su capa de autenticación sea estructural. Dos hallazgos deberían cambiar cómo lo tratan los equipos. Primero, el 40 % sin autenticación es una exposición directamente explotable, no teórica: esos servidores entregan la ejecución de herramientas a cualquiera que pueda alcanzarlos y, según el resumen de Adversa de junio de 2026, Censys contabilizó 12 520 de estos servicios en la Internet pública. Segundo, que exista autenticación no significa que sea correcta: todos los servidores OAuth que los autores pudieron probar estaban defectuosos, y el fallo más frecuente (vinculación DCR abierta) conduce directamente al robo de cuenta. Como el servidor MCP a menudo actúa a la vez como servidor de recursos OAuth y como cliente OAuth frente a los servicios anteriores, un solo salto roto se convierte en un problema de «confused deputy» que abarca plataformas operadas de forma independiente.

Defenses

Las correcciones son higiene OAuth estándar que el código de los servidores MCP suele omitir.

1. Blinde el Dynamic Client Registration. No acepte redirect_uri arbitrarios de registrantes anónimos. Ponga en lista blanca los callbacks exactos, exija autenticación en el endpoint de registro y prefiera los Client ID Metadata Documents (mecanismo preferido por la especificación del 25 de noviembre de 2025) frente al DCR abierto.

2. Imponga PKCE, rechace los downgrades. Exija S256; rechace las peticiones que omitan code_challenge o usen el método plain. PKCE es la vinculación principal en entornos de cliente abierto donde no se puede proteger ningún client_secret.

3. Valide las URI de redirección por coincidencia exacta y vincule el flujo. Mantenga los códigos de autorización de un solo uso y corta duración, vinculados al mismo cliente y verificador PKCE; preserve state contra el CSRF; proteja la integridad de cualquier URI incrustada en state.

4. Mantenga PKCE coherente en los saltos delegados. Si el primer salto impone PKCE, la petición anterior también debe hacerlo: la incoherencia de capa anula la garantía de forma silenciosa.

5. Autentique cada servidor remoto y retire de la red el resto. La acción de mayor impacto: poner autenticación delante de cada servidor MCP remoto y sacar de la Internet pública los no autenticados. Combínelo con la admisión atestiguada de servidores de herramientas y las consideraciones de diseño de seguridad de MCP de la NSA como base.

Status

Elemento	Referencia	Fecha	Notas
Estudio de medición	arXiv:2605.22333 (cs.CR)	2026-05	Primer estudio de autenticación de servidores MCP remotos
Exposición	Artículo	2026-05	7973 servidores activos; 3233 (40,55 %) sin autenticación
Fallos OAuth	Artículo	2026-05	119 servidores probables, todos defectuosos; 325 fallos en total
Fallo dominante	Artículo	2026-05	Vinculación DCR abierta en el 95,8 % → robo del código de autorización
Divulgación	Artículo	2026-05	Divulgación responsable; 9 CVE asignadas (CVE-2026-26384–26390)
Contexto del ecosistema	Resumen Adversa / Censys	2026-06-04	12 520 servicios MCP expuestos en Internet

El enfoque correcto no es «OAuth está roto», sino que los servidores MCP remotos reimplementan OAuth bajo la presión del despliegue y se equivocan en las partes difíciles, mientras que una parte importante omite la autenticación por completo. Trate su capa de autenticación MCP como cualquier otra superficie OAuth pública: blinde el registro, imponga PKCE y ponga una credencial delante de todo lo que pueda ejecutar una herramienta.