Vulnerabilidad XSS en WordPress que puede escalar a PHP y la urgencia de parchear ya

WordPress publicó el 6 de agosto un parche que corrige una vulnerabilidad de cross-site scripting (XSS) reflejado en la pantalla de acceso que, según el descubrimiento público, puede llegar a encadenarse hasta ejecución de código PHP en determinadas condiciones. La falla fue reportada por la empresa pwn.ai y registrada como CVE-2026-64638 (puntuación CVSS 8.9). WordPress incluyó la corrección en la versión 7.0.3 y la aplicó retroactivamente hasta la rama 4.7; las instalaciones con actualizaciones automáticas habilitadas deberían recibir el parche sin intervención del administrador. Puede consultarse la referencia del CVE en la base de datos NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-64638, y el anuncio oficial de seguridad de WordPress en su categoría de noticias: https://wordpress.org/news/category/security/.

Lo confirmado por pwn.ai es que el XSS es de tipo reflejado y accesible desde la página de login sin autenticación: un nombre de usuario especialmente formado enviado en un intento de acceso fallido puede llegar al usuario final dentro de la página de error y ejecutar JavaScript en el navegador. Ese JavaScript, según la compañía, puede encadenarse con otros comportamientos de WordPress para provocar peticiones same-origin que permitan control adicional dentro de la sesión del sitio. WordPress, en su asesoría pública, describe una evaluación más cautelosa: la escalada desde ese XSS hasta ejecutar código en el servidor (RCE) exige condiciones externas al control del atacante —en particular, interacción y aprobación explícita de un administrador— y por tanto requiere éxito en ingeniería social además de la vulnerabilidad inicial.

Técnicamente, el fallo surge por un conflicto entre distintos filtros que WordPress aplica al valor del nombre de usuario tras un intento fallido de acceso. De forma simplificada y comprobada por los investigadores, el dato pasa por sanitize_user() y por wp_strip_all_tags() (que usa la función PHP strip_tags()). Cadenas que parecen etiquetas HTML pero contienen espacios inmediatamente después del signo "<" pueden sobrevivir a ese primer procesado como texto. Más abajo, WordPress aplica wp_kses_post(), cuyo parser interpreta esa misma entrada como HTML permitido, lo que resulta en la inserción de elementos DOM controlados por el atacante en la página de error de login. Esos elementos terminan interactuando con user-profile.js, un script de gestión de perfil que se carga en la página de login por el manejo de restablecimiento de contraseñas; la ausencia de ciertos campos esperados en ese contexto deja variables en estado undefined y permite que un elemento inyectado sobrescriba, por ejemplo, ajaxurl, redirigiendo la lógica JavaScript hacia una petición REST seleccionada por el atacante. pwn.ai demostró además cómo aprovechar la compatibilidad con JSONP en la API REST de WordPress para convertir la respuesta en código JavaScript ejecutado con el origen del sitio. En entornos donde la API responde 401 para peticiones anónimas, el parámetro _envelope=1 puede envolver esa negación con un 200 externo y hacer que jQuery procese la respuesta como script.

Los investigadores denominaron su cadena XSS2Shell y describen múltiples rutas hacia ejecución en PHP. Una de las demostraciones reproducidas por pwn.ai usa el XSS para invocar la interfaz nativa de aprobación de Application Passwords dentro de una sesión ya autenticada con rol Administrador. Esa interfaz crea una credencial API y redirige a una URL de éxito controlada por el atacante; con la credencial creada, el atacante puede publicar una página que contiene JavaScript same-origin y, cuando un administrador autenticado la abre, ese script obtiene el nonce para subir plugins y realiza la subida de un archivo ZIP que contiene código PHP. En la prueba de concepto de pwn.ai el código PHP pudo solicitarse directamente desde el plugin extraído sin necesidad de activar el plugin. Importante: pwn.ai separó los pasos en pruebas distintas: la reproducción del XSS en servidores remotos se realizó en instalaciones WordPress 7.0.2 sin cookies de sesión, mientras que la demostración completa que llega a ejecución de PHP se hizo en un entorno local limpio.

Qué está confirmado: existe un XSS reflejado en la página de login sin necesidad de autenticación y WordPress publicó un parche el 6 de agosto. pwn.ai reprodujo localmente la cadena completa hasta PHP execution y demostró la explotación del camino de Application Passwords en laboratorio. WordPress reconoció el hallazgo, acreditó al equipo y emitió la actualización de seguridad; al cierre de la evidencia pública (7 de agosto) no había informes verificados de explotación en la naturaleza.

Qué es estimación o aún incierto: el grado en que esta cadena se está explotando activamente contra sitios en producción no está confirmado; la escalada a RCE requiere la interacción de un administrador autenticado y, según WordPress, elementos de ingeniería social que están fuera del control técnico del atacante. La eficacia de mitigaciones parciales (por ejemplo, políticas CSP complejas o ciertos hardenings) fue probada por los investigadores en algunos escenarios y encontraron que una política CSP basada en nonce con strict-dynamic no impidió la demostración, pero el comportamiento puede variar según plugins, configuraciones y versiones del servidor.

¿A quiénes afecta? Prácticamente cualquier instalación de WordPress que no haya aplicado la actualización: los investigadores aseguran que la cadena funciona contra instalaciones por defecto y no requiere configuraciones de hosting inusuales. Las instalaciones anteriores a la rama 4.7 quedan fuera del soporte de backports y, por tanto, siguen expuestas si no se actualizan o parchean manualmente.

Consecuencias concretas de una explotación completa serían graves: obtención de credenciales almacenadas en wp-config.php, creación persistente de cuentas administrativas, subida y ejecución de código PHP, modificación o borrado de contenido y exposición de archivos o secretos accesibles por el proceso PHP. El alcance real de daño depende del contexto del servidor (privilegios del worker PHP, medidas de filesystem, disponibilidad de backups y controles de integridad).

Medidas prácticas y específicas que deben aplicar los administradores hoy mismo: actualizar a WordPress 7.0.3 u otra versión que incluya la corrección; si la actualización no es posible de inmediato, minimizar exposición del archivo de acceso: proteger wp-login.php con autenticación HTTP adicional o restringir su acceso por IP, activar un WAF con reglas que bloqueen inyecciones en parámetros de login, deshabilitar edición de plugins/temas desde el dashboard, revocar Application Passwords creados recientemente y auditar la lista de credenciales. Después de la actualización, revisar el sitio buscando cuentas administrativas nuevas o modificaciones de plugins/themes y comprobar integridad de archivos y presencia de archivos ZIP o plugins no legítimos. Si sospecha compromiso, cambie las claves de salts en wp-config.php, restaure desde backups limpios y considere una auditoría forense. Habilitar 2FA y limitar el uso de cuentas con privilegios elevadas reduce la ventana de explotación por ingeniería social.

Finalmente, mantenga copias de seguridad fuera del servidor production y active actualizaciones automáticas cuando sea posible; WordPress indica que sitios con actualizaciones en segundo plano deberían recibir el release automáticamente. Dado que la explotación completa descrita por pwn.ai requiere interacción adicional con un administrador, la combinación de parche inmediato, controles de acceso al login y prácticas fuertes de seguridad operacional es la defensa más eficaz.

El hallazgo ilustra cómo vulnerabilidades aparentemente de presentación (XSS en una página de error) pueden convertirse en vectores críticos cuando interactúan con lógica existente y APIs del mismo sitio. La recomendación técnica y práctica es inequívoca: aplicar la actualización oficial sin demora y revisar administradores y credenciales expuestos.