WordPress ha publicado un parche urgente tras descubrir y corregir una vulnerabilidad de XSS en WordPress en la pantalla de acceso. Aunque el fallo comienza sin necesidad de privilegios del atacante, su impacto puede crecer de forma peligrosa cuando se combina con acciones específicas por parte de un administrador ya autenticado.
La corrección ya está disponible y la recomendación es clara: actualiza de inmediato. A continuación te explicamos qué se sabe, por qué el riesgo es alto y qué pasos deberías tomar para proteger tu sitio.
Qué es la vulnerabilidad y por qué importa
El problema corregido se clasifica como una reflected cross-site scripting (XSS) previa a la autenticación en el formulario de inicio de sesión. Está asociada a la identificación CVE-2026-64638 y tiene una severidad alta (CVSS 8.9).
Según la investigación compartida por pwn.ai, la lógica afectada permite inyectar contenido que termina ejecutándose en el navegador del visitante cuando este alcanza la página de error del inicio de sesión. En esa fase, el atacante no necesita autenticarse: basta con que consiga que un valor especialmente preparado llegue a la respuesta que muestra el error.
Cómo funciona el encadenamiento hacia ejecución de PHP
El salto desde la XSS hasta la ejecución de código PHP no ocurre de manera automática. Para que la cadena avance se requieren condiciones concretas:
- La víctima debe estar ya iniciada como Administrador en WordPress.
- Además, necesita interactuar de forma explícita con una página controlada por el atacante.
- En las pruebas divulgadas, esa interacción se describe como un clic ordinario.
La cadena se describe con el nombre XSS2Shell. El punto de partida es la manipulación del username que WordPress procesa al fallar el inicio de sesión. Ese valor se mueve por distintas funciones del sistema antes de llegar al navegador, donde termina materializándose como elementos del DOM controlados por el atacante.
En términos prácticos, el efecto permite que el JavaScript inyectado interactúe con componentes internos que se cargan en la propia página de acceso (incluidas rutinas vinculadas al manejo de restablecimiento de contraseñas y scripts de gestión de perfil). Desde ahí, se puede forzar a WordPress a dirigir llamadas hacia rutas REST del mismo origen.
Detalle técnico: del DOM inyectado a solicitudes REST
Los investigadores explican que la vulnerabilidad se apoya en cómo WordPress transforma y valida el nombre de usuario al mostrar el mensaje de error. En el proceso intervienen funciones como sanitize_user() y wp_strip_all_tags(), y el filtrado se ve afectado por cómo ciertos patrones “parecidos a etiquetas” pueden sobrevivir como texto.
Luego, una validación posterior mediante wp_kses_post() interpreta el mismo contenido de una manera que puede permitir la creación de elementos HTML “vivos” dentro del DOM de la página de error. El resultado es que el navegador del visitante termina con elementos que el atacante controla.
Después, esos elementos interactúan con un script propio del sistema, user-profile.js, que también se carga en el entorno de inicio de sesión porque la página incluye funcionalidad relacionada con restablecer contraseñas. Al faltar algunos elementos esperados, la lógica interna puede entrar en un estado donde ciertas comprobaciones se superan de forma indebida y donde además se puede clobber un valor asociado a ajaxurl mediante un elemento inyectado.
Con ello, el flujo del JavaScript interno se orienta a una solicitud REST seleccionada por el atacante dentro del mismo origen.
¿Qué papel juega JSONP y el Content Security Policy?
En la cadena descrita, los investigadores utilizan el soporte de WordPress para JSONP en respuestas REST para conseguir que la respuesta se procese como script, de manera que el navegador ejecute código bajo el origen del sitio.
Además, señalan que, en pruebas realizadas, una Content Security Policy basada en nonces con la directiva strict-dynamic no bloqueó el recorrido demostrado.
Esto es importante porque muchos administradores aplican políticas CSP para reducir el riesgo de ejecución de scripts. En este caso, el informe indica que dicha capa no resulta suficiente para detener por completo la cadena cuando la XSS ya está presente y se cumplen los demás requisitos.
Vector alternativo: Application Password y carga de un plugin
Además del recorrido que llega a solicitudes REST y ejecución posterior, pwn.ai describe una vía que usa el flujo de Application Passwords dentro de una sesión de administrador.
En esa lógica, WordPress genera un control de aprobación y redirige hacia un success_url seleccionado por el atacante usando credenciales de API. Dado que estas credenciales están pensadas para acceso a API y pueden revocarse, la cadena no depende necesariamente de robar la contraseña principal del administrador.
Según la explicación, los investigadores usan esas credenciales para publicar una página que incluye JavaScript del mismo origen. Cuando el administrador (ya autenticado) abre esa página, el script obtiene un nonce para subir plugins y finalmente carga un ZIP proporcionado por el atacante.
En la demostración descrita, el plugin no necesita activarse: el paso posterior puede solicitar código PHP directamente desde el paquete extraído.
Qué tan real es el riesgo y qué significa para tu sitio
La ruta XSS→PHP no es “una puerta abierta” para cualquier visitante. Aun así, el informe recalca que el impacto puede ser severo si el administrador de un sitio vulnerable interactúa con una página maliciosa en un contexto adecuado.
Entre los resultados potenciales de una ejecución de PHP exitosa se mencionan consecuencias graves: exposición de credenciales de base de datos en wp-config.php, capacidad para crear o modificar cuentas con rol de administrador, lectura de archivos y secretos accesibles por el proceso PHP, y posibilidad de ejecutar comandos a nivel del sistema con los permisos del worker de PHP.
Por su parte, el aviso oficial de WordPress adopta un enfoque más conservador sobre la explotabilidad completa, indicando que la escalada hacia ejecución remota requiere condiciones que no controla el atacante, incluyendo además ingeniería social y una interacción explícita de la víctima.
Actualización y versiones afectadas
WordPress corrigió la vulnerabilidad el 6 de agosto con el parche incluido en la rama 7.0.3. También se realizaron retroportaciones para la rama 4.7.
La recomendación es actualizar de inmediato. Los sitios que tengan habilitadas actualizaciones automáticas en segundo plano deberían recibir la actualización de seguridad sin intervención manual.
Las versiones anteriores a 4.7 siguen siendo vulnerables, aunque quedan fuera del rango actual de retroportación del proyecto.
Medidas adicionales (y límites de la mitigación)
Los investigadores advierten que las medidas de endurecimiento conocidas no deben tratarse como mitigación completa del problema de fondo. En otras palabras: puedes aplicar defensas de superficie, pero la solución real es instalar el parche.
Además, como el recorrido descrito requiere interacción y un administrador autenticado, conviene reforzar prácticas operativas: limitar la navegación de administradores hacia enlaces no confiables, revisar permisos y sesiones activas, y promover controles de seguridad que reduzcan la probabilidad de que se cumplan las condiciones de la cadena.
Resumen final
La vulnerabilidad corregida demuestra por qué XSS en WordPress es un riesgo que no debe subestimarse. Aunque el fallo comienza en la pantalla de acceso sin autenticación del atacante, la cadena puede avanzar hasta ejecución de PHP bajo condiciones específicas y con interacción de un administrador.
Si administras un sitio con WordPress, actúa ya: instala la actualización disponible (por ejemplo, 7.0.3 u otra versión corregida correspondiente a tu rama). Es la medida más efectiva para cortar la cadena de ataque.
Fuente: https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
