Un agujero en WordPress: el formulario de acceso entrega el servidor
Una vulnerabilidad de WordPress apodada XSS2Shell convierte un intento de inicio de sesión fallido en código PHP ejecutándose en el servidor. Registrada como CVE-2026-64638, alcanza 8,9 puntos en la escala CVSS. Empieza con un nombre de usuario escrito en el formulario público de acceso y termina, en las condiciones adecuadas, con un plugin del atacante descomprimido dentro de su instalación. WordPress publicó la corrección en la versión 7.0.3 el 6 de agosto de 2026 y la retroportó hasta la rama 4.7. El código de explotación público apareció en cuestión de días.
Cómo funciona la cadena XSS2Shell
El punto de entrada es el mensaje de error del inicio de sesión. Envíe un nombre de usuario que no existe y WordPress se lo devuelve impreso en la página. Ese reflejo debería ser inofensivo, y en el camino hay dos saneadores distintos. El bypass hallado por el equipo de pwn.ai aprovecha una discrepancia entre ambos: strip_tags() no considera etiqueta una construcción precedida por un espacio, de modo que una carga con la forma < area id=ajaxurl> pasa intacta, mientras que wp_kses_post() lee después esa misma cadena como HTML válido y la renderiza como un elemento real en la página.
Lo ingenioso es lo que hace ese elemento. No es un script. Es un nodo del DOM con nombre que choca con una variable de JavaScript que WordPress deja sin definir en esa pantalla, una técnica llamada DOM clobbering. Un script de administración del núcleo busca ajaxurl, encuentra el elemento del atacante en lugar de nada y dirige una petición hacia donde el atacante la apuntó. A partir de ahí la cadena recorre el propio código de confianza del sitio: un punto REST con soporte JSONP ejecuta el JavaScript del atacante en el origen del sitio, un truco de ejecución de métodos entre ventanas alcanza la sesión de un administrador conectado para aprobar un Application Password, y esa credencial concede acceso REST autenticado.
El último paso no necesita ningún fallo exótico. El Application Password robado lleva privilegios de administrador, así que el atacante simplemente usa la API para subir un plugin: un archivo ZIP con PHP dentro. En una instalación de un solo sitio, el administrador además tiene por defecto derecho a HTML sin filtrar, y eso es lo que hace posible el paso intermedio de publicar una página llena de JavaScript. Llegados a ese punto, el código ya no está en el navegador. Se ejecuta con los privilegios del proceso PHP, al lado de las credenciales de la base de datos.
Qué necesita realmente un atacante
Aquí es donde el titular y la realidad se separan. La mitad de cross-site scripting no requiere de verdad ni cuenta ni contraseña, y por eso el fallo es previo a la autenticación. La mitad de ejecución remota de código no se dispara sola. Un administrador tiene que estar conectado al sitio objetivo y tiene que abrir un enlace controlado por el atacante. No aparece ningún aviso, no se pide confirmación y la víctima no ve nada raro, pero la visita tiene que ocurrir.
En la práctica el listón es bajo. Los administradores de sitios pinchan enlaces en tickets de soporte, formularios de contacto, avisos de comentarios y correos de proveedores durante todo el día, a menudo en la misma sesión del navegador donde tienen abierto el panel. Leer "requiere interacción del usuario" como un consuelo es exactamente la vía por la que una cadena así se queda sin parchear durante un mes.
Qué versiones están afectadas
Son vulnerables todas las versiones de WordPress desde la 4.7 hasta la 7.0.2 incluida. Esa rama salió en diciembre de 2016, por eso el rango afectado cubre prácticamente cualquier instalación que siga recibiendo actualizaciones. WordPress publicó el mismo día correcciones para todo el árbol soportado, desde la 7.0.3 pasando por 6.9.6 y 6.8.7 y hasta la 4.7.34. Todo lo que corra en 4.6 o anterior no recibe ninguna actualización de seguridad y debe tratarse como permanentemente expuesto.
XSS2Shell fue uno de los doce problemas cerrados en esa versión. Entre los demás hay cross-site scripting almacenado en los bloques Post Date y Post Content, en los ajustes de emojis y en la edición rápida, una filtración de información que exponía comentarios de entradas protegidas con contraseña, un salto del flujo de confirmación de correo, una inyección de CSS a través del filtro de atributos seguros, una escalada de privilegios en redes multisitio con registro abierto, una falsificación de peticiones del lado del servidor en la validación de URL que alcanzaba rangos link-local, y una enumeración de slugs de entradas. Incluso sin la cadena principal, esa lista ya es motivo para actualizar hoy.
Qué hacer ahora
- Actualizar de inmediato: pasar a la 7.0.3 o a la versión parcheada de su rama. Las actualizaciones automáticas en segundo plano instalan por defecto las versiones menores de seguridad, pero confirme el número en lugar de darlo por hecho.
- Auditar los Application Passwords: abrir cada perfil de administrador y revocar toda credencial que no reconozca. Ese es el rastro que deja la cadena, y sobrevive a un cambio de contraseña.
- Revisar usuarios, plugins y archivos: buscar cuentas de administrador que usted no creó y plugins que aparecieron sin la entrada correspondiente en su propio historial de cambios.
- No abrir el panel desde cualquier sitio: mantener la sesión de administración en un perfil de navegador distinto del que usa para el correo y los tickets elimina justo la condición de la que depende este ataque.
- Restringir la pantalla de acceso: el reflejo vive en wp-login.php. Limitar quién puede llegar hasta ella, por lista de IP permitidas, autenticación HTTP o regla de cortafuegos, reduce la superficie para el próximo fallo en ese mismo archivo.
Por qué importa más allá de los dueños de sitios
Una instalación de WordPress comprometida rara vez es el objetivo del atacante. Es un vehículo de reparto, y el tráfico que sirve genera confianza precisamente porque el dominio es legítimo. Vimos el mismo patrón cuando un script publicitario empezó a reescribir direcciones de monederos cripto en miles de webs corrientes, y la misma idea está detrás de los ataques a nivel de navegador que cabalgan sobre una sesión autenticada que la víctima ya tiene abierta. Para un lector, y no un administrador, la defensa práctica está en la capa de red: el filtrado DNS y las listas de bloqueo impiden que se cargue la carga de segunda etapa aunque el sitio que la sirve sea uno que visita desde hace años. Es un argumento directo a favor de las herramientas de privacidad que bloquean en el momento de la resolución, y conviene decir con franqueza que ninguna de ellas parchea su propio servidor. Eso solo lo hace la actualización.
