El martes WordPress sacó la 7.0.3 como actualización de seguridad. Doce vulnerabilidades corregidas de golpe, una de ellas en la pantalla de login sin necesidad de autenticación previa. Si gestionas webs en WordPress —y en ticweb.es llevamos años viendo lo mismo— ya sabes que cuando el core publica un parche así, no es para quedarse mirando el changelog.
Lo que me ha llamado la atención no es solo el parche en sí. Es quién ha encontrado los fallos y el contexto en el que llegan. Semanas después de que la comunidad hablara del WP2Shell y de que los laboratorios de IA se pusieran a demostrar que pueden auditar código a escala, WordPress 7.0.3 aparece con informes de Anthropic, Pwn AI, Aikido Security y otros. Coincidencia temporal, quizá. Pero el mensaje de fondo me parece claro: el escrutinio al core de WordPress ya no lo hacen solo los investigadores de siempre.
La más delicada, según el propio advisory de GitHub (GHSA-52p2-r8wf-jcrf), es un XSS reflejado pre-autenticación en la pantalla de acceso. Un atacante puede montar una web maliciosa que, con ingeniería social y la interacción explícita de la víctima, escale el ataque hasta ejecución remota de código PHP. WordPress lo califica como posible bajo condiciones que no controla el atacante. Traducción para quien administra sitios: no es un exploit masivo tipo WP2Shell, pero tampoco es un detalle menor que puedas ignorar porque «solo afecta al login».
En mi experiencia, la pantalla de login es uno de esos sitios que todo el mundo da por cerrado. Le pones limitación de intentos, quizá 2FA si el cliente paga bien, y sigues. Un XSS ahí, sin necesidad de credenciales, cambia la ecuación porque cualquier administrador que caiga en un enlace trampa mientras tiene sesión abierta en otra pestaña puede regalarte la puerta de entrada. No hace falta fuerza bruta ni diccionarios.
WordPress ha backportado el arreglo hasta la rama 4.7, lo cual es un gesto de cortesía hacia instalaciones antiguas pero también una señal incómoda: el fallo afecta a todas las versiones. Si tienes clientes con WordPress 5.x o 6.x que nunca han actualizado porque «funciona y no tocamos nada», este parche es exactamente el tipo de cosa que explota alguien con tiempo y un enlace bien construido.
Lo que no me cuadra del todo es el relato tranquilizador que suele acompañar estos releases. Automattic y la comunidad repiten que las actualizaciones automáticas en background cubren a la mayoría. Bien. Pero yo sigo viendo en hosting compartido —incluido el nuestro— sitios con auto-update desactivado porque un plugin de hace tres años petaba con cada minor. Esos sitios no están en el informe de «millones de instalaciones protegidas». Están en la cola de «lo miramos el mes que viene».
Search Engine Journal recoge el comentario de Oliver Sild, de Patchstack, señalando que la vulnerabilidad más fea es precisamente la del login y que, afortunadamente, ninguna de las doce es explotable en masa como WP2Shell. Me parece un matiz honesto. Pero también recuerda que los clientes de Patchstack recibieron reglas de mitigación en el momento del disclosure. Si no pagas un WAF o un servicio de parcheo virtual, tu única defensa real sigue siendo actualizar el core. No hay magia intermedia.
Otro detalle: WordPress 7.1 RC2 ya incluye estos arreglos. La 7.1 final sale el 19 de agosto, en pleno WordCamp US. El timing no es casual. Automattic quiere llegar al escenario con un core limpio de cara a anunciar Icons API, @mentions en notas y el resto de novedades. Entiendo la estrategia de producto. Lo que me preocupa es que muchos administradores mezclen en la cabeza «nueva versión con features chulas» y «parche de seguridad urgente». Son cosas distintas. La 7.0.3 no te trae estilos responsive nativos ni procesado de medios en el navegador; te trae doce parches. Punto.
Si gestionas varias instalaciones, esto es lo que yo haría hoy mismo:
- Comprobar en cada sitio la versión activa. Dashboard → Actualizaciones, o
wp core versionsi prefieres SSH. - Actualizar a 7.0.3 aunque estés en una rama antigua: el backport cubre hasta 4.7, pero la rama soportada activamente es solo la última.
- Revisar plugins de seguridad y caché: a veces bloquean el proceso de actualización y dejan el core a medias.
- Documentar qué sitios no se han actualizado y por qué. «El cliente no quiere» no es excusa válida ante un XSS pre-auth; es una decisión de riesgo que debería constar por escrito.
También aprovecharía para revisar quién tiene acceso de administrador real. Un XSS en login no necesita que el atacante conozca tu contraseña; necesita que alguien con privilegios haga clic donde no debe. Menos admins, sesiones más cortas, 2FA obligatorio en cuentas con capacidad de instalar plugins. Suena básico, lo es, y sigue sin aplicarse en la mitad de las pymes que conozco.
El ecosistema WordPress lleva décadas demostrando que la superficie de ataque es enorme y que el core, los plugins y los temas se retroalimentan. Que ahora los hallazgos lleguen también desde laboratorios de IA no empeora el problema; lo hace más visible. La pregunta no es si habrá más parches de este calibre antes de fin de año —los habrá— sino cuántos sitios los tendrán instalados antes de que alguien monte la cadena de explotación completa del XSS del login.
Si tu proveedor de hosting te garantiza que «todos los WordPress están actualizados» pero no te enseña un informe por dominio con fecha y versión, ¿le creerías a ciegas o pedirías acceso al panel para comprobarlo tú mismo?