WordPress 7.1.3 corrige siete fallos de seguridad: a quién afectan y cómo actualizar
WordPress publicó el 6 de octubre de 2026 la versión 7.1.3, una actualización de mantenimiento y seguridad que corrige siete fallos de seguridad y cuatro errores. Esta vez el aviso no habla de ningún fallo crítico como el de la 7.1.2, pero dos de los siete se pueden aprovechar sin tener cuenta en la web, y los dos tienen que ver con los comentarios. El equipo de WordPress recomienda actualizar de inmediato.
Es la tercera actualización de seguridad en menos de tres semanas, después de la 7.1.1 y la 7.1.2. Tres de los siete fallos los avisó Anthropic, la empresa que desarrolla la IA Claude, que ya había avisado de otro en la 7.1.1.
Los dos fallos que se pueden aprovechar sin cuenta
Un comentario trampa en la bandeja de moderación. Con la configuración que trae WordPress de serie, el primer comentario de un visitante se queda pendiente de aprobación, así que cualquiera puede dejar uno sin registrarse. Ese comentario podía llevar un enlace preparado que, si un editor o un administrador lo pulsaba desde la pantalla de Comentarios del panel, ejecutaba código del atacante en su navegador. En la jerga, un cross-site scripting (XSS) almacenado, y en la sesión de un administrador ese código puede actuar con sus permisos. Lo descubrió Thomas Chauchefoin, de Trail of Bits. Según Patchstack, esta vía solo funciona de la 7.1.0 a la 7.1.2, porque antes los comentarios de los visitantes no podían llevar el atributo que la hace posible.
Comentarios de entradas privadas a la vista. Cada entrada tiene su propio feed de comentarios, una dirección pensada para los lectores RSS. WordPress cargaba esos comentarios antes de comprobar si el visitante podía ver la entrada; después ocultaba la entrada, pero no sus comentarios, y como un feed nunca da error 404, los mostraba igualmente. Así, cualquiera podía leer los comentarios aprobados de entradas privadas o sin publicar. Lo avisó Ananda Dhakal, de Patchstack.
Los otros cinco necesitan una cuenta o un plugin
- Un Autor podía fijar entradas en la portada. Fijar está reservado a editores y administradores, pero la comprobación de la API REST tenía un «y» donde tocaba un «o», y cualquiera con rol de Autor se la saltaba. Lo avisó Anthropic.
- Bloquear la web con una dirección. La función que convierte direcciones relativas en completas,
WP_Http::make_absolute_url(), entraba en un bucle sin fin con ciertas rutas. Según Patchstack, un usuario con rol de Colaborador podía provocarlo desde la vista previa de enlaces del editor de bloques. Es una denegación de servicio (DoS). Lo avisó Anthropic. - Inyección SQL al exportar. Al exportar contenido desde Herramientas → Exportar, WordPress metía en la consulta a la base de datos los números de las imágenes destacadas sin comprobar que fueran números. Se llama de «segundo orden» porque el valor manipulado tiene que estar guardado de antes y salta más tarde, cuando un administrador exporta un solo tipo de contenido (no con la opción «Todo el contenido»). Afecta desde la 6.5. Lo avisó Anthropic.
- XSS en las imágenes incrustadas de Imgur. WordPress trataba Imgur como un servicio de confianza y no filtraba lo que devolvía al incrustar una imagen, aunque esa respuesta incluía texto escrito por quien la subió. Un Colaborador podía aprovecharlo con una entrada. Ahora pasa por el mismo filtro que el resto de servicios. Patchstack avisa de que el parche no borra lo que ya estaba guardado en caché y recomienda vaciar la caché de la web después de actualizar. Lo avisaron Zhengyu Liu, Jingcheng Yang y Gavin Zhong.
- Avisos internos que se hacían pasar por otros. Cuando una entrada cambia de estado, WordPress lanza un aviso interno (un hook) con el estado y el tipo en el nombre, como
publish_post. Si un plugin le pasaba esos datos sin filtrar, una entrada guardada con el estado «delete» lanzabadelete_post, el mismo aviso que un borrado de verdad, y todo lo que estuviera enganchado a él se ponía en marcha. Ahora solo se lanzan con estados y tipos registrados. Lo avisó Alex Concha, del equipo de seguridad de WordPress.
Ni el aviso oficial ni los análisis publicados hablan de ataques reales. Patchstack lo resume así: hay que actualizar en cuanto se pueda, pero no es una emergencia como para dejarlo todo.
Cómo actualizar
- Mira primero qué versión tienes en Escritorio → Actualizaciones. Arriba del todo pone «Versión actual»: si dice 7.1.3, ya está.
- Lo normal es que ya se haya instalado sola. Si en esa pantalla aparece «Este sitio se mantiene al día automáticamente solo con las versiones de mantenimiento y seguridad de WordPress», WordPress instala estas correcciones por su cuenta, en segundo plano.
- Si no, haz una copia de seguridad o comprueba que tu alojamiento tenga una reciente, y pulsa Actualizar ahora.
- Comprueba después tres cosas: que la portada carga, que un artículo se ve bien y que el editor de entradas abre sin errores.
Si tu web sigue en una rama anterior, no hace falta que saltes a la 7.1: WordPress ha publicado las correcciones también para las ramas antiguas. Estas son las de los últimos años:
| Si tu web está en la rama… | Actualiza a… |
|---|---|
| 7.1 | 7.1.3 |
| 7.0 | 7.0.7 |
| 6.9 | 6.9.10 |
| 6.8 | 6.8.11 |
| 6.7 | 6.7.10 |
| 6.6 | 6.6.10 |
| 6.5 | 6.5.13 |
Eso sí, WordPress recuerda que solo la versión más reciente tiene soporte activo: el parche para las ramas antiguas es una cortesía. Si tu web lleva años sin salir de una de ellas, tienes el paso a paso para ponerla al día en la guía que escribimos con la vulnerabilidad wp2shell.
Si no puedes actualizar ahora mismo
- No pulses enlaces de comentarios pendientes desde la pantalla de Comentarios. Apruébalos, mándalos a spam o a la papelera sin abrir lo que enlazan.
- Repasa quién tiene cuenta en Usuarios → Todos los usuarios. Patchstack aconseja revisar quién tiene rol de Colaborador o superior, porque varios de estos fallos dependen de lo que pueden hacer esos roles. Quita las cuentas que ya no se usen. Esto conviene hacerlo también después de actualizar.
Raiola Networks, hosting para WordPress
Esta web está alojada en Raiola desde julio de 2026: empecé contratando un solo mes para probar, y me quedé. Lo que más valoro es que se esfuerzan en ayudar a sus clientes: tienen un canal de YouTube con cientos de tutoriales, organizan webinars de vez en cuando (el último, sobre cómo posicionarte en Google) y ahora mismo estoy haciendo su curso de cPanel. Un consejo de lo que aprendí: si lo tienes claro, contrata en pago anual y con el dominio incluido desde el principio. Pagar mes a mes sale más caro al año, y pasarse a anual después no tiene descuento.
Ver los planes de hosting de Raiola Enlace de afiliado: si contratas a través de él, bandaanchatech.com recibe una comisión sin coste adicional para ti. Recomiendo Raiola porque es donde tengo alojada esta web.