WordPress 7.1.4 corrige un fallo en la actualización del núcleo

WordPress 7.1.4 corrige el fallo de seguridad detectado en el proceso de actualización del núcleo, pero actualizar no sustituye la protección de la carpeta temporal en el servidor. Si utilizas una versión anterior, debes comprobar que tienes instalada la corrección correspondiente a tu rama y que wp-content/upgrade/ no es accesible públicamente.

La actualización se publicó el 28 de octubre de 2026, según WordPress.org. Incluye correcciones para 22 vulnerabilidades agrupadas en 17 avisos, de acuerdo con el análisis de Patchstack.

Cómo comprobar qué versión de WordPress tienes instalada

Entra en el panel de administración y abre Escritorio > Actualizaciones. Comprueba la versión instalada, no únicamente si aparece un aviso de actualización disponible.

WordPress.org permite actualizar desde ese apartado o descargar el paquete correspondiente. Algunas instalaciones admiten actualizaciones automáticas en segundo plano, pero eso no demuestra que la corrección ya esté aplicada en tu web.

Si administras varias instalaciones, revísalas por separado. Una tienda, un blog corporativo y una web de pruebas pueden encontrarse en versiones distintas aunque compartan proveedor de alojamiento.

Esta tabla permite decidir qué revisar antes de dar por terminado el mantenimiento:

Cada rama tiene una versión de seguridad diferente

No todas las instalaciones necesitan mostrar exactamente 7.1.4.

El aviso oficial de seguridad de WordPress en GitHub identifica las versiones afectadas desde 4.7.0 hasta 7.1.3, con correcciones distribuidas entre las distintas ramas.

Las versiones corregidas incluyen:

• 7.1.4 para la rama 7.1.
• 7.0.8 para la rama 7.0.
• 6.9.11 para la rama 6.9.
• 6.8.12 para la rama 6.8.
• 4.7.39 para la rama 4.7.

Existen también correcciones intermedias para las demás ramas. Por eso, antes de considerar segura una instalación antigua, conviene consultar la relación completa del aviso oficial.

WordPress 4.6 y las versiones anteriores no reciben esta corrección, según Patchstack. En esos casos, la decisión adecuada es preparar la migración a una rama corregida, revisando previamente la compatibilidad de la web.

Mantener un registro de versiones y fechas de soporte ayuda a evitar estas situaciones. Puedes relacionar esta revisión con nuestro artículo sobre el calendario de soporte del stack tecnológico.

El fallo aprovechaba los archivos temporales de actualización

Durante una actualización completa del núcleo, WordPress extraía archivos en un directorio predecible dentro de wp-content/upgrade/.

Si ese directorio era accesible desde Internet, alguien sin cuenta de usuario podía intentar acceder a los archivos mientras se extraían. Si conseguía aprovechar ese breve intervalo, podía llegar a ejecutar código en el servidor.

Así lo describe el aviso de seguridad publicado por WordPress.

La explotación requiere condiciones específicas: que se esté realizando una actualización completa, que la ruta sea accesible y que la petición coincida con una ventana de apenas segundos.

WordPress clasifica el fallo con severidad baja, mientras que Patchstack destaca su elevada complejidad de explotación. Aun así, la posibilidad de ejecución remota justifica corregirlo.

La versión también soluciona varios problemas de XSS almacenado relacionados con bloques, Customizer, eliminación de datos personales e Interactivity API, además de una denegación de servicio almacenada en esta última, según WordPress.org.

Bloquea wp-content/upgrade/ directamente en Apache o Nginx

Esta es la comprobación que conviene hacer incluso después de actualizar.

La recomendación de Patchstack y Rescana es impedir que el servidor web entregue públicamente los archivos de wp-content/upgrade/.

En Apache, la restricción debe aplicarse mediante su configuración de acceso. En Nginx, mediante una regla equivalente que deniegue las solicitudes dirigidas a esa ruta.

El objetivo es bloquear las peticiones web, no impedir que WordPress utilice internamente la carpeta durante sus actualizaciones.

Después de aplicar la configuración, comprueba que la ruta no permite listar archivos y que tampoco pueden servirse directamente contenidos de su interior. Desactivar únicamente el listado no equivale a bloquear el acceso.

Hay otro detalle importante: un cortafuegos implementado en PHP no basta para proteger esta ruta.

Si tu alojamiento no permite modificar Apache o Nginx, solicita al proveedor que aplique y verifique la restricción.

Qué revisar antes de cerrar el mantenimiento

En una web comercial conviene comprobar que la actualización ha terminado, confirmar la versión instalada y verificar el bloqueo desde fuera del servidor.

Si utilizas plugins o desarrollos que dependen de PHP, aprovecha la revisión para comprobar también el entorno. Nuestro artículo sobre cómo actualizar PHP en WordPress ante problemas de seguridad permite abordar esa parte por separado.

Documenta la versión instalada, la configuración de acceso aplicada y quién puede revisarla. Para organizar la comunicación de problemas detectados, también puedes consultar el artículo sobre notificación de vulnerabilidades y Cyber Resilience Act.

Esta semana, comprueba la versión real de cada WordPress y pide verificar el bloqueo de wp-content/upgrade/ en el servidor. Si necesitas revisar una web o tienda antes de actualizarla, cuéntanos qué instalación tienes y qué necesitas comprobar en Contrast 3D.