WordPress 7.1.4 corrige un fallo durante la actualización: confirma que el parche llegó a cada sitio

WordPress publicó la versión 7.1.4 el 28 de octubre de 2026 con correcciones de seguridad, entre ellas la de una debilidad que puede permitir la ejecución remota de código durante el periodo de actualización. El anuncio de la versión recomienda actualizar de inmediato. Para quienes gestionan varios sitios, la primera tarea es determinar qué instalaciones han recibido realmente la corrección.

Según WordPress, los sitios compatibles con las actualizaciones automáticas en segundo plano inician el proceso automáticamente. Eso describe cómo comienza una actualización, no confirma que haya terminado en todos los servidores. Una opción activada, una lista de mantenimiento antigua o la política general de un proveedor de alojamiento no sustituyen la comprobación de la versión instalada.

El proceso de actualización forma parte de la corrección

El anuncio atribuye a Umut Bayram la comunicación de la debilidad del proceso de actualización. También enumera problemas de secuencias de comandos entre sitios almacenadas, o XSS almacenado, que afectan a áreas como la Interactivity API, la actualización selectiva del Personalizador y las solicitudes de eliminación de datos personales, además de un problema de denegación de servicio almacenada. Los certificados raíz incluidos se actualizan debido a la revocación de eMudhra.

Otras correcciones abordan el descubrimiento sin autenticación de conjuntos de cambios del Personalizador todavía no publicados y el acceso a notas de entradas por usuarios con privilegios que no pueden editar la entrada asociada. Son problemas distintos de permisos y exposición. El anuncio no establece que un sitio concreto haya sufrido un ataque ni que todas las vulnerabilidades tengan las mismas condiciones de explotación.

La documentación de la versión añade detalles sobre los componentes y permisos afectados. Resulta útil para el administrador que evalúa una instalación concreta. Para el propietario que decide si actuar, la recomendación de actualizar inmediatamente ya es clara; el fallo durante la actualización no es un motivo para posponer la reparación.

Verifica que terminó y comprueba que el sitio funciona

Abre el Escritorio de cada sitio, elige Actualizaciones y consulta la versión actual. Para la rama estable vigente, el objetivo de esta publicación es 7.1.4. Si la actualización sigue disponible, utiliza Actualizar ahora o coordina la instalación con quien gestione el alojamiento. Vuelve a abrir la pantalla al terminar y registra la versión resultante.

Las instrucciones de actualización de WordPress recomiendan hacer primero una copia de seguridad y explican que los fallos de la actualización con un clic pueden deberse a permisos del sistema de archivos. Un registro de mantenimiento útil debe incluir el sitio, la versión instalada, la ubicación de la copia, el resultado y cualquier error pendiente. Una actualización fallida pertenece a la lista de trabajo activo, no a la columna de tareas terminadas.

Tras actualizar, comprueba un artículo público, el acceso de administración y una acción esencial de publicación. Estas comprobaciones permiten saber si el sitio sigue siendo utilizable; no constituyen una auditoría de seguridad. Utiliza un plan preparado de pruebas y reversión y asegúrate de que las comprobaciones de copia y restauración cubren una recuperación que puedas ejecutar de verdad.

Las ramas antiguas necesitan una versión exacta, no tranquilidad genérica

El anuncio indica que los parches de seguridad llegan hasta la rama 4.7 y que todavía se estaban distribuyendo. La documentación de la versión ya enumera publicaciones antiguas corregidas, incluida 4.7.39, y afirma que 4.6 y las anteriores ya no reciben actualizaciones de seguridad. Solo la versión más reciente de WordPress tiene soporte activo. Comprueba el parche correspondiente a la rama que está instalada; la existencia de adaptaciones no convierte todas las instalaciones antiguas en seguras.

Si un sitio no puede actualizarse hoy, contacta con el proveedor de alojamiento o el responsable de mantenimiento e indica la versión y el error que lo impide, asigna una persona responsable y fija un plazo concreto de recuperación o actualización. Solicita una evaluación de contención específica para el sitio mientras se organiza la reparación. No consideres una copia de seguridad, un cortafuegos o una promesa de actualizar más tarde como prueba de que esas vulnerabilidades están corregidas.

El mismo anuncio dice que 7.2 Beta 3 contiene las correcciones aplicables y sitúa la fecha prevista de publicación de 7.2 en el 8 de diciembre. El archivo de versiones distingue las pruebas beta de las versiones de producción. Una futura versión principal no es motivo para dejar pendiente una actualización de seguridad actual.