Versión de seguridad WordPress 7.1.4: qué deben hacer hoy las agencias

Actualización, 5 de noviembre de 2026: Wordfence cuenta ya más de 240.000 intentos bloqueados contra este fallo desde el 28 de octubre, con un pico de más de 74.000 el 30 de octubre. CISA añadió CVE-2026-119977 a su catálogo Known Exploited Vulnerabilities el 2 de noviembre. Wordfence sigue considerando difícil un ataque con éxito en la práctica, porque solo funciona durante los segundos en que se ejecuta una actualización. Su consejo es el mismo que el nuestro: actualiza ahora a la 7.1.4 o al backport de tu rama, y bloquea los archivos PHP en wp-content/upgrade/ en el servidor web antes de actualizar. Los usuarios gratuitos de Wordfence reciben la regla del cortafuegos el 27 de noviembre. Fuente: Wordfence, 5 de noviembre de 2026.

Actualización, 31 de octubre de 2026: los ataques van en aumento. Wordfence informa ahora de casi 59.000 intentos bloqueados en 24 horas contra los archivos de instalación temporales en wp-content/upgrade/ (frente a 18.500 en las primeras 21 horas). Siguen sin confirmarse intrusiones. Si un sitio de cliente aún no está en la 7.1.4 o en el backport de su rama, actualízalo hoy y cierra la carpeta upgrade en el servidor; no esperes al lunes.

WordPress 7.1.4 salió el 28 de octubre de 2026 como versión de seguridad. Corrige 22 vulnerabilidades en 17 avisos, y las mismas correcciones se trasladaron a cada rama compatible hasta la 4.7.39. Una de ellas es inusual: un fallo en el propio proceso de actualización del núcleo que no requiere iniciar sesión. Es difícil de explotar, pero los atacantes empezaron a buscarlo en menos de un día, y es el único problema de esta versión que un cortafuegos en forma de plugin no puede detener. Esto es lo que significa para los sitios de clientes que mantienes y lo que debes hacer hoy.

Qué se corrige

• Ejecución de código sin iniciar sesión durante una actualización. Antes de la 7.1.4, la carpeta donde WordPress descomprime las actualizaciones, dentro de wp-content/upgrade/, tenía un nombre previsible, y la limpieza eliminaba el index.php que bloquea el listado del directorio. Un atacante que acierte en los pocos segundos en que se ejecuta una actualización, en un sitio donde esa carpeta es accesible desde la web, podía ejecutar código. Patchstack califica la complejidad del ataque como alta y no considera práctica la explotación. Como la copia descomprimida no carga los plugins de tu sitio, un plugin cortafuegos a nivel de PHP no puede bloquear esta petición.
• XSS almacenado desde cuentas de Colaborador o superiores, sobre todo en la Interactivity API (7 de los 17 avisos) y en varios bloques del núcleo.
• Customizer: los conjuntos de cambios no publicados podían verlos visitantes sin sesión iniciada.

A quién afecta

A todo sitio con una versión inferior a la 7.1.4 o al backport correspondiente (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 y así sucesivamente, hasta la 4.7.39). Los sitios en la 4.6 o anterior no reciben ninguna corrección. Los problemas de XSS importan sobre todo en sitios donde clientes, redactores o autores invitados tienen cuentas de Colaborador o superiores.

Comprueba un sitio en dos minutos

1. Versión: en wp-admin ve a Escritorio → Actualizaciones, o ejecuta wp core version. Todo lo que esté por debajo de la 7.1.4 (o del backport de tu rama) necesita la actualización.
2. Carpeta upgrade: abre https://example.com/wp-content/upgrade/ en una ventana privada. Un 403 o un 404 es lo que quieres. Un listado de archivos o una página 200 vacía significa que la carpeta es accesible desde la web.
3. Cuentas: en Usuarios, filtra por Colaborador, Autor y Editor. Elimina las que nadie use.

Qué hacer ahora

1. Actualiza el núcleo a la 7.1.4 o al backport de tu rama. Las versiones de seguridad menores suelen instalarse solas; comprueba que lo hicieron, porque algunos proveedores de hosting y plugins desactivan las actualizaciones automáticas del núcleo. Asegúrate antes de tener una copia de seguridad reciente, y comprueba después la página de inicio, un formulario y el pago.
2. Bloquea el acceso web a la carpeta upgrade en el servidor web, no en un plugin. En Apache, un archivo .htaccess en wp-content/upgrade/ con Require all denied. En nginx, location ^~ /wp-content/upgrade/ { deny all; }. WordPress sigue escribiendo en la carpeta mediante PHP, así que las actualizaciones siguen funcionando. En hosting gestionado donde no puedes cambiar el servidor, pídeselo a tu proveedor.
3. Sitios en la 4.6 o anterior: planifica ya el paso a una versión compatible. No habrá corrección para ellos.

Los atacantes están buscando este fallo, pero no se ha confirmado ninguna intrusión con éxito, así que un sitio actualizado con la carpeta upgrade cerrada no necesita restaurar ni cambiar claves solo por esta versión. Si ves archivos desconocidos en wp-content/upgrade/ o nuevas cuentas de administrador, trátalo como una intrusión: restaura desde una copia anterior a la aparición de esos archivos y luego cambia contraseñas y claves salt. Nuestra rutina para un día de vulnerabilidad tiene todos los pasos.

Cómo ayuda Verploy

Cada actualización se comprueba. Las arriesgadas se prueban primero en una copia. El núcleo de WordPress siempre cuenta como arriesgado: se prueba en una copia privada del sitio antes de que cambie el sitio en vivo y, si una comprobación falla tras publicar, el sitio se revierte automáticamente. Las copias de seguridad nocturnas cifradas en la UE te dan un punto limpio al que volver, y las vulnerabilidades conocidas aparecen por sitio con un enlace a la fuente.

Fuente: Patchstack, «WordPress 7.1.4 Security Release», 28 de octubre de 2026, patchstack.com. Aviso de explotación de Wordfence, 29 de octubre de 2026, según SecurityOnline; cifra de 24 horas según CyberPress, 31 de octubre de 2026. Comprobado el 31 de octubre de 2026.