WordPress 7.1.4, publicada el 28/10/2026, es una versión de seguridad que corrige 12 vulnerabilidades y actualiza los certificados raíz incluidos en el núcleo, y el proyecto recomienda instalarla de inmediato. El fallo más delicado es una debilidad en el proceso de actualización que puede derivar en ejecución remota de código mientras se actualiza el sitio. El resto son, sobre todo, problemas de XSS almacenado en bloques, en la Interactivity API y en el personalizador.
Las claves de WordPress 7.1.4 en 30 segundos
La versión la han coordinado Aaron Jorbin y Nik Tsekouras, y es la cuarta de seguridad de la rama 7.1 desde mediados de septiembre. Antes llegaron WordPress 7.1.1, con 11 correcciones de seguridad, WordPress 7.1.2, que cerró una vulnerabilidad crítica de ejecución remota de código, y WordPress 7.1.3, que corrigió siete vulnerabilidades hace tres semanas. Junto a la 7.1.4 se ha publicado también WordPress 7.2 Beta 3, que ya incorpora las correcciones aplicables.
El anuncio oficial enumera los problemas y quién los comunicó, pero no asigna una gravedad a cada uno ni explica cómo se explotan:
| Vulnerabilidad | Comunicada por |
|---|---|
| Debilidad en el proceso de actualización que puede permitir ejecución remota de código durante la ventana de actualización | Umut Bayram |
| XSS almacenado mediante marcado de bloques manipulado | Rafie Muhammad (Awesome Motive) |
| XSS almacenado a través de solicitudes de borrado de datos personales | Anthropic |
| Varios XSS almacenados en la Interactivity API | AnC y DatNLQ (VietSunshine Cyber Security), rekter0 y Anas cherni, Marcel Karlsson, y Weston Ruter, Jon Surrell, Alex Concha y Luis Herranz (equipo de seguridad de WordPress) |
| Denegación de servicio almacenada en la Interactivity API | Jon Surrell (equipo de seguridad de WordPress) |
| XSS almacenado en el refresco selectivo del personalizador | Rafie Muhammad (Awesome Motive) |
| XSS almacenado en el bloque Categorías | Ben Bidner (equipo de seguridad de WordPress) |
| XSS almacenado mediante nombres de usuario manipulados | Anthropic |
| Cambios del personalizador sin publicar visibles para usuarios sin sesión | Antonio Lorensius Silaban |
| XSS almacenado en los bloques Lista de reproducción e Imagen | Ben Bidner (equipo de seguridad de WordPress) |
| XSS almacenado en los bloques de paginación de comentarios (siguiente y anterior) | Alex Concha (equipo de seguridad de WordPress) |
| Usuarios con privilegios pueden leer notas de entradas que no pueden editar | Ramon (equipo de seguridad de WordPress) |
La lista tiene 12 entradas, pero algunas agrupan varios fallos, como la de la Interactivity API, que reconoce a cuatro grupos de investigadores que los encontraron por separado. Por eso la página de documentación de la versión habla de 22 vulnerabilidades. Esa misma página recoge 32 ficheros modificados, entre ellos class-wp-upgrader.php, kses.php, class-wp-block-parser.php, la clase de la Interactivity API y los ficheros de varios bloques, y no menciona correcciones de errores ajenas a la seguridad.
El anuncio no da detalles técnicos, pero el problema del proceso de actualización es el que tiene más alcance sobre el papel: según WordPress, puede llevar a ejecutar código de forma remota durante el tiempo en que el sitio se está actualizando. Es una ventana corta, aunque se repite en cada actualización del núcleo, los plugins o los temas. El cambio en class-wp-upgrader.php y en update-core.php apunta a esa parte del código.
Los XSS almacenados son el otro bloque grande. En este tipo de fallo, alguien con capacidad para guardar contenido, ya sea un bloque, un nombre de usuario o una solicitud de borrado de datos, deja un código que se ejecuta después en el navegador de quien lo ve, a menudo un administrador. La versión también cierra una fuga de información: los cambios del personalizador que aún no se han publicado podían descubrirlos visitantes sin sesión iniciada.
Además, WordPress actualiza el paquete de certificados raíz que incluye el núcleo por la revocación de la autoridad de certificación eMudhra. Ni el anuncio ni la documentación precisan más sobre ese cambio. Como en la 7.1.3, dos de los fallos aparecen comunicados por Anthropic, la empresa que desarrolla los modelos Claude, sin nombre de investigador ni detalle del método utilizado.
Los sitios con actualizaciones automáticas en segundo plano, que es la opción por defecto para las versiones menores, empezarán a actualizarse solos. En el resto hay que ir a Escritorio > Actualizaciones y pulsar «Actualizar ahora», o descargar el paquete desde WordPress.org. Conviene tener una copia de seguridad reciente y comprobar después que los plugins importantes siguen funcionando. Quien gestione muchas webs puede comprobar el resultado con las herramientas de administración centralizada que use habitualmente.
Las correcciones se han trasladado como cortesía a todas las ramas que siguen recibiendo parches de seguridad, que hoy llegan hasta la 4.7, aunque esas versiones saldrán a medida que estén listas. WordPress recuerda que solo la versión más reciente tiene soporte activo. La rama 7.1 tendrá un recorrido corto: el proyecto prevé publicar WordPress 7.2 el 8 de diciembre, con Ipsum como nuevo tema por defecto.
Doce vulnerabilidades de seguridad, entre ellas un riesgo de ejecución remota de código durante las actualizaciones y varios XSS almacenados, y actualiza los certificados raíz incluidos en el núcleo.
Sí. Es una versión de seguridad y WordPress recomienda actualizar los sitios de inmediato.
En los sitios con actualizaciones automáticas en segundo plano, sí. En los demás hay que hacerlo desde Escritorio > Actualizaciones.
Está prevista para el 8 de diciembre. Ya está disponible la Beta 3, que incluye las correcciones de la 7.1.4 que le afectan.
Fuentes:
