Nombre del complemento	Inicio de sesión sin contraseña de OwnID
Tipo de vulnerabilidad	Omisión de autenticación
Número CVE	CVE-2025-10294
Urgencia	Alto
Fecha de publicación de CVE	2025-10-15
URL de origen	CVE-2025-10294

Bypass crítico de autenticación en OwnID Passwordless Login (<= 1.3.4) — Lo que los propietarios de sitios de WordPress deben hacer ahora mismo

Autor: Equipo de seguridad de WP-Firewall
Fecha: 2025-10-15
Etiquetas: WordPress, seguridad, WAF, vulnerabilidad, autenticación, respuesta a incidentes

---

Resumen — Una vulnerabilidad recientemente divulgada (CVE-2025-10294) en el plugin de WordPress OwnID Passwordless Login (versiones <= 1.3.4) permite a actores no autenticados eludir los controles de autenticación. El problema se clasifica como “Autenticación Rota” con una alta puntuación CVSS. Si ejecutas WordPress y usas este plugin (o un flujo de autenticación sin contraseña que se integre con él), sigue la guía a continuación de inmediato para evaluar, mitigar y recuperarte si es necesario.

---

Por qué esto es importante (corto)

Los flujos de inicio de sesión sin contraseña son atractivos porque reducen la fatiga de contraseñas para los usuarios. Pero también concentran la confianza en un menor número de partes móviles: un punto final de callback, validación de tokens, manejo de nonce/estado y creación de sesiones. Cuando cualquiera de esas verificaciones está incompleta o es eludible, un actor no autenticado puede obtener los mismos derechos que un usuario legítimo, incluido el acceso a nivel de administrador. Ese es precisamente el riesgo reportado para OwnID Passwordless Login <= 1.3.4.

Esta publicación explica el riesgo, qué buscar y pasos prácticos para proteger su sitio hoy. La guía está escrita desde la perspectiva de WP-Firewall (un equipo de firewall y seguridad de WordPress) y está destinada a propietarios de sitios, desarrolladores y equipos de hosting.

---

Acciones rápidas — qué hacer ahora (lista de verificación accionable)

1. Si tiene OwnID Passwordless Login instalado:
   • Desactive el plugin inmediatamente hasta que esté disponible una solución confiable de upstream.
     • wp plugin deactivate ownid-passwordless-login (usando WP-CLI)
     • Panel de control: Plugins → Plugins instalados → Desactivar
2. Si no puede desactivar inmediatamente, restrinja el acceso a wp-admin a IPs de confianza y habilite límites de tasa estrictos en la capa del servidor web/WAF.
3. Monitoree los registros en busca de actividad de inicio de sesión sospechosa o creaciones de usuarios inesperadas (ver sección de Detección a continuación).
4. Implemente un parche virtual a corto plazo con su WAF: bloquee puntos finales sospechosos y combinaciones de parámetros anómalos asociados con el flujo sin contraseña (ver mitigaciones de WP-Firewall).
5. Rote secretos y considere forzar restablecimientos de contraseñas o invalidar todas las sesiones activas para usuarios administrativos.
6. Si sospecha de una posible violación, siga inmediatamente la sección de Respuesta a Incidentes y Limpieza.

Tome estos pasos ahora — no espere una actualización oficial del plugin si su sitio está expuesto.

---

Resumen de la vulnerabilidad

• Software afectado: Plugin OwnID Passwordless Login para WordPress
• Versiones vulnerables: <= 1.3.4
• Tipo de vulnerabilidad: Autenticación rota (OWASP A7)
• CVE: CVE-2025-10294
• Informado por: Jonas Benjamin Friedli (crédito de investigación)
• Privilegio requerido: No autenticado
• Versión corregida: N/A (en el momento de la divulgación)

Descripción de alto nivel: El flujo de autenticación del plugin contiene un defecto de implementación que permite a un atacante eludir las verificaciones de autenticación previstas y obtener una sesión autenticada en un sitio objetivo sin credenciales válidas o consentimiento. El vector de explotación exacto depende de cómo el plugin valida los datos de callback y los tokens en el flujo de trabajo sin contraseña. Debido a que el ataque no requiere autenticación previa, la superficie de ataque es amplia y puede ser explotada de forma remota.

---

Análisis técnico (lo que probablemente está sucediendo)

Los flujos de autenticación sin contraseña normalmente implican:

• Iniciar una solicitud de inicio de sesión (el usuario o cliente activa un desafío sin contraseña).
• Generar un desafío o token de corta duración, registrar el estado y enviar una solicitud de verificación fuera de banda al usuario (correo electrónico/SMS/autenticador de OS).
• Recibir un callback o token de verificación del proveedor de verificación o del cliente.
• Validar el token devuelto y la sesión/estado, luego establecer una sesión de WordPress para el usuario.

Una implementación confiable sin contraseña debe:

• Usar tokens firmados criptográficamente con una caducidad estricta.
• Vincular tokens a un usuario específico y a un estado almacenado (nonce), evitando la repetición de tokens o el intercambio de tokens.
• Validar los URI de origen/redirección y asegurar que las solicitudes de callback sean legítimas.
• Prevenir la creación directa o elevación de sesiones a través de puntos finales no controlados.

En este caso, la vulnerabilidad indica que uno o más de esos pasos de validación están ausentes, incompletos o implementados incorrectamente — por ejemplo:

• Falta o verificación insuficiente del token de callback.
• Falta de asegurarse de que el token esté vinculado al usuario o estado esperado.
• Falta de comprobaciones de nonce/CSRF en los puntos finales que crean sesiones.

Debido a que un atacante puede llamar al punto final vulnerable sin autenticación, puede falsificar una solicitud que resulta en una sesión para un usuario arbitrario, potencialmente incluyendo administradores.

Nota: Esta es una descripción técnica de alto nivel para ayudar a los defensores. Evite compartir detalles públicos de PoC de explotación — ayudarán a los atacantes. Enfóquese en la mitigación.

---

Impacto — por qué esto es crítico

Una vulnerabilidad de omisión de autenticación con acceso no autenticado tiene graves consecuencias:

• Toma de control del sitio: Los atacantes pueden obtener acceso de administrador, modificar contenido, crear puertas traseras o instalar plugins/temas maliciosos.
• Robo de datos: Acceso a datos de usuarios, páginas privadas y contenido almacenado.
• Compromiso persistente: Los atacantes pueden crear usuarios administradores ocultos o tareas programadas (cron) para mantener el acceso.
• Daño a la reputación: Desfiguración, spam o inclusión en listas negras por motores de búsqueda.
• Movimiento lateral para hosts: En entornos compartidos, un sitio comprometido puede ser un punto de apoyo para atacar otras cuentas si los permisos están mal configurados.

Debido a que esta vulnerabilidad permite acceso no autenticado, la probabilidad de explotación masiva automatizada es alta. Los atacantes escanean la web en busca de firmas de plugins vulnerables y intentan sistemáticamente omisiones de inicio de sesión.

---

Cómo detectar la explotación en su sitio

Señales inmediatas a verificar:

1. Usuarios administradores inesperados:
   • WP-CLI: wp user list --role=administrator
   • Panel de control: Usuarios → Todos los usuarios → filtrar por Administrador
   • Busque administradores o usuarios recientemente creados con direcciones de correo electrónico extrañas.
2. Inicios de sesión recientes exitosos para usuarios administradores desde direcciones IP desconocidas:
   • Verifique los registros de acceso de su servidor web (nginx/apache) en busca de solicitudes POST a wp-login.php o a puntos finales REST con respuestas 200/302 alrededor de marcas de tiempo sospechosas.
   • Si tiene habilitada la auditoría de actividad (registros de auditoría), verifique los inicios de sesión de administradores fuera del horario laboral.
3. Cambios de archivos y nuevos archivos:
   • Busque en los directorios de plugins/temas y wp-content archivos inesperados.
   • Indicadores comunes: archivos con nombres similares a los archivos PHP del sistema pero con marcas de tiempo recientes, archivos que contienen evaluar/base64_decode/gzuncompress.
   • Comando de búsqueda de muestra (ejecutado desde la raíz del sitio):
     buscar . -tipo f -mtime -14 -imprimir
     (Lista archivos modificados en los últimos 14 días.)
4. Cambios en la base de datos:
   • Verifique si hay modificaciones en opciones_wp (entradas de auto-carga sospechosas), nuevos trabajos cron (wp_options->cron), o cambios de contenido no autorizados.
   • Busque PHP sospechoso en opciones:
     SELECT option_name, LENGTH(option_value) FROM wp_options WHERE option_name LIKE '%template%' OR option_name LIKE '%cron%';
5. Tráfico saliente inusual:
   • Verifique el firewall del servidor o los registros de red para conexiones a IPs/dominios desconocidos que provengan de su servidor web.
6. Patrones de actividad de inicio de sesión específicos para puntos finales sin contraseña:
   • Revise los registros de acceso para solicitudes POST/GET a puntos finales asociados con el plugin o para parámetros sospechosos que coincidan con el flujo sin contraseña.

Mantenga copias detalladas de los registros para investigación y posible análisis forense.

---

Opciones de mitigación inmediata (propietarios y administradores del sitio)

Si ejecuta el plugin vulnerable, elija la ruta segura más rápida:

1. Desactive el plugin de inmediato
   • Mitigación a corto plazo más confiable.
   • Use WP-CLI cuando tenga muchos sitios que administrar:
     wp plugin deactivate ownid-passwordless-login --allow-root
2. Si no puedes desactivar:
   • Restringir el acceso a los puntos finales relevantes a través de reglas del servidor web (denegar todas las IP excepto las IP de administradores de confianza).
   • Agregar un .htaccess o un fragmento de nginx para denegar el acceso a los archivos PHP del plugin y a los puntos finales que producen la vulnerabilidad.
   • Ejemplo (nginx, bloquear por patrón de URI):
     
ubicación ~* /wp-content/plugins/ownid-passwordless-login/ {
    devolver 403;
}

   • Nota: Ten cuidado: bloquear por ruta puede romper características legítimas. Prefiere desactivar cuando sea posible.
3. Usa tu WAF para implementar parches virtuales:
   • Bloquear solicitudes con cargas útiles de parámetros sospechosos a los puntos finales del plugin.
   • Hacer cumplir verificaciones de origen y referer para solicitudes que establezcan sesiones.
   • Agregar límites de tasa estrictos para frenar ataques de fuerza bruta y escaneos automatizados.
4. Rotar claves e invalidar sesiones:
   • Forzar restablecimientos de contraseña para usuarios administradores:
     wp user update --user_pass=''
   • Invalidar sesiones pidiendo a los usuarios que cierren sesión y/o utilizando plugins que destruyan sesiones activas.
   • Restablecer cualquier clave API compartida a nivel de sitio utilizada por flujos de autenticación.
5. Endurecer el acceso de administrador:
   • Restringir temporalmente wp-admin a direcciones IP de confianza.
   • Habilitar la autenticación de dos factores para cuentas de administrador (si es posible).
   • Mover la página de inicio de sesión o usar una capa de acceso que requiera un secreto compartido o autenticación HTTP básica para wp-admin.
6. Mantener copias de seguridad:
   • Asegúrate de tener una copia de seguridad conocida y buena tomada antes de cualquier compromiso sospechado. No sobrescribir copias de seguridad con un estado comprometido.

---

Recomendaciones de parches virtuales de WP-Firewall (cómo un WAF puede protegerte ahora)

Como proveedor de firewall de WordPress, recomendamos las siguientes reglas de WAF en capas (genéricas, no específicas de explotación) para mitigar el riesgo hasta que esté disponible un parche en la parte superior:

1. Bloquear o desafiar solicitudes a los puntos finales del plugin:
   • Identificar los puntos finales REST del plugin, las acciones de admin-ajax y las rutas de archivos del plugin.
   • Bloquear solicitudes POST a esos puntos finales desde rangos de IP no confiables o aplicar un desafío CAPTCHA/JavaScript.
2. Hacer cumplir las verificaciones de encabezados HTTP:
   • Requerir un encabezado Origin y Referer válidos para solicitudes que crean sesiones, y rechazar solicitudes con encabezados faltantes o claramente falsificados de clientes no confiables.
   • Validar encabezados comunes como Content-Type y desautorizar tipos inesperados.
3. Limitar la tasa de flujos sospechosos:
   • Aplicar límites de tasa estrictos por IP en los puntos finales de creación de sesiones para interrumpir la explotación automatizada.
   • Considerar retrasos progresivos o bloqueos temporales después de un pequeño número de intentos.
4. Detectar combinaciones de parámetros anómalos:
   • Crear reglas para coincidir con patrones inusuales en parámetros de token, estado o identificación de usuario utilizados por flujos sin contraseña (por ejemplo, tokens que son demasiado cortos/largos o contienen caracteres mal formados).
5. Proteger el área de administración con una capa de acceso:
   • Requerir autenticación adicional o lista blanca de IP para wp-admin y XML-RPC. Esto detiene muchas técnicas de movimiento lateral incluso si un atacante logra eludir el plugin.
6. Auditoría y alerta:
   • Crear alertas de WAF en solicitudes POST que resulten en acciones de autenticación exitosas sin un desafío previo o un valor de estado válido.
   • Reenviar alertas a los administradores del sitio y equipos de hosting para revisión inmediata.

Importante: No confiar únicamente en las reglas de WAF como una solución a largo plazo: son una mitigación. El plugin debe ser actualizado o reemplazado por una implementación segura.

---

Firmas de detección y sugerencias de registro para WAF y hosts

Crear reglas para registrar y alertar sobre los siguientes comportamientos observables:

• Solicitudes POST a puntos finales específicos del complemento de clientes sin una cookie de sesión válida.
• Respuestas HTTP exitosas (200/302) de los puntos finales de creación de sesión seguidas inmediatamente por solicitudes a /wp-admin/ o admin-ajax.php desde la misma IP.
• Intentos repetidos de crear o modificar cuentas utilizando los puntos finales del complemento.
• Volúmenes de solicitudes anormales para puntos finales sin contraseña desde una sola IP o un pequeño rango de IP.

Campos de registro a capturar para correlación:

• Marca de tiempo, IP de origen, User-Agent
• URI de solicitud y cadena de consulta
• Nombres de parámetros del cuerpo POST (evitar registrar cuerpos completos si contienen tokens sensibles)
• Código de respuesta y tamaño de respuesta
• Estado de la cookie e ID de sesión (si está presente)

Almacenar registros fuera del host cuando sea posible para prevenir manipulaciones durante una investigación.

---

Respuesta a incidentes y limpieza (si sospechas de un compromiso)

Si encuentras evidencia de compromiso, sigue un flujo de limpieza estructurado:

1. Aísle el sitio:
   • Pon el sitio en modo de mantenimiento o desconéctalo mientras investigas y limpias.
   • Si estás en un hosting compartido, notifica a tu proveedor de inmediato y pídeles que aíslen la cuenta.
2. Preservar las pruebas:
   • Haz una copia de los registros del servidor web, volcado de bases de datos y instantáneas del sistema de archivos para la investigación forense. No modifiques estas copias.
3. Rota credenciales y claves:
   • Cambia las contraseñas de administrador de WordPress y cualquier clave API utilizada por el sitio.
   • Rota las contraseñas de hosting y base de datos.
4. Elimina el plugin vulnerable y reemplázalo:
   • Desactiva y elimina OwnID Passwordless Login.
   • Reemplaza con una alternativa bien revisada solo después de verificación y pruebas independientes.
5. Busca y elimina puertas traseras:
   • Escanea en busca de archivos PHP inyectados que contengan palabras clave: evaluar, base64_decode, preg_replace con /e, create_function, gzinflate, sistema, exec, shell_exec.
   • Comando de ejemplo para encontrar usos sospechosos:
     grep -R --exclude-dir=uploads -nE "eval\(|base64_decode\(|gzinflate\(|shell_exec\(|system\(" .
6. Inspecciona la base de datos en busca de cambios no autorizados:
   • Tabla de usuarios (wp_usuarios) para cuentas desconocidas.
   • Tabla de opciones para código malicioso autoloaded.
   • Tabla de publicaciones para scripts inyectados.
7. Reinstala el núcleo, plugins y temas de fuentes confiables:
   • No confíes en archivos en el sistema de archivos comprometido. Reemplázalos descargando copias nuevas desde WordPress.org o sitios de desarrolladores.
8. Restaura desde una copia de seguridad limpia:
   • Si tienes una copia de seguridad limpia tomada antes del compromiso, restaura y luego aplica endurecimiento de seguridad.
9. Monitoreo post-recuperación:
   • Monitorea los registros de cerca durante más de 30 días después de la recuperación en busca de signos de reinfección.
   • Considera una auditoría de seguridad profesional si el sitio contiene datos sensibles.
10. Considere contratar una respuesta profesional a incidentes si maneja datos financieros o personales a gran escala.

---

Endurecer la autenticación de WordPress (a largo plazo)

1. Evite puntos únicos de falla: los flujos sin contraseña están bien, pero asegúrese de que se implementen con tokens firmados, vinculación de nonce y validación estricta.
2. Haga cumplir la autenticación multifactor para los usuarios administradores.
3. Minimice las cuentas de administrador: use el principio de menor privilegio.
4. Mantenga los complementos y temas actualizados y solo instale complementos de fuentes confiables.
5. Utilice un proceso central de monitoreo y parcheo para todos los sitios que administre.
6. Habilite el registro y la alerta para inicios de sesión de administradores y cambios inesperados de archivos.
7. Endurezca los permisos de archivos y desactive la ejecución de PHP en las cargas cuando sea posible:

   <FilesMatch "\.php$">
     Deny from all
   </FilesMatch>
       

8. Haga cumplir contraseñas fuertes y rotación periódica para los usuarios administradores.

---

Recomendaciones para desarrolladores de complementos (lista de verificación de seguridad por diseño)

• Utilice tokens firmados (JWT o similar) con expiraciones cortas y reclamaciones de audiencia.
• Vincule tokens a un estado o nonce almacenado del lado del servidor y validado en la devolución de llamada.
• Valide estrictamente las URI de redirección y los orígenes.
• Siempre verifique el emisor y la firma de los tokens que provienen de proveedores de terceros.
• Evite crear sesiones o elevar privilegios en solicitudes GET simples.
• Implemente protección CSRF/nonce para cualquier punto final que pueda cambiar el estado o crear sesiones.
• Registre eventos de autenticación significativos con suficiente contexto (sin exponer secretos).
• Cree un proceso de divulgación responsable y mantenga una línea de tiempo de parches.
• Proporcione orientación de endurecimiento a los propietarios del sitio y recomiende reglas de WAF donde sea apropiado.

---

Para hosts y agencias: recomendaciones operativas

• Aplique parches rápidamente y proporcione parches virtuales bajo demanda si un complemento utilizado por muchos clientes es vulnerable.
• Ofrezca servicios de aislamiento y escaneo del sitio para clientes potencialmente afectados.
• Bloquee o limite la tasa de patrones de escaneo y explotación maliciosos conocidos en el borde.
• Notifique a los clientes con pasos accionables y ofrezca ayuda para implementar mitigaciones (desactivación, bloqueo, restablecimientos de sesión).
• Mantenga un proceso de respaldo y recuperación probado y ofrezca respuesta a incidentes como servicio.

---

Cronograma y referencias

• Fecha del informe: 15 de octubre de 2025
• CVE: CVE-2025-10294
• Investigación acreditada a: Jonas Benjamin Friedli

Para la divulgación técnica, consulte la entrada oficial de CVE y el informe del investigador. (No reproducimos el código de explotación aquí para evitar habilitar a los atacantes.)

---

Preguntas frecuentes

P — Si desactivo el complemento, ¿los usuarios perderán acceso a sus cuentas?
R — Desactivar el complemento deshabilitará el flujo sin contraseña proporcionado por ese complemento. Los usuarios que dependen de él necesitarán iniciar sesión a través de un nombre de usuario/contraseña estándar u otro método de autenticación disponible hasta que haya un reemplazo seguro o una versión parcheada disponible.

P — ¿Mi sitio está automáticamente comprometido si tengo el complemento instalado?
R — No automáticamente. La presencia de vulnerabilidades indica posibilidad; el compromiso real depende de si un atacante descubrió y explotó con éxito la falla en su sitio. Debe asumir el riesgo y actuar en consecuencia.

P — ¿Cuándo estará disponible un parche oficial?
R — En el momento de la divulgación puede que no haya un lanzamiento oficial corregido. Siga el canal oficial del complemento para actualizaciones y aplique el parche inmediatamente cuando se publique. Mientras tanto, aplique las mitigaciones descritas anteriormente.

---

Proteja sus sitios de WordPress: plan WP-Firewall Basic (Gratis)

Protección más fuerte sin costo

Si gestionas sitios de WordPress, aprovecha el plan WP-Firewall Basic (Gratis) — diseñado para ofrecer protección esencial y gestionada sin compromiso. El plan gratuito incluye nuestro firewall gestionado, ancho de banda ilimitado, un Firewall de Aplicaciones Web (WAF) activo, un escáner de malware y protecciones que mitigan los riesgos del OWASP Top 10. Es un primer paso fácil para reducir la ventana de riesgo de vulnerabilidades de plugins como esta.

Regístrate en el plan gratuito y obtén reglas de mitigación virtual instantáneas aplicadas a tu sitio: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si necesitas eliminación automática de malware, controles de lista negra/blanca de IP, informes de seguridad mensuales y parches virtuales de vulnerabilidad, revisa nuestros planes Standard y Pro para características y soporte adicionales.)

---

Palabras finales — prioriza la contención y verificación

Esta omisión de autenticación es una vulnerabilidad de alto impacto porque no requiere credenciales previas. Si tu sitio utiliza OwnID Passwordless Login (<=1.3.4), actúa ahora: desactiva o bloquea el plugin, aplica mitigaciones de WAF e inspecciona los registros en busca de signos de compromiso. Si ejecutas muchos sitios de WordPress, automatiza los pasos de detección y mitigación con una solución de firewall gestionado para reducir el tiempo de triaje manual y proteger a los clientes antes de que se publique un parche oficial.

Si necesitas ayuda para evaluar un sitio o implementar parches virtuales, el soporte de WP-Firewall está disponible para ayudar con flujos de trabajo de mitigación y recuperación rápida.

Mantenerse seguro,
El equipo de seguridad de WP-Firewall