CVE-2026-87759 expone cómo la ausencia de dos verificaciones básicas en Add User Autocomplete transforma a un suscriptor sin privilegios en administrador del sitio.
Una vulnerabilidad catalogada como de severidad alta por el National Vulnerability Database permite que cualquier usuario autenticado en una instalación multisitio de WordPress — incluso con el rol más bajo de suscriptor — se otorgue a sí mismo privilegios de administrador. El fallo, identificado como CVE-2026-87759, reside en el plugin Add User Autocomplete y afecta todas las versiones anteriores a la 1.2. La falla combina dos omisiones de seguridad elementales: el plugin no verifica las capacidades del usuario que ejecuta la acción ni valida tokens de protección contra falsificación de solicitudes (nonce) antes de crear invitaciones de membresía con roles definidos por el atacante.
Cómo dos controles ausentes abren la puerta a la escalada total de privilegios
El plugin Add User Autocomplete facilita la gestión de usuarios en instalaciones multisitio de WordPress, pero su implementación omite dos mecanismos de seguridad fundamentales en el flujo de creación de invitaciones de membresía. Primero, no realiza verificaciones de capacidad (capability checks) — el sistema de WordPress que determina qué acciones puede ejecutar cada rol de usuario. Segundo, no valida tokens nonce — cadenas únicas de un solo uso que WordPress genera para proteger formularios y solicitudes contra ataques de falsificación de solicitudes entre sitios.
La combinación de ambas omisiones permite que un atacante autenticado con cualquier nivel de privilegio — el caso más crítico es un suscriptor, el rol con menos permisos en WordPress — envíe una solicitud directa al endpoint del plugin que crea invitaciones de membresía. Como el plugin acepta el rol deseado como parámetro controlado por el usuario y no verifica si quien hace la solicitud tiene autorización para asignar ese rol, el atacante puede especificar «administrator» en la invitación y procesarla inmediatamente. El resultado es una escalada de privilegios instantánea sin necesidad de interacción de un administrador legítimo.
Por qué el alcance se limita a multisitio pero el impacto sigue siendo crítico
La vulnerabilidad aplica exclusivamente a instalaciones multisitio de WordPress — una configuración que permite gestionar múltiples sitios desde una única instalación del sistema. Esta arquitectura es común en organizaciones que administran redes de sitios relacionados: universidades con un sitio por facultad, medios con ediciones regionales, empresas con micrositios por producto. En América Latina, este modelo es frecuente en instituciones educativas públicas de México y Argentina, donde una sola instalación multisitio puede albergar decenas de sitios departamentales con administradores locales de confianza limitada.
Aunque la restricción a multisitio reduce la superficie de ataque comparada con una vulnerabilidad que afecte instalaciones estándar, el impacto en los entornos expuestos es total: un atacante con acceso de suscriptor — el nivel que típicamente se otorga a cualquier usuario registrado en un sitio público — obtiene control administrativo completo. Esto incluye la capacidad de instalar plugins maliciosos, modificar código de temas, acceder a datos de todos los usuarios del sitio y, en instalaciones multisitio, potencialmente pivotar hacia otros sitios de la red si comparten credenciales o tienen configuraciones débiles de aislamiento.
El patrón recurrente de plugins que confían en la interfaz para aplicar seguridad
La arquitectura de la vulnerabilidad refleja un error de diseño común en el ecosistema de plugins de WordPress: implementar controles de seguridad únicamente en la capa de interfaz de usuario mientras se deja el backend sin validaciones. El plugin probablemente oculta la opción de crear invitaciones con roles elevados en su interfaz gráfica cuando el usuario no tiene privilegios suficientes, pero no replica esa lógica de autorización en el código que procesa las solicitudes HTTP directas. Un atacante que inspeccione el tráfico de red o el código fuente del plugin puede identificar el endpoint vulnerable y construir una solicitud POST manual que bypasea por completo la interfaz.
Este patrón se repite en vulnerabilidades documentadas de otros plugins de WordPress donde la ausencia de capability checks en funciones AJAX o REST API permite que usuarios no autorizados ejecuten acciones privilegiadas. La omisión del nonce check agrava el problema al eliminar la última barrera que podría detectar solicitudes construidas fuera del flujo legítimo del plugin. WordPress proporciona funciones nativas para ambas validaciones — current_user_can() para capacidades y wp_verify_nonce() para tokens — pero su uso no es obligatorio a nivel de plataforma, lo que deja la responsabilidad de implementarlas correctamente en manos de cada desarrollador de plugin.
Nuestro análisis
CVE-2026-87759 ejemplifica cómo la ausencia de controles de seguridad básicos en componentes de terceros puede anular por completo el modelo de permisos de una plataforma. La severidad alta asignada por NVD es coherente con el impacto: escalada de privilegios completa con complejidad de ataque baja y sin necesidad de interacción del usuario. Lo que distingue este caso es la simplicidad de la explotación — no requiere técnicas avanzadas ni condiciones de carrera, solo conocimiento de cómo enviar una solicitud HTTP con parámetros controlados.
La corrección en la versión 1.2 del plugin presumiblemente incorpora las validaciones omitidas, pero el caso deja expuesta una pregunta estructural sobre el ecosistema de WordPress: ¿cuántos de los más de 60.000 plugins activos en el repositorio oficial implementan validaciones de seguridad solo en la interfaz, asumiendo que nadie intentará acceder directamente a sus endpoints internos? La respuesta determina cuántas vulnerabilidades similares están esperando ser descubiertas en instalaciones que confían en que «si no veo el botón en la interfaz, la acción no es posible».