La vulnerabilidad de ejecución remota de código (RCE) en el núcleo de WordPress que corrigió la versión 7.1.4 ya tiene identificador oficial: CVE-2026-119977, publicado el 31 de octubre por Wordfence con una puntuación CVSS de 8,1, nivel alto. Afecta a todas las versiones entre la 4.7.0 y la 7.1.3 y permite a un atacante sin cuenta ejecutar código en el servidor, pero solo durante los segundos en los que el sitio está instalando una actualización completa del núcleo. Pese a esa ventana tan estrecha, ya se está intentando explotar de forma masiva.
Las claves de la vulnerabilidad CVE-2026-119977 de WordPress en 30 segundos
El fallo ya estaba entre los corregidos en WordPress 7.1.4, publicada el 28 de octubre. Lo que ha cambiado desde entonces es que tiene CVE, que los proveedores de seguridad han publicado sus reglas de detección y que la explotación empezó casi de inmediato. Según las notas oficiales de la versión, la 7.1.4 corrige 22 vulnerabilidades agrupadas en 17 avisos, y el investigador Umut Bayram figura entre quienes las reportaron.
El problema está en cómo WordPress actualiza su núcleo cuando descarga el paquete completo. Durante el proceso, descomprime los archivos en una carpeta de trabajo dentro de wp-content/upgrade/, que el servidor web puede servir. Hasta la versión 7.1.3, el nombre de esa carpeta era predecible y, además, la limpieza borraba el index.php que impide listar el directorio. Según el análisis de Patchstack, un atacante que pida la ruta correcta en el momento justo puede llegar a ejecutar código PHP en el servidor. Trend Micro lo clasifica como CWE-367, una condición de carrera del tipo «comprobar y luego usar» (TOCTOU).
De ahí la puntuación. El vector CVSS (AV:N/AC:H/PR:N/UI:N) indica que se ataca por red, sin credenciales ni interacción del usuario, pero con complejidad alta: la ventana dura segundos y solo existe mientras el sitio se está actualizando. Patchstack, de hecho, no lo considera práctico de explotar en un intento aislado. El problema es que esa ventana se repite en cada actualización, incluidas las automáticas, y los atacantes no envían una petición, sino miles. Según recoge Techaeris, Wordfence explicó que una sola petición casi no tiene posibilidades de acertar y que los atacantes están sondeando de forma continua.
Wordfence asegura que bloqueó 62.969 intentos de explotación en las primeras 24 horas después de publicar la versión 7.1.4 y que los ataques empezaron nueve minutos después de activar su regla de cortafuegos. Dos de los orígenes más activos estuvieron atacando pequeños grupos de sitios durante unas 14 horas y media. La compañía no detectó compromisos con éxito, pero el volumen deja claro que el fallo está en el punto de mira.
Hay un detalle técnico que complica la defensa: según Patchstack, un cortafuegos que funcione a nivel de PHP dentro de WordPress no puede bloquear este ataque, porque la copia descomprimida se ejecuta sin cargar los mu-plugins del sitio. La protección tiene que estar en el servidor web o en la red. En ese terreno, varios proveedores han publicado reglas. Trend Micro, por ejemplo, ha añadido una regla IPS para servidores (1012774) y un filtro de red para TippingPoint (48746) como parcheo virtual, además de detecciones para su plataforma Vision One, con el argumento de reducir la exposición mientras se aplican las actualizaciones.
La medida principal es actualizar a WordPress 7.1.4 o a la versión corregida de la rama que uses. Según las notas oficiales, el parche se publicó el mismo día para 7.0.8, 6.9.11, 6.8.12 y así hasta la 4.7.39; las versiones 4.6 y anteriores ya no reciben actualizaciones de seguridad. Los sitios con actualizaciones automáticas en segundo plano habrán recibido el parche sin intervención. La 7.1.4 añade 16 caracteres aleatorios al nombre de la carpeta temporal, vuelve a crear el index.php y deja de borrarlo, y protege la copia de wp-config.php durante el proceso.
Mientras tanto, y también después, conviene bloquear el acceso web a wp-content/upgrade/ desde la configuración de Apache o Nginx y comprobar que no se puede listar. Trend Micro recomienda además no dejar el actualizador a medias y restringir el acceso a directorios no estándar en la raíz web. Para los equipos que gestionan muchos sitios, tiene sentido revisar los registros del servidor en busca de peticiones repetidas a rutas dentro de esa carpeta durante las ventanas de actualización.
No es el único problema que corrige la 7.1.4. La mayoría de las otras vulnerabilidades requieren una cuenta de colaborador o superior, así que Patchstack aconseja revisar qué usuarios tienen esos roles. Hay también una fuga de información sin autenticación: los cambios del Personalizador sin publicar quedaban expuestos a cualquier visitante.
Desde la 4.7.0 hasta la 7.1.3. Está corregida en la 7.1.4 y en las versiones de mantenimiento de las ramas anteriores hasta la 4.7.39.
No. Pero solo se puede explotar mientras el sitio está instalando una actualización completa del núcleo, una ventana de pocos segundos.
Según Patchstack, un cortafuegos a nivel de PHP no basta, porque la copia descomprimida se ejecuta sin los mu-plugins del sitio. Hay que bloquear el acceso a wp-content/upgrade/ en el servidor web o en la red.
Sí. Wordfence bloqueó 62.969 intentos en las primeras 24 horas tras la publicación de la 7.1.4, sin compromisos detectados.
Fuentes:
