Las herramientas de MCP necesitan autorización por acción

El 17 de mayo de 2026, NVD publicó CVE-2026-8719 para AI Engine 3.4.9, un plugin de WordPress que expone funciones de IA y MCP en sitios de WordPress.¹³

El modo de falla debería incomodar a cualquiera que construya con MCP. Wordfence describió la ausencia de una comprobación de capacidades de WordPress en la ruta de autorización OAuth con tokens bearer de MCP: cualquier token OAuth válido podía llegar a herramientas de MCP de nivel administrador sin verificar privilegios de administrador.² Wordfence calificó el problema con 8,8, severidad alta, y marcó la versión 3.5.0 como la versión corregida.² El registro de cambios del plugin dice que la versión 3.5.0 corrigió la autorización OAuth y la validación de tokens de MCP al exigir capacidad de administrador.³

La autorización de MCP falla cuando un servidor trata la posesión de un token bearer como permiso para usar todas las herramientas. OAuth puede demostrar que un token llegó mediante un flujo de autorización. Aun así, el servidor de MCP debe decidir si ese sujeto puede ejecutar esa herramienta, sobre ese recurso y con ese radio de impacto.

Resumen

La especificación de autorización HTTP de MCP les da a los equipos una base necesaria: metadatos de recursos protegidos, flujos OAuth 2.1, manejo de tokens bearer, validación de tokens, comprobaciones de audiencia y respuestas explícitas 403 Forbidden cuando faltan alcances o permisos.⁴ El tutorial de seguridad de MCP presenta la autorización como la capa que protege los recursos y operaciones sensibles expuestos por los servidores de MCP.⁵ Esa mecánica no elimina la decisión de autorización a nivel de aplicación. El servidor todavía tiene que mapear el token a un usuario, rol, inquilino, herramienta, recurso, acción y política.

CVE-2026-8719 convierte esa distinción en una falla concreta. AI Engine agregó OAuth 2.1 y Dynamic Client Registration para su servidor de MCP en la versión 3.4.9 el 12 de mayo, y luego corrigió la autorización OAuth y la validación de tokens de MCP en la versión 3.5.0 el 16 de mayo al exigir capacidad de administrador.³ La lección va más allá de WordPress: todo servidor de MCP que pueda modificar datos, publicar contenido, cambiar configuración, leer registros privados, gastar dinero o llamar APIs privilegiadas necesita autorización por acción, por debajo del modelo y por debajo del cliente.

La distribución de herramientas aumenta el riesgo. Un estudio de mayo de 2026 sobre clonación de herramientas midió 8.861 repositorios de MCP y Skills, con 100.011 entradas de herramientas, y encontró tasas altas de clones verificados en grupos de alta similitud.⁶ Las plantillas reutilizadas pueden propagar buenos patrones. También pueden propagar controles ausentes.

Puntos clave

Para quienes construyen servidores de MCP: - Valida los tokens y luego autoriza la acción concreta. Trátalos como controles separados. - Devuelve 401 para tokens inválidos o ausentes, y 403 para tokens válidos que no tienen alcance o permiso suficiente. - Prueba tokens de bajo privilegio contra cada herramienta de administración, escritura, publicación, eliminación, exportación y configuración.

Para equipos de seguridad: - Revisa los servidores de MCP como puntos de conexión de aplicación, no como plugins de chat. - Pregunta a qué usuario, rol, inquilino, recurso y acción corresponde cada llamada de herramienta. - Exige registros que muestren sujeto del token, nombre de la herramienta, recurso, veredicto de autorización y motivo de denegación.

Para equipos de plataformas de agentes: - Las cifras de mercados de herramientas no prueban implementaciones independientes. - Las comprobaciones de similitud y procedencia importan porque las herramientas clonadas pueden copiar lógica de autorización vulnerable. - Trata las plantillas de servidor como infraestructura sensible para la seguridad.

Para operadores: - Actualiza AI Engine a 3.5.0 o una versión posterior si ejecutas el plugin afectado de WordPress.²³ - Desactiva la exposición de MCP hasta saber qué roles de WordPress pueden acceder a qué herramientas. - Inicia toda conexión nueva de MCP en modo de solo lectura, y amplía la autoridad solo después de que las pruebas demuestren que las rutas de denegación funcionan.

Qué falló en AI Engine

AI Engine presenta MCP como una forma de conectar Claude Code, Claude, ChatGPT, OpenClaw y otros clientes a un sitio de WordPress mediante una URL, un flujo de inicio de sesión y un paso de aprobación.³ La versión 3.4.9 agregó OAuth 2.1 con Dynamic Client Registration para el servidor de MCP, de modo que los clientes controlados desde el navegador pudieran conectarse sin un token bearer compartido.³

Esa dirección de producto tiene sentido. Los tokens estáticos compartidos no encajan bien en integraciones de MCP orientadas al usuario. Los flujos OAuth pueden vincular un cliente, un usuario y un servidor con más limpieza que los secretos copiados y pegados.

El error estaba una capa más abajo. Según NVD y Wordfence, la ruta vulnerable aceptaba cualquier token OAuth válido para el acceso a MCP sin verificar privilegio de administrador antes de conceder acceso a herramientas de MCP de nivel administrador.¹² La diferencia importa:

La descripción del parche en la página del plugin de WordPress usa el lenguaje correcto: la autorización OAuth y la validación de tokens de MCP ahora exigen capacidad de administrador, lo que evita la escalada de privilegios por usuarios no administradores.³ Esa frase nombra la capa que faltaba. Un token no puede sustituir una comprobación de capacidad.

OAuth es necesario, pero no suficiente

La especificación de autorización de MCP cubre el flujo a nivel de transporte para transportes basados en HTTP. La especificación dice que los clientes de MCP hacen solicitudes a servidores restringidos de MCP en nombre de propietarios de recursos, y ancla el flujo en OAuth 2.1, metadatos de recursos protegidos, metadatos del servidor de autorización, Dynamic Client Registration y uso de tokens bearer.⁴

Esas piezas resuelven problemas reales:

La especificación de MCP también advierte sobre riesgos de confused deputy y de reenvío de tokens. Los servidores de MCP deben validar que los tokens presentados apunten al servidor de MCP, y no deben pasar a APIs ascendentes un token recibido del cliente de MCP.⁴ Esa guía protege el límite entre servicios.

La autorización por acción protege el límite dentro del servidor de MCP.

Un servidor de MCP puede exponer 10 herramientas o 100. Algunas leen metadatos públicos. Otras leen registros privados. Algunas preparan borradores. Otras modifican el estado de producción. Algunas administran usuarios, plugins, pagos, trabajos, mensajes o infraestructura. Un token válido no debería llegar automáticamente a todas las herramientas solo porque el servidor aceptó la sesión.

La cadena correcta se ve así:

1. Validar emisor, firma, vencimiento, audiencia y reglas de transporte del token.
2. Resolver el token a un sujeto local: usuario, cuenta de servicio, organización, inquilino o automatización.
3. Cargar el rol, los alcances, las concesiones, los presupuestos y la política de ese sujeto.
4. Clasificar la herramienta de MCP solicitada por tipo de acción y riesgo.
5. Comprobar el recurso objetivo, no solo el nombre de la herramienta.
6. Devolver 403 cuando el token es válido, pero la acción excede la autoridad.
7. Registrar la decisión con suficiente detalle para revisión.

OAuth lleva la solicitud al punto de decisión. La autorización decide si la acción corresponde.

Las llamadas de herramientas necesitan una matriz de permisos

Las herramientas de agentes vuelven más peligrosos los viejos hábitos de puntos de conexión. Una ruta web normal suele tener alrededor un recorrido de UI estrecho. Una herramienta orientada al modelo vive dentro de un planificador. El agente puede reintentar, encadenar llamadas, inspeccionar descripciones de herramientas, combinar resultados de lectura con acciones de escritura y llevar instrucciones de contenido no confiable a pasos posteriores.

Ese comportamiento cambia el modelo mínimo de permisos. Un servidor no debería preguntar solo “¿este usuario puede acceder a MCP?”. Debería preguntar “¿este usuario puede realizar esta acción mediante esta herramienta sobre este recurso en este momento?”.

Usa una matriz:

Esa matriz encaja con el patrón de las claves de agentes necesitan presupuestos de riesgo. Las credenciales no deberían comportarse como cadenas bearer de propósito general. Deberían comportarse como objetos de autoridad acotada, con límites del lado del servidor, registros de actividad, revocación y valores predeterminados conservadores.

También encaja con el marco de propiedad de la propiedad de agentes de IA es la base de la confianza. Toda llamada privilegiada de herramienta debería mapearse a una cuenta responsable, una sesión, un conjunto de autoridad, una ruta de revisión y una ruta de detención.

Las herramientas clonadas pueden copiar el mismo control ausente

El error de AI Engine importaría incluso si cada servidor de MCP proviniera de una implementación independiente y cuidadosa. El ecosistema de herramientas no se ve tan limpio.

Kim, Jiang, Hu, Jia y Gong publicaron el 10 de mayo de 2026 un estudio que mide la clonación de herramientas en ecosistemas de IA agéntica. Su conjunto de datos cubrió 7.508 repositorios de MCP con 87.564 herramientas extraídas y 1.353 repositorios de Skills con 12.447 herramientas, para un total de 8.861 repositorios y 100.011 entradas de herramientas.⁶ Los autores usaron similitud de Jaccard a nivel de tokens y similitud estructural difusa ssdeep, y luego verificaron manualmente pares muestreados en distintos grupos de similitud.⁶

El resumen reporta que el 60% de los candidatos con Jaccard alto y el 85% de los candidatos con ssdeep alto en el ecosistema de MCP fueron verificados manualmente como clones.⁶ El estudio sostiene que la duplicación oculta puede contaminar divisiones de pruebas comparativas, propagar implementaciones vulnerables, sesgar mediciones de generalización en uso de herramientas y plantear inquietudes de procedencia, atribución y licencias.⁶

Ese hallazgo cambia la forma en que los equipos deberían leer el crecimiento de los mercados de MCP. Más herramientas no significan automáticamente más revisión de seguridad independiente. Un andamiaje de servidor repetido puede darle consistencia al ecosistema. Esa misma repetición puede copiar el mismo patrón débil de autorización en muchos paquetes.

Por eso, la revisión de seguridad debe incluir procedencia:

Las Skills de agentes necesitan gestores de paquetes defendía una distribución estilo paquete, con procedencia y política alrededor de las Skills. Los servidores de MCP necesitan la misma disciplina, más pruebas de autorización en tiempo de ejecución.

La suite mínima de pruebas para la autorización de MCP

Todo servidor de MCP que toque datos privados o mutables debería incluir una suite de pruebas de autorización. Las pruebas unitarias que confirman el camino feliz no bastan. El comportamiento peligroso vive en las rutas de denegación.

Empieza con estos casos:

El código de estado exacto puede seguir la política del producto, pero la distinción debe mantenerse: las credenciales inválidas fallan antes de resolver el sujeto, y las credenciales válidas con autoridad insuficiente fallan en el control de autorización. La especificación de MCP nombra 401 para autorización ausente o inválida, y 403 para alcances inválidos o permisos insuficientes.⁴

Para WordPress en particular, la misma regla se vuelve más clara: las herramientas de MCP que realizan operaciones administrativas deberían comprobar las mismas capacidades de WordPress que comprobarían el panel, la API REST o la ruta interna de PHP. Un rol de menor privilegio no debería obtener una nueva vía hacia comportamiento de administrador solo porque la llamada llegó mediante un protocolo orientado al modelo.

Qué debería exigir la revisión de mercados

Los mercados de MCP y directorios de plugins deberían tratar los metadatos de autorización como datos de paquete de primera clase. Una persona que decide si habilita un servidor necesita más que un conteo de herramientas.

Metadatos públicos mínimos:

Esos campos no eliminarían las herramientas vulnerables. Harían real la superficie de revisión. Los operadores podrían comparar la autoridad declarada con el código real, y los mercados podrían agrupar implementaciones similares cuando aparece un defecto.

Ese es el puente que falta entre la especificación de autorización de MCP y el estudio de clonación de herramientas. La especificación les dice a los implementadores cómo hacer el flujo a nivel de protocolo. El ecosistema necesita procedencia a nivel de paquete y evidencia de autorización por acción para que las implementaciones repetidas no repitan los mismos controles ausentes.

Qué construir en su lugar

Construye la autorización de MCP como una canalización:

1. Control de protocolo: verifica metadatos de recursos protegidos, flujo OAuth, ubicación del token, validez del token, vencimiento, emisor y audiencia.
2. Control de sujeto: mapea el token a un usuario, cuenta de servicio, rol, inquilino y espacio de trabajo.
3. Control de herramienta: clasifica cada herramienta por lectura, borrador, escritura, eliminación, publicación, exportación, administración, ejecución o gasto.
4. Control de recurso: autoriza el objeto objetivo exacto o el límite de inquilino.
5. Control de presupuesto: aplica límites de frecuencia, tamaño, gasto, audiencia y tiempo antes de ejecutar.
6. Control de aprobación: exige aprobación humana o por política para acciones de alto riesgo.
7. Control de auditoría: registra veredictos de permitir, denegar y revisión requerida en un lugar que los operadores puedan inspeccionar.

Los controles deben vivir fuera del modelo. Una descripción de herramienta puede decirle al agente que evite acciones administrativas. Una instrucción puede pedir cautela. Ninguna de las dos debería cargar con el límite. El servidor debe rechazar la acción no autorizada incluso cuando el agente la pida con cortesía, confianza o insistencia.

Tu entorno aislado de agente es una sugerencia plantea lo mismo desde otro ángulo: permisos válidos aún pueden componerse en comportamientos inseguros. Las herramientas de MCP necesitan autorización en el límite de la acción porque el agente compondrá acciones más rápido de lo que una persona puede simular mentalmente.

FAQ

¿MCP requiere OAuth?

No. La autorización de MCP es opcional, y la especificación de autorización HTTP aplica cuando una implementación admite autorización sobre transportes basados en HTTP. La misma especificación dice que los transportes STDIO deberían obtener credenciales desde el entorno en lugar de seguir el flujo OAuth de HTTP.⁴

¿OAuth resuelve la autorización de MCP?

OAuth resuelve solo parte del problema. OAuth puede establecer un flujo de autorización, emitir tokens y permitir que un servidor protegido de MCP valide tokens bearer. El servidor de MCP todavía debe decidir si el sujeto del token puede realizar la acción específica de la herramienta contra el recurso objetivo.

¿Qué demostró CVE-2026-8719?

CVE-2026-8719 demostró que una ruta con token válido aún puede omitir la aplicación de capacidades locales. NVD y Wordfence describen AI Engine 3.4.9 como una versión que aceptaba cualquier token OAuth válido para el acceso a MCP sin verificar privilegio de administrador antes de que las herramientas de MCP de nivel administrador quedaran accesibles.¹²

¿Qué deberían probar primero quienes construyen con MCP?

Prueba primero las rutas de denegación: token de bajo privilegio contra herramienta de administrador, token de solo lectura contra herramienta de escritura, token válido contra recurso de otro inquilino, token vencido, token de audiencia incorrecta y herramienta destructiva sin aprobación. Que OAuth pase en el camino feliz no prueba autorización por acción.

¿Por qué la clonación de herramientas importa para la seguridad de MCP?

La clonación de herramientas importa porque las implementaciones repetidas pueden repetir el mismo middleware vulnerable, atajos de autenticación y controles ausentes. El estudio de mayo de 2026 sobre clonación de herramientas encontró tasas altas de clones verificados entre candidatos de MCP con alta similitud y advirtió que la duplicación oculta puede propagar implementaciones vulnerables.⁶

Referencias