WordPress 7.1.4 corrige 22 vulnerabilidades y una falla que podía terminar en ejecución remota de código

WordPress publicó el 28 de octubre de 2026 la versión 7.1.4 y esta vez no estamos frente a una actualización que convenga dejar esperando varios días solamente porque nuestro sitio parece funcionar perfectamente.

WordPress 7.1.4 es una actualización de seguridad y el propio proyecto recomienda instalarla inmediatamente. Entre las correcciones encontramos diferentes vulnerabilidades XSS, problemas de permisos, exposición de información que todavía no había sido publicada y una condición especialmente interesante dentro del proceso de actualización del núcleo que, bajo determinadas circunstancias, podía terminar en ejecución remota de código.

La documentación oficial permite además dimensionar el alcance de esta actualización, WordPress 7.0 y 6.9 estaban afectados por las 22 vulnerabilidades contabilizadas, mientras ramas anteriores recibieron las correcciones que les correspondían de acuerdo con los problemas que también estaban presentes en ellas.

Eso tampoco significa que cualquier página con una versión anterior pueda ser tomada remotamente con sólo conocer su dirección, porque varias de las vulnerabilidades necesitan determinados permisos, configuraciones o condiciones para ser explotadas. Entender esa diferencia es importante para no transformar una actualización seria en un titular apocalíptico.

Cuando WordPress utiliza la palabra seguridad, la actualización deja de ser solamente una cuestión de mantenimiento

WordPress recibe actualizaciones constantemente y no todas tienen la misma importancia.

Algunas solucionan errores visuales, problemas de compatibilidad o comportamientos inesperados que podemos corregir tranquilamente dentro del ciclo habitual de mantenimiento de una página.

WordPress 7.1.4 pertenece a otra categoría.

El equipo de WordPress la publicó específicamente como una versión de seguridad y recomienda actualizar los sitios inmediatamente.

La actualización incluye correcciones en diferentes áreas del núcleo, entre ellas procesamiento de bloques, Interactivity API, Customizer, pantallas de usuarios, solicitudes relacionadas con privacidad, permisos y el propio sistema que WordPress utiliza para actualizarse.

La corrección que más llama la atención está dentro del propio proceso de actualización de WordPress

Entre todos los problemas publicados hay uno que inevitablemente sobresale porque el resultado potencial es especialmente serio.

WordPress corrigió una condición de carrera durante las actualizaciones del núcleo que podía conducir a ejecución remota de código durante la ventana en la que WordPress estaba siendo actualizado.

Ejecución remota de código, habitualmente abreviada como RCE, significa que bajo determinadas condiciones un atacante puede conseguir que un servidor ejecute instrucciones que él controla.

Es uno de los resultados que más preocupan cuando hablamos de seguridad web porque el problema deja de limitarse a mostrar contenido no deseado o acceder a información y puede avanzar hacia la ejecución de acciones dentro del servidor.

Esa diferencia es importante porque un titular como “WordPress permite ejecución remota de código” sería técnicamente mucho más amplio de lo que describe la vulnerabilidad publicada.

Lo curioso es que el momento vulnerable podía aparecer justamente mientras WordPress se estaba protegiendo

Una condición de carrera ocurre cuando dos procesos o acciones coinciden de una manera que el sistema no esperaba y el resultado depende del orden exacto en que consiguen ejecutarse.

En este caso el problema estaba relacionado con el mecanismo utilizado por WordPress durante una actualización del propio núcleo.

Eso genera una situación particularmente interesante, la página podía encontrarse instalando una nueva versión para quedar protegida mientras, durante un intervalo determinado de ese mismo proceso, existía una condición que potencialmente podía aprovecharse para ejecutar código.

WordPress 7.1.4 endurece este comportamiento y cierra esa posibilidad.

Buena parte de las correcciones están relacionadas con XSS almacenado

Otra expresión que aparece repetidamente en la documentación de WordPress 7.1.4 es stored XSS o XSS almacenado.

Explicado sin convertir esto en una clase de programación, un XSS permite introducir contenido que el navegador puede terminar interpretando como código cuando otra persona visita una pantalla o página determinada.

Cuando además hablamos de XSS almacenado, ese contenido malicioso puede quedar guardado dentro de WordPress y ejecutarse posteriormente cuando otro usuario accede al lugar donde aparece.

WordPress 7.1.4 corrige diferentes variantes relacionadas con:

Varias de estas vulnerabilidades requieren que el atacante ya cuente con determinados permisos dentro del sitio, por ejemplo un usuario con rol Contributor, Author o Editor, por eso tampoco debemos interpretarlas como ataques completamente anónimos disponibles para cualquiera.

Pero en seguridad los permisos parciales también importan, especialmente en sitios con muchos usuarios, portales, medios, comunidades, tiendas o instalaciones donde diferentes personas pueden publicar y editar contenido.

La Interactivity API aparece varias veces y eso no significa que la tecnología sea insegura

Una parte importante de las correcciones está relacionada con la Interactivity API de WordPress.

Esta API permite crear comportamientos interactivos en los bloques sin que cada desarrollador tenga que inventar su propia solución desde cero, algo cada vez más importante dentro de la evolución del editor y de la experiencia de WordPress.

La versión 7.1.4 corrige diferentes escenarios relacionados con enlaces JavaScript, manejadores de eventos, contexto de la API, elementos que podían cargar páginas administrativas y situaciones capaces de producir XSS almacenado o incluso una denegación de servicio.

Que encontremos varias correcciones dentro de una misma tecnología tampoco debería interpretarse como prueba de que esa tecnología esté mal diseñada.

Cuando una plataforma incorpora mecanismos nuevos y cada vez más utilizados también aumenta la cantidad de investigadores que los analizan, aparecen escenarios límite y el código termina endureciéndose.

WordPress también podía revelar cambios del Customizer que todavía no habían sido publicados

Entre las vulnerabilidades encontramos un problema de divulgación de información que resulta fácil de entender incluso sin conocimientos técnicos.

Determinados changesets del Customizer que todavía no habían sido publicados podían ser descubiertos por visitantes sin autenticar.

Un changeset funciona como un conjunto de cambios que WordPress puede guardar antes de hacerlos públicos, por ejemplo mientras estamos preparando modificaciones dentro del personalizador.

Si esa información todavía no fue publicada, un visitante anónimo tampoco debería poder descubrirla.

WordPress 7.1.4 corrige esa exposición.

Otro grupo de correcciones vuelve sobre algo fundamental, quién puede ver y modificar cada cosa

WordPress funciona con un sistema de roles y capacidades que permite decidir qué puede hacer cada usuario.

Un administrador no tiene los mismos permisos que un editor, un autor o un colaborador, y los desarrollos personalizados pueden incluso crear roles propios.

WordPress 7.1.4 corrige un problema por el cual determinados roles personalizados con capacidad para moderar comentarios podían leer, editar o eliminar notas asociadas con publicaciones que esos mismos usuarios no tenían permiso para editar.

También se incorporaron endurecimientos relacionados con nombres de usuarios dentro de instalaciones Multisite.

Son problemas menos espectaculares que un RCE, pero forman parte de una regla esencial de seguridad, cada usuario debería acceder únicamente a aquello para lo que tiene autorización.

La actualización también modifica certificados raíz después de una revocación de eMudhra

No todas las modificaciones de WordPress 7.1.4 están relacionadas con vulnerabilidades dentro del código del CMS.

La versión también actualiza el conjunto de certificados raíz incluido con WordPress debido a una revocación relacionada con eMudhra.

Los certificados raíz forman parte de la cadena de confianza utilizada para verificar conexiones seguras con servicios externos.

Cuando una autoridad o un certificado deja de considerarse confiable, el software que mantiene una copia de esos certificados necesita actualizarla para evitar continuar confiando en algo que ya fue revocado.

Para el propietario de una página esto ocurre prácticamente de manera transparente, pero es otro ejemplo de todo aquello que se mantiene por debajo de la interfaz que vemos diariamente.

WordPress también publicó correcciones para muchas ramas anteriores

Una particularidad de esta actualización es la cantidad de versiones anteriores que recibieron backports de seguridad.

Un backport consiste en tomar una corrección desarrollada para una versión actual y adaptarla para una rama anterior que también estaba afectada.

Las correcciones continúan en ramas mucho más antiguas y WordPress llegó a publicar backports para versiones hasta 4.7.

Sin embargo, hay una aclaración oficial que no deberíamos pasar por alto, solamente la versión más reciente de WordPress se considera activamente soportada.

Que una rama antigua reciba por cortesía una corrección de seguridad puntual no convierte automáticamente a esa versión en una plataforma recomendable para mantener un proyecto moderno.

WordPress 4.6 y anteriores, además, ya no reciben estas actualizaciones de seguridad.

Actualizar rápido no significa actualizar sin mirar absolutamente nada

Cuando aparece una versión de seguridad nuestra recomendación es actualizar cuanto antes, pero eso tampoco significa trabajar sin ningún criterio.

En una instalación profesional comprobaríamos primero que exista una copia de seguridad reciente, verificaríamos el estado general del sitio y después instalaríamos WordPress 7.1.4.

En sitios que permiten actualizaciones automáticas en segundo plano, WordPress puede iniciar el proceso automáticamente.

Actualizar plugins y temas no reemplaza actualizar el núcleo

Otro punto que parece obvio pero genera bastante confusión es que cada capa de WordPress necesita su propio mantenimiento.

Podemos tener Elementor, WooCommerce, Yoast SEO y todos nuestros plugins completamente actualizados y seguir utilizando una versión vulnerable del núcleo de WordPress.

También puede ocurrir exactamente lo contrario, tener WordPress 7.1.4 instalado mientras un plugin antiguo conserva una vulnerabilidad propia.

Una actualización no reemplaza a la otra.

WordPress 7.1.4 será una versión de ciclo corto porque WordPress 7.2 ya está en desarrollo

WordPress 7.1.4 pertenece a lo que el proyecto denomina una versión de ciclo corto.

La próxima versión principal será WordPress 7.2 y, de acuerdo con el anuncio oficial de esta actualización, actualmente está prevista para el 8 de diciembre de 2026.

Eso tampoco es un motivo para esperar hasta diciembre y saltarnos 7.1.4.

Las versiones mayores incorporan nuevas funciones y cambios más grandes, mientras esta actualización existe precisamente para solucionar problemas de seguridad que ya conocemos hoy.

Preguntas frecuentes sobre WordPress 7.1.4

WordPress 7.1.4 vuelve a demostrar que actualizar no se trata solamente de conseguir funciones nuevas

Cuando pensamos en una actualización solemos imaginar un botón nuevo, cambios de diseño o alguna función que antes no existía.

Las actualizaciones de seguridad funcionan de otra manera.

La mayoría de las veces instalamos la nueva versión y visualmente no cambia absolutamente nada, nuestra página sigue mostrando el mismo diseño, los mismos textos y las mismas funciones que tenía cinco minutos antes.

Pero debajo de esa página aparentemente idéntica pueden haber desaparecido diferentes caminos que permitían ejecutar JavaScript no autorizado, acceder a información que todavía no debía ser pública, superar determinados límites de permisos o aprovechar una condición dentro del proceso de actualización.

WordPress 7.1.4 es precisamente una de esas versiones.

No necesitamos instalarla porque traiga algo espectacular que podamos mostrar en una captura, necesitamos instalarla porque corrige problemas que preferimos no tener que descubrir después de que alguien intente aprovecharlos.