Una vulnerabilidad crítica en el complemento OAuth Single Sign On – SSO (OAuth Client) de miniOrange puede permitir que un atacante sin cuenta previa suplante a cualquier usuario de una instalación WordPress, incluido un administrador. El fallo ha recibido el identificador CVE-2026-57807 y una puntuación CVSS de 9,8 sobre 10.
El problema afecta a las versiones identificadas por Patchstack como 38.5.8 y anteriores. La compañía de seguridad no había registrado todavía una actualización oficial que corrigiera el fallo cuando publicó su aviso, por lo que recomienda aplicar medidas de contención de inmediato. La vulnerabilidad fue comunicada por el investigador Kim Dvash el 06/06/2026 y se hizo pública el 09/07/2026.
La National Vulnerability Database describe el error como una omisión de autenticación a través de una ruta o canal alternativo, clasificada bajo CWE-288. La entrada señala que puede explotarse mediante el mecanismo de recuperación de contraseña y confirma que no requiere privilegios, interacción del usuario ni condiciones complejas. La puntuación de 9,8 procede de Patchstack como autoridad que asignó el CVE; NIST todavía no había realizado su propia evaluación.
Los complementos de inicio de sesión único añaden nuevas rutas de autenticación al funcionamiento habitual de WordPress. En lugar de utilizar únicamente el formulario de usuario y contraseña, permiten acceder mediante proveedores como Microsoft Entra ID, Google Workspace, Keycloak, Okta, Auth0 o servicios que empleen OAuth y OpenID Connect.
Este modelo simplifica la gestión de identidades, pero también introduce más puntos en los que el complemento debe comprobar quién está realizando una petición, qué usuario pretende utilizar y si el proceso de autenticación ha terminado correctamente.
CVE-2026-57807 se encuentra en una vía alternativa vinculada con la recuperación de acceso. Según la clasificación publicada, el complemento procesa una ruta que no aplica los mismos controles exigidos en el flujo normal. Un atacante remoto puede aprovechar esa diferencia para conseguir una sesión válida asociada a otro usuario.
Si el usuario suplantado tiene permisos de administrador, el incidente deja de limitarse al robo de una cuenta. Desde el panel de WordPress sería posible instalar complementos, cambiar archivos del tema, crear nuevos administradores, modificar el contenido, acceder a información almacenada y mantener una puerta trasera después de que se cierre la sesión inicial.
El alcance puede extenderse al alojamiento cuando WordPress tiene permisos de escritura amplios o comparte credenciales, archivos y recursos con otras webs. Un administrador comprometido puede instalar código PHP y utilizar la aplicación como punto de entrada para acceder a bases de datos, secretos almacenados en la configuración o servicios conectados.
Un sistema de doble factor tampoco debe considerarse automáticamente una defensa suficiente. Si el segundo factor protege únicamente el formulario habitual, pero el atacante entra por una ruta alternativa que genera o acepta la sesión sin pasar por ese flujo, la comprobación adicional podría no llegar a ejecutarse. El efecto exacto dependerá de la integración utilizada en cada instalación.
| Elemento comprometido | Posible consecuencia |
|---|---|
| Cuenta de administrador | Control del panel y de la configuración |
| Complementos y temas | Instalación de código malicioso |
| Usuarios registrados | Acceso a información personal o interna |
| Base de datos | Lectura, modificación o extracción de registros |
| OAuth y OpenID Connect | Exposición potencial de configuraciones y secretos |
| Archivos de WordPress | Inserción de puertas traseras y redirecciones |
| Visitantes | Distribución de malware, fraude o phishing |
| Alojamiento compartido | Movimiento hacia otras aplicaciones del servidor |
Patchstack considera la vulnerabilidad de alta prioridad y advierte de que los fallos de este tipo pueden incorporarse a campañas automatizadas. Esa valoración no significa que exista constancia pública de explotación activa. La entrada de CISA disponible en la NVD marcaba el estado de explotación como “ninguna” el 13/07/2026, aunque señalaba que el ataque sería automatizable y tendría un impacto técnico total.
La información difundida inicialmente presenta una dificultad importante: la numeración de versiones no coincide con la edición disponible en el directorio público de WordPress.
La ficha oficial de WordPress.org muestra la versión 6.26.20 de OAuth Single Sign On – SSO (OAuth Client), con más de 6.000 instalaciones activas. Sin embargo, el aviso de Patchstack identifica como afectadas las versiones 38.5.8 y anteriores.
El historial de Patchstack contiene además una vulnerabilidad anterior de la edición Premium con numeración 38.4.9, lo que apunta a que la rama 38.x corresponde a una variante comercial distribuida fuera del repositorio público. El aviso actual no aclara expresamente esta diferencia ni publica una cifra de instalaciones.
Por eso no resulta correcto afirmar que el fallo expone a “millones de webs”. La versión gratuita registra más de 6.000 instalaciones en WordPress.org, mientras que el número de clientes de la edición comercial no se ha publicado. Tampoco debe asumirse que una instalación con versión 6.x es vulnerable o segura únicamente por su numeración.
Los administradores deben comprobar el nombre exacto del paquete instalado, su edición, el origen desde el que se descargó y la versión que aparece en la administración o en los archivos del complemento. En despliegues gestionados puede haber variantes empresariales que no reciben actualizaciones desde WordPress.org y utilizan canales privados de miniOrange.
La diferencia también afecta a la respuesta. Actualizar la edición gratuita a su última versión no corrige necesariamente una vulnerabilidad localizada en un paquete comercial distinto. Del mismo modo, desactivar sin comprobar un complemento SSO puede dejar fuera a los usuarios si se ha eliminado el formulario de acceso convencional.
Antes de realizar el cambio conviene verificar que existe una cuenta administrativa local, almacenada de forma segura y probada, que permita entrar después de deshabilitar el inicio de sesión único. En organizaciones donde todo el acceso depende del proveedor de identidad, una desactivación improvisada podría causar una interrupción aunque cierre la vulnerabilidad.
El primer paso es elaborar un inventario inmediato. Cada instalación debe revisarse para confirmar si utiliza OAuth Single Sign On – SSO (OAuth Client), qué edición está activa y si su versión pertenece a la rama afectada hasta la 38.5.8.
Cuando se confirme una versión vulnerable y no exista todavía una actualización oficial, la medida más segura es desactivar el complemento temporalmente. Si la organización no puede prescindir del SSO, debería solicitar instrucciones a miniOrange y aplicar una protección virtual específicamente preparada para CVE-2026-57807.
Patchstack ha publicado una regla de mitigación para sus clientes, aunque reconoce que, debido a la naturaleza del fallo, bloquea tanto solicitudes legítimas como maliciosas en el flujo afectado. Esto puede provocar que determinadas funciones de autenticación o recuperación dejen de estar disponibles mientras la regla permanezca activa.
Las reglas genéricas de un WAF pueden ayudar a reducir exposición, pero no deben presentarse como una solución garantizada. Un fallo lógico de autenticación puede utilizar peticiones aparentemente válidas que no contienen las firmas habituales de SQL injection, subida de archivos o ejecución de comandos.
Cuando sea viable, puede restringirse temporalmente el acceso a los puntos de inicio de sesión y recuperación mediante una VPN, una lista de direcciones autorizadas o una capa de autenticación adicional en el proxy. Esta opción encaja mejor en intranets y aplicaciones privadas que en webs donde cualquier cliente debe iniciar sesión.
También es necesario buscar señales de que el sitio ya haya sido comprometido:
wp-content, uploads o directorios temporales;wp-config.php, .htaccess o usuarios de la base de datos;Si aparecen indicios de intrusión, actualizar o eliminar el complemento no basta. El atacante puede haber creado otra cuenta, instalado una puerta trasera o copiado credenciales. La respuesta debería incluir una revisión de archivos desde una fuente fiable, restauración cuando sea necesaria y rotación de contraseñas administrativas, claves de base de datos, salts de WordPress, tokens de API y secretos OAuth.
Los registros del proveedor de identidad también pueden aportar información. Conviene buscar inicios de sesión que no coincidan con la actividad del usuario, nuevas aplicaciones autorizadas, modificaciones en las URI de redirección o usos inesperados de credenciales del cliente.
La copia de seguridad utilizada para restaurar debe ser anterior al primer acceso malicioso, no simplemente anterior al descubrimiento público de la vulnerabilidad. Una puerta trasera instalada días antes puede sobrevivir si se recupera una copia ya contaminada.
La publicación de CVE-2026-57807 vuelve a poner el foco en una parte especialmente sensible de WordPress: los complementos que controlan la identidad. Un fallo en un editor visual puede exponer contenido; un error en la autenticación puede entregar directamente la cuenta con más privilegios del sistema.
¿Qué versiones están afectadas por CVE-2026-57807?
Patchstack y la NVD señalan las versiones de OAuth Single Sign On – SSO (OAuth Client) hasta la 38.5.8 incluida.
¿Existe ya un parche oficial de miniOrange?
El aviso de Patchstack no mostraba una versión corregida cuando fue publicado. Los administradores deben comprobar el canal oficial del producto antes de reactivar una instalación vulnerable.
¿La vulnerabilidad afecta a millones de webs?
No existe información pública que respalde esa cifra. El complemento gratuito muestra más de 6.000 instalaciones activas, mientras que se desconoce el número de despliegues de la edición comercial vinculada a la rama 38.x.
¿Basta con cambiar la contraseña del administrador?
No. El fallo evita el flujo normal de autenticación. Es necesario desactivar, actualizar o mitigar el complemento y revisar si se crearon usuarios, sesiones, archivos o puertas traseras.
vía: cybersecuritynews y patchstack
