WordPress 7.1.4: la vulnerabilidad que se explota justo cuando actualizas (CVE-2026-119977)

Acción inmediata

Si administras algún WordPress, haz esto antes de seguir leyendo:

# ¿Qué versión tienes?
wp core version

# Actualiza a la última de tu rama (7.1.4 si estás en la 7.1)
wp core update

# Comprueba que ningún archivo del core fue alterado
wp core verify-checksums

Sin WP-CLI: Escritorio, Actualizaciones, y listo. Las versiones corregidas son 7.1.4, 7.0.8, 6.9.11, 6.8.12 y así hasta la 4.7.39. La 4.6 y anteriores no reciben parche.

Y, mientras actualizas, bloquea el acceso web a wp-content/upgrade/ (más abajo tienes cómo). Es la parte que casi nadie va a hacer y la que más importa.

---

Qué ocurrió

El 28 de octubre de 2026 WordPress publicó la versión 7.1.4, una versión de seguridad con 13 correcciones. Una de ellas, reportada por Umut Bayram, es una condición de carrera durante el proceso de actualización del core que puede acabar en ejecución remota de código (RCE) sin autenticación.

El 3 de noviembre, CISA añadió el fallo a su catálogo de vulnerabilidades explotadas (KEV), lo que significa que hay evidencia de ataques reales. Las agencias federales de EE. UU. tienen hasta el 6 de noviembre para parchear.

Dato	Valor
Identificador	CVE-2026-119977 (asignado por Wordfence); aviso GHSA-4w3m-c66w-69mg
Tipo	Condición de carrera TOCTOU (CWE-367)
Versiones afectadas	WordPress 4.7.0 a 7.1.3
Corregido en	7.1.4 y backports hasta la 4.7.39
Gravedad	Baja según WordPress; CVSS 3.1 de 8.1 (alta) según Wordfence
En el KEV de CISA	Sí, desde el 3 de noviembre de 2026

Una nota sobre el CVE y la gravedad

Verás cifras que no cuadran, y conviene saber por qué:

• El aviso oficial dice “CVE: ninguno conocido”. El aviso de GitHub se publicó el 29 de octubre. Según un análisis de Rescana, Wordfence, que actúa como CNA, asignó el CVE después, el 31 de octubre, y WordPress no actualizó el aviso. Los medios publicados antes de esa fecha tampoco lo traen.
• WordPress dice “baja”; Wordfence dice 8,1. La diferencia viene de la complejidad: el ataque exige acertar una ventana de pocos segundos. Eso reduce la probabilidad, no el daño si se consigue.

---

Cómo funciona

Según el aviso de WordPress y el análisis publicado por xHack, la cadena es esta:

1. Cuando actualizas el core con el paquete completo, WordPress descomprime la versión nueva en una carpeta de trabajo dentro de wp-content/upgrade/.
2. Antes de la 7.1.4, el nombre de esa carpeta salía del nombre del paquete, es decir, era predecible.
3. La carpeta es accesible desde la web y contiene todos los archivos de la versión nueva, incluido wp-admin/setup-config.php, el instalador, que puede ejecutarse sin la configuración del sitio.
4. La rutina de limpieza borraba todo el contenido, incluido el index.php que evita el listado de directorios.

Un atacante que consulta esa ruta en el momento justo puede ejecutar el instalador desde tu propia carpeta temporal. En las pruebas de laboratorio de Wordfence, la carpeta era alcanzable solo durante segundos.

La corrección de la 7.1.4 aleatoriza el nombre del directorio de staging y añade protección con index, según la cobertura de SecurityWeek.

Por qué las actualizaciones automáticas no te salvan

Lo contraintuitivo: el momento de riesgo es la propia actualización. Los sitios con actualizaciones automáticas en segundo plano también pasan por esa ventana, porque esas actualizaciones ejecutan el mismo código vulnerable. Y la ventana se abre cada vez que se actualiza el core, no una sola vez.

Esto lo cambia todo respecto a “parchea y olvídate”: una vez en la 7.1.4 o una rama corregida, el problema queda cerrado. Hasta entonces, cada actualización antes del parche es una oportunidad.

Condiciones del ataque

Para que funcione deben darse todas a la vez:

• El sitio ejecuta una actualización completa del core.
• El servidor sirve wp-content/upgrade/ públicamente.
• La ruta de staging es predecible o descubrible.
• El atacante termina antes de que WordPress elimine los archivos temporales.

Si rompes la tercera condición, bloqueando la ruta, el ataque no puede empezar.

---

Estado de explotación

Lo que se sabe y lo que no:

• Wordfence registró más de 18.500 peticiones dirigidas a rutas del instalador en las primeras 21 horas tras activar su regla de firewall.
• Un medio cita unas 63.000 peticiones bloqueadas en 24 horas (The Hacker News); otro análisis dice no haber podido verificar esa cifra, así que tómala con cautela.
• No hay compromisos confirmados públicamente, y CISA no ha publicado la evidencia detrás de su marca de “explotada”.
• No se han publicado direcciones IP ni hashes de archivos como indicadores de compromiso.

Dicho de otra forma: hay intentos masivos y automáticos, y aún no se conoce un caso demostrado de éxito. Es el mejor momento para actuar, antes de que eso cambie.

---

Cómo mitigar

1. Actualiza a la versión de tu rama

wp core update
wp core version

Si usas una versión antigua que ya no es la última, lo ideal es subir a la 7.1.4. Si no puedes, usa el backport de tu rama (por ejemplo 6.8.12 o 6.9.11). Revisa todos tus sitios, incluidos staging, sitios de clientes y los que tienen las actualizaciones automáticas desactivadas.

2. Bloquea wp-content/upgrade/ desde el servidor

Es la defensa que funciona incluso antes de parchear. Hay que hacerlo en el servidor web, el virtual host o el CDN, no poniendo un archivo dentro de la carpeta: la rutina de limpieza lo borraría.

Patchstack añade un matiz importante: un plugin de firewall en PHP puede no detener esta petición, porque llega a un archivo PHP de la carpeta temporal antes de que WordPress cargue.

Nginx:

location ^~ /wp-content/upgrade/ {
    return 404;
}

Apache (virtual host):

<Location "/wp-content/upgrade">
    Require all denied
</Location>

Apache en hosting compartido (.htaccess en la raíz del sitio):

RedirectMatch 404 ^/wp-content/upgrade/

Después de aplicarlo, recarga el servidor y comprueba que la ruta ya no responde:

curl -I https://tu-sitio.com/wp-content/upgrade/
# Esperado: 403 o 404

Aviso: estas reglas son configuraciones estándar de cada servidor, pero no las probé contra este fallo en concreto. Pruébalas primero en un solo sitio. WordPress copia los archivos en el servidor, no por HTTP, así que bloquear la ruta no debería romper las actualizaciones, pero confírmalo.

3. Mantén la regla después de actualizar

Entre actualizaciones, esa carpeta solo contiene un index.php, así que bloquearla no te quita nada. Déjala puesta.

4. Capa extra

Si usas Wordfence, activa la Extended Protection como segunda barrera. Es un complemento, no un sustituto de la regla del servidor.

---

Cómo saber si te intentaron atacar

En los logs de acceso:

# Peticiones a PHP dentro de la carpeta temporal
grep "wp-content/upgrade/" /var/log/nginx/access.log | grep "\.php"

# Rutas del instalador
grep "setup-config.php" /var/log/nginx/access.log

Fíjate en peticiones repetidas alrededor de las horas en que se actualizó el sitio.

En WordPress:

wp core verify-checksums     # archivos del core alterados
wp user list --role=administrator   # administradores que no reconoces
wp plugin list               # plugins que no instalaste

Si encuentras algo sospechoso:

1. Conserva los logs y el contenido de la carpeta de upgrade antes de limpiar nada.
2. Rota las contraseñas de administradores y de la base de datos, y las claves de wp-config.php.
3. Revisa usuarios, plugins y archivos PHP nuevos.
4. Si falla la verificación de checksums, restaura desde una copia limpia.

---

No es el único arreglo de la 7.1.4

Si estabas posponiendo la actualización, hay más motivos. Según el anuncio oficial, esta versión corrige 13 asuntos, entre ellos:

• Varios XSS almacenados: en el marcado de bloques, la API de interactividad, el personalizador, los bloques de categorías, listas de reproducción, imágenes y paginación de comentarios, y en los inicios de sesión y las solicitudes de datos privados.
• Una denegación de servicio almacenada en la API de interactividad.
• Cambios del personalizador sin publicar que podían ser descubiertos por usuarios no autenticados.
• Notas de entradas legibles por usuarios con privilegios pero sin permiso de edición.
• Actualización de los certificados raíz tras la revocación de eMudhra.

Los backports del resto de arreglos siguen en curso: WordPress indica que se publicarán conforme estén listos.

---

Lo que deja este incidente

1. El proceso de actualización también es superficie de ataque. Pasamos años endureciendo plugins y temas, y este fallo aparece en el mecanismo que se supone que nos protege.
2. Un firewall en PHP no siempre basta. Si el fallo se dispara antes de que WordPress cargue, la defensa tiene que estar en el servidor o en el CDN. Es la misma lección que vimos con php2shell, donde el fallo vivía por debajo de la aplicación.
3. Revisa los sitios que no ves. Los que más se quedan atrás son los de clientes antiguos, staging olvidados y sitios con las actualizaciones automáticas apagadas. Un inventario con la versión de cada uno vale más que cualquier regla.

---

Conclusión

CVE-2026-119977 no es un fallo en un plugin ni algo que dependa de una mala configuración tuya: depende del momento en que WordPress se actualiza a sí mismo. Actualiza a 7.1.4 o al backport de tu rama, bloquea wp-content/upgrade/ en el servidor, verifica los checksums y revisa todos tus sitios, no solo el principal.

Los detalles siguen moviéndose: el CVE se asignó días después del aviso, las cifras de ataques varían según la fuente y CISA no ha publicado su evidencia. Contrasta con el aviso oficial de WordPress y con Wordfence antes de dar el tema por cerrado.

---

Fuentes y recursos

• WordPress.org — Anuncio de WordPress 7.1.4

• GitHub — Aviso GHSA-4w3m-c66w-69mg (versiones afectadas por rama)

• xHack — CVE-2026-119977: el momento de actualizar es el riesgoso

• The Hacker News — Intentos de explotación tras el parche

• The Hacker News — CISA confirma la explotación

• SecurityWeek — Fresh WordPress vulnerability in attackers’ crosshairs