WordPress solucionó una vulnerabilidad grave de XSS en su pantalla de inicio de sesión que afectaba a todas las versiones. Atacantes podrían ejecutar código PHP en el servidor si lograban que un administrador interactuara con una página maliciosa. Se recomienda actualizar inmediatamente a la versión 7.0.3 o superiores para mitigar este riesgo.







WordPress ha corregido un fallo de cross-site scripting (XSS) reflejado previo a la autenticación en su pantalla de inicio de sesión que afecta a todas las versiones del sistema de gestión de contenidos. pwn.ai demostró cómo este fallo puede encadenarse para lograr la ejecución de código PHP en el servidor cuando un administrador conectado interactúa con una página controlada por un atacante.

Rastreada como CVE-2026-64638 (puntuación CVSS: 8.9), esta vulnerabilidad de gravedad alta no requiere privilegios del atacante. Según pwn.ai, que descubrió el fallo y compartió los detalles técnicos, el XSS de la página de inicio de sesión no requiere autenticación. Una vez que un nombre de usuario manipulado llega a la página de error de inicio de sesión fallido, el JavaScript resultante se ejecuta en el navegador del visitante sin necesidad de más interacción en esa página.

La ruta de ejecución de código requiere que la víctima ya esté conectada como Administrador y una interacción explícita con una página controlada por el atacante. En la demostración de pwn.ai, esa interacción es un simple clic.

Los investigadores indicaron que el ataque funciona contra instalaciones predeterminadas de WordPress y no requiere configuraciones de despliegue o hosting inusuales. También afirmaron tener múltiples rutas desde el XSS hasta la ejecución de código, incluyendo variantes que instalan un plugin o suben un archivo ZIP arbitrario.

El aviso de WordPress adopta una visión más cautelosa sobre la explotabilidad, señalando que la escalada a RCE implica condiciones fuera del control del atacante y requiere ingeniería social exitosa más la interacción explícita de la víctima.

El problema fue parcheado el 6 de agosto en WordPress 7.0.3 (enlace), con correcciones retrocedidas hasta la rama 4.7. WordPress recomienda que actualices inmediatamente; los sitios con actualizaciones automáticas en segundo plano deberían recibir la versión de seguridad automáticamente. Las versiones anteriores a la 4.7 siguen afectadas pero están fuera del rango actual de soporte del proyecto.

Los investigadores, que llaman a la cadena de ataque XSS2Shell, dijeron que su sistema autónomo descubrió y reprodujo la cadena de vulnerabilidades tras utilizar la investigación de Paulos Yibelo de 2022 sobre Same Origin Method Execution (SOME) como punto de partida.

La empresa afirmó que el trabajo tomó casi cuatro días utilizando modelos de código abierto y un flujo de trabajo multiagente. La cadena fue reproducida el 26 de julio y reportada a WordPress al día siguiente.

El funcionamiento del fallo

El fallo comienza en la forma en que WordPress maneja el nombre de usuario de un inicio de sesión fallido. Según los investigadores, el valor pasa por sanitize_user() y wp_strip_all_tags(), que depende de strip_tags() de PHP. Una cadena similar a una etiqueta que contiene un espacio en blanco después del < de apertura puede sobrevivir a ese analizador como texto. Más tarde, WordPress pasa el valor por wp_kses_post(), cuyo analizador independiente interpreta la misma entrada como HTML permitido. El resultado son elementos DOM vivos controlados por el atacante en la página de inicio de sesión fallido.

Esos elementos luego interactúan con user-profile.js de WordPress, un script de gestión de perfiles que también se carga en la página de inicio de sesión porque esta maneja el restablecimiento de contraseñas.

Algunos elementos del perfil que el script espera están ausentes allí: dos entradas faltantes se resuelven como "undefined", permitiendo que pase una comprobación de igualdad, mientras que la variable ajaxurl (que normalmente es indefinida) puede ser sustituida por un elemento DOM inyectado. Esto dirige el JavaScript de WordPress hacia una solicitud REST de mismo origen seleccionada por el atacante.

Los investigadores utilizan el soporte JSONP de REST de WordPress para convertir esa solicitud en JavaScript que se ejecuta en el origen del sitio. Para despliegues donde las solicitudes REST anónimas devuelven un HTTP 401, el parámetro _envelope=1 puede envolver la denegación en una respuesta HTTP 200 externa, permitiendo que jQuery continúe procesando la respuesta como un script.

Los investigadores también descubrieron en sus pruebas que una Política de Seguridad de Contenido (CSP) basada en nonce utilizando strict-dynamic no bloqueó la ruta demostrada.

De XSS a ejecución de PHP

La ruta desde el XSS hasta la ejecución de PHP se basa en la técnica SOME de Yibelo, que utiliza una cadena de propiedades JSONP permitida para invocar un método en otra ventana del navegador.

Una ruta demostrada por pwn.ai utiliza el XSS de origen de WordPress para invocar el control nativo de aprobación de Contraseñas de Aplicación dentro de la sesión de un Administrador conectado. WordPress entonces crea una credencial de API y la redirige a una success_url HTTPS seleccionada por el atacante.

Las Contraseñas de Aplicación son credenciales revocables destinadas al acceso a la API, por lo que esta ruta no necesita robar la contraseña principal del administrador. Los investigadores usaron la credencial para acceder a REST autenticado y publicar una página de WordPress que contenía JavaScript de mismo origen. Cuando la sesión del administrador abrió esa página, el script obtuvo el nonce de subida de plugins de WordPress y subió un archivo ZIP suministrado por el atacante. Luego, se pudo solicitar PHP directamente desde el plugin extraído. El plugin no necesitaba ser activado.

La evidencia de producción se detiene en el XSS. Los investigadores reprodujeron por separado el XSS de la página de inicio de sesión sin cookies contra dos despliegues de WordPress 7.0.2 en perfiles de Chrome limpios sin cookies ni credenciales de WordPress.

No intentaron la creación de Contraseñas de Aplicación, la subida de archivos, la persistencia o la ejecución de PHP en esos sistemas. La cadena completa de ejecución de PHP fue demostrada por separado en una instalación local limpia de WordPress 7.0.2.

Los investigadores advirtieron que las medidas conocidas de endurecimiento (hardening) de WordPress no deben tratarse como una mitigación completa para el XSS subyacente y que es obligatorio aplicar la actualización de seguridad.

Una ejecución exitosa de PHP expondría las credenciales de la base de datos de WordPress en wp-config.php, permitiría la creación persistente de administradores y cambios de contenido, expondría archivos y secretos legibles por el trabajador de PHP, y permitiría ejecutar comandos del sistema operativo con los privilegios de dicho trabajador.

WordPress acreditó al equipo de pwn.ai el descubrimiento y la divulgación responsable de la vulnerabilidad. Hasta el 7 de agosto, el aviso del proyecto no reporta explotaciones activas en entornos reales.

Fuente:
THN