CiberseguridadWordPressWeb

WordPress 7.1.4: el fallo del actualizador que ya se explota (CVE-2026-119977) y cómo proteger su web

Por Abant SistemasPublicado el 5 de noviembre de 2026

WordPress publicó el 28 de octubre de 2026 la versión 7.1.4, una actualización de seguridad que corrige más de veinte fallos. Casi todos son menores, pero uno no: un error en el propio proceso de actualización, registrado como CVE-2026-119977, que permite a cualquiera, sin usuario ni contraseña, ejecutar código en el servidor durante los segundos en que WordPress instala una actualización. Afecta a todas las versiones desde la 4.7 hasta la 7.1.3, y el 3 de noviembre la agencia de ciberseguridad de Estados Unidos (CISA) lo incluyó en su catálogo de vulnerabilidades explotadas.

La paradoja de este fallo: el momento de riesgo es justo la actualización que lo corrige. Mientras su WordPress se pasa a la 7.1.4, la ventana está abierta. Por eso conviene bloquear primero la carpeta de actualizaciones y actualizar después.

Qué ha pasado

El fallo lo comunicó el investigador Umut Bayram al equipo de seguridad de WordPress, que lo corrigió en la 7.1.4 y en versiones equivalentes para las ramas antiguas, hasta la 4.7. WordPress lo califica de gravedad baja, porque explotarlo exige acertar en un margen de tiempo muy corto. La empresa de seguridad Wordfence, que registró el CVE, le da una puntuación de 8,1 sobre 10: difícil de aprovechar, pero con consecuencias graves si sale bien.

Lo que ha cambiado la valoración es la reacción de los atacantes. Wordfence publicó una regla de su cortafuegos unas tres horas después de la actualización y registró el primer intento nueve minutos más tarde. En las primeras 24 horas bloqueó cerca de 63.000 intentos, y a primeros de noviembre la cifra superaba los 240.000, con el pico entre el 29 de octubre y el 1 de noviembre. A 31 de octubre Wordfence hablaba de intentos, no de webs comprometidas; la inclusión en el catálogo de CISA el 3 de noviembre indica que ya hay pruebas de explotación real.

Cómo funciona, sin tecnicismos

Cuando WordPress se actualiza con el paquete completo, descomprime una copia nueva de sí mismo en una carpeta temporal, wp-content/upgrade/, y desde ahí la copia a su sitio. Esa copia temporal incluye el asistente de instalación, el mismo que se usa al montar una web desde cero. Durante unos segundos ese asistente queda accesible desde internet en una ruta fácil de adivinar, porque lleva el número de la versión que se está instalando.

Si un atacante lo abre justo en ese momento, puede conectarlo a una base de datos suya y acabar ejecutando código en el servidor de la víctima. No tiene que saber cuándo actualiza usted: las actualizaciones automáticas siguen un calendario y un programa que pregunta por esa ruta una y otra vez, durante horas, acaba acertando. Es exactamente lo que ha observado Wordfence: unas pocas direcciones consultando grupos pequeños de webs durante más de catorce horas seguidas.

Hay un detalle importante para quien confía en su plugin de seguridad: la petición va directamente a un fichero PHP de esa carpeta, sin pasar por WordPress. Un cortafuegos que funciona como plugin no llega a verla, salvo que esté configurado para cargarse antes que cualquier fichero PHP (en Wordfence, la opción Extended Protection). La protección tiene que estar en el servidor web.

A quién afecta

Situación de su web	Riesgo	Qué hacer
WordPress 7.1.4 o la corrección de su rama, instalada	Corregido	Comprobar que no hubo intrusión antes de actualizar
WordPress entre 4.7 y 7.1.3, con actualizaciones automáticas	Alto: la ventana se abre al actualizar	Bloquear wp-content/upgrade/ y confirmar la versión
WordPress entre 4.7 y 7.1.3, sin actualizar desde hace tiempo	Alto, y suele venir con plugins atrasados	Bloquear, actualizar y revisar la web entera
WordPress anterior a la 4.7	Sin corrección: esas versiones ya no reciben parches	Migrar a una versión con soporte o a otra plataforma

WordPress ha publicado correcciones para todas las ramas que aún reciben parches de seguridad, desde la 4.7 en adelante, aunque recuerda que solo da soporte activo a la última versión. Si su web está en una rama antigua, lo recomendable es aprovechar para pasar a la 7.1.4: las ramas viejas reciben solo los parches de seguridad, y plugins y temas suelen dejar de funcionar con ellas.

Qué hacer hoy

Bloquee el acceso web a la carpeta wp-content/upgrade/ antes de nada. WordPress no necesita que esa carpeta se vea desde internet para actualizarse, así que no rompe nada, y cierra la ventana aunque una actualización automática se ponga en marcha. En el siguiente apartado tiene las líneas para Apache y Nginx.
Actualice a WordPress 7.1.4, o a la corrección de su rama, desde Escritorio, Actualizaciones. Si su hosting gestiona las actualizaciones por usted, pídale por escrito qué versión tiene instalada su web.
Compruebe la versión al terminar: aparece al pie del escritorio de WordPress y en Escritorio, Actualizaciones. Con acceso por terminal, el comando wp core version la muestra en un segundo.
Si su web no estaba actualizada el 28 de octubre, revise los indicios de intrusión que explicamos más abajo.
Revise también los plugins y el tema. La 7.1.4 corrige el núcleo, pero la mayoría de webs que se comprometen entran por un plugin atrasado.

Cómo bloquear la carpeta de actualizaciones

En Apache, que es lo habitual en el hosting compartido, añada estas líneas al principio del fichero .htaccess de la raíz de la web, por encima del bloque «# BEGIN WordPress»:

# Bloquea el acceso web a la carpeta temporal de actualizaciones (CVE-2026-119977)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

En Nginx, la regla equivalente va dentro del bloque server de la web, y después hay que recargar la configuración:

location ^~ /wp-content/upgrade/ {
    deny all;
}

Para comprobar que funciona, abra en el navegador su-dominio/wp-content/upgrade/: debe aparecer un error 403 (acceso prohibido). Si ve un listado de ficheros o una página en blanco sin error, la regla no se está aplicando. Si no tiene acceso a estos ficheros, pídaselo a su proveedor de hosting: varios ya lo aplican por defecto en todos sus servidores.

Cómo saber si alguien ha entrado

Si su web estaba en una versión vulnerable el 28 de octubre, Wordfence recomienda revisar estas señales:

En los registros de acceso del servidor, peticiones a ficheros PHP dentro de wp-content/upgrade/, sobre todo a setup-config.php, que hayan recibido respuesta 200 en lugar de 403 o 404.
Usuarios con rol de administrador que nadie de la empresa reconoce.
Plugins que nadie ha instalado, a menudo con nombres que imitan a otros conocidos.
Ficheros PHP que no deberían estar ahí, especialmente en wp-content/uploads/, donde solo debería haber imágenes y documentos.

Si encuentra algo, no se limite a borrar lo que vea: quien ha conseguido ejecutar código suele dejar más de una puerta trasera. Lo correcto es restaurar una copia de seguridad anterior a la intrusión, actualizarla antes de volver a publicarla, cambiar todas las contraseñas (administradores, hosting, FTP y base de datos) y revisar el resto de la web. Si necesita ayuda con eso, es parte de lo que hacemos en ciberseguridad para empresas.

Por qué importa en una empresa

Una web comprometida no es solo una página que se ve mal. Quien controla el servidor puede insertar código que robe los datos de los formularios de contacto o de pago, redirigir a sus visitantes a páginas fraudulentas, enviar spam desde su dominio hasta que los correos de la empresa empiecen a caer en la carpeta de correo no deseado de sus clientes, o usar la web para atacar a terceros. Google, además, marca las webs infectadas en sus resultados, y recuperar esa confianza lleva semanas.

En las pymes el problema rara vez es técnico: es que nadie tiene asignado mantener la web. Se hizo hace años, funciona, y nadie sabe en qué versión está ni quién tiene la contraseña del hosting.

Conclusión práctica

CVE-2026-119977 es difícil de explotar contra una web concreta, pero los atacantes lo están intentando de forma masiva y automática, y basta con acertar una vez. Bloquear wp-content/upgrade/ son cinco líneas y actualizar, unos minutos. Hágalo esta semana, y después compruebe que nadie entró antes.

Y si su web corporativa no necesita realmente un gestor de contenidos, vale la pena plantearse la pregunta de fondo. Una web estática no tiene actualizador, ni base de datos, ni plugins: este fallo, el de PHP2Shell y la mayoría de los que vienen no tienen por dónde entrar. En nuestro artículo sobre cómo pasar de WordPress a una web estática explicamos cuándo compensa, y en diseño web para empresas cómo lo hacemos.

Fuentes

Información actualizada a 5 de noviembre de 2026. Si cambian los datos de explotación o se publican nuevas correcciones, actualizaremos este artículo.

Nota editorial: este artículo se ha preparado con ayuda de herramientas de inteligencia artificial y lo ha revisado y publicado Abant Sistemas (LA PEQUEÑA MANZANA SLU), que asume su responsabilidad editorial. Si detectas un error, escríbenos a info@abantsistemas.com.