WordPress 7.1.4 cierra un RCE sin cuenta que ya sondean los atacantes

Nueve minutos tardó en llegar la primera petición contra la regla que Wordfence desplegó el 28 de octubre de 2026 a las 20:30 UTC para proteger a sus clientes del fallo más serio de WordPress 7.1.4, una condición de carrera en el proceso de actualización que permite ejecutar código en el servidor sin tener cuenta en la web. La versión, publicada ese mismo día con parches para 22 vulnerabilidades y backports hasta la rama 4.7, llega con atacantes sondeando ya las rutas del instalador temporal, aunque explotarlo exige acertar en una ventana de unos segundos.

El anuncio oficial de WordPress lo publicó el 28 de octubre Aaron Jorbin, que lideró la release junto a Nik Tsekouras, con la fórmula habitual: «it is recommended that you update your sites immediately» (se recomienda actualizar los sitios de inmediato). El proyecto lo difundió también desde su cuenta en X, donde pidió a los propietarios de webs que actualizaran desde el panel o descargando el paquete.

Una copia completa de WordPress a la vista durante unos segundos

Cada vez que WordPress instala o actualiza algo, descomprime el paquete en wp-content/upgrade, un directorio que el servidor web sirve como cualquier otro. Hasta 7.1.3 el nombre de la carpeta de trabajo se derivaba del nombre del paquete, así que era predecible, y la rutina de limpieza que se ejecuta antes de descomprimir borraba todo el contenido del directorio, incluido el index.php que impide listarlo. Durante los segundos que dura una actualización completa del núcleo, la copia descomprimida contiene un WordPress entero con su propio wp-admin/setup-config.php, el instalador que arranca sin la configuración del sitio.

Dave Jong, Security Research Lead de Patchstack, escribe en el análisis de Patchstack que esa copia «sits at a guessable and browsable path» (está en una ruta adivinable y navegable). Quien la alcance a tiempo puede ejecutar el instalador contra una base de datos que controle, dentro del document root de otra persona, y de ahí pasar a ejecutar PHP. Wordfence describe el mismo recorrido y añade un detalle que importa para la defensa: el exploit pide directamente un fichero PHP del árbol temporal sin pasar por el WordPress del sitio, de modo que un firewall en PHP que se cargue como plugin no llega a ver la petición.

El fallo lo comunicó el investigador Umut Bayram, acreditado en el anuncio de WordPress sin cargo ni empresa. El sink es antiguo: Patchstack lo sitúa en WordPress 2.8, y la corrección se ha portado a todas las ramas que todavía reciben parches de seguridad, hasta 4.7.

La corrección está en el commit e7b33f536d de la rama 7.1, que fusiona el changeset 64877 y acredita a umut3806, marcs0h, rfaile313 y jorbin. El diff cambia dos ficheros. En class-wp-upgrader.php aparece un método nuevo, get_working_dir_name, que añade al nombre de la carpeta un guion y 16 caracteres aleatorios generados con wp_generate_password, la limpieza del directorio deja de borrar index.php y, si ese fichero no existe, lo crea con el clásico «Silence is golden». En update-core.php, la lista de ficheros que nunca se copian desde el directorio de trabajo incorpora wp-config.php, y un comentario nuevo explica el motivo. «Never copy a wp-config.php, which could have been written to the working directory.» (nunca copiar un wp-config.php, que podría haberse escrito en el directorio de trabajo). Patchstack señala que este segundo cambio no se menciona en el anuncio.

La captura del commit en GitHub muestra las 36 líneas añadidas, con el nombre impredecible del directorio, el index.php que ya no se borra y el wp-config.php que ya no se promociona. Dos días antes, el 26 de octubre, un colaborador había abierto en el repositorio el PR 14879, asociado al ticket 66148 de Trac, para añadir ficheros index.php al directorio de actualización y al de copias temporales. Ese PR sigue abierto y no forma parte del parche.

18.500 peticiones en 21 horas contra setup-config.php

Wordfence desplegó su regla de bloqueo el 28 de octubre a las 20:30 UTC, unas tres horas después del anuncio, para los clientes de Premium, Care y Response. Los usuarios de la versión gratuita la recibirán el 27 de noviembre, tras el retraso habitual de 30 días. Según la telemetría de Wordfence, la primera coincidencia llegó nueve minutos después y en las primeras 21 horas contaron más de 18.500 peticiones dirigidas a rutas del instalador setup-config.php dentro del árbol temporal.

Dos de las fuentes con más volumen sondearon pequeños grupos de sitios durante unas 14,5 horas seguidas, el comportamiento que cabe esperar de quien intenta cazar la ventana de una actualización. Otras probaron variaciones de nombre de directorio y de versión. Wordfence reconoce que no todas las peticiones usaban la ruta vulnerable exacta, pero concluye que «attackers quickly understood the race condition and began targeting it» (los atacantes entendieron rápido la condición de carrera y empezaron a apuntar a ella). La firma no publica ningún caso de compromiso confirmado, y en sus laboratorios el directorio vulnerable solo permaneció accesible durante segundos.

Las dos lecturas no se contradicen, pero conviene tenerlas juntas. Patchstack puntúa el fallo con complejidad de ataque alta y «would not call it practical to exploit» (no lo llamaría práctico de explotar), mientras que Wordfence le asigna un CVSS de 8,1 y documenta sondeos a gran escala. Lo que une ambas es que la ventana se abre en cada actualización, incluidas las automáticas en segundo plano, y que una web que actualiza plugins y temas con frecuencia abre esa ventana muchas veces al mes.

El anuncio no asigna puntuaciones ni identificadores a ninguna de las 22 vulnerabilidades, y a 30 de octubre de 2026, cuando se escribe esta noticia, ningún CVE de la release figuraba en NVD. WordPress tampoco publica CVSS en sus notas de seguridad, por lo que las dos cifras disponibles proceden de laboratorios y no coinciden en el enfoque.

Qué ramas de WordPress reciben el parche y cuántas webs hay en juego

La página de la versión 7.1.4 en HelpHub detalla el alcance por ramas. WordPress 7.0 y 6.9 están afectadas por las 22 vulnerabilidades y reciben 7.0.8 y 6.9.11. Las ramas 6.8 y 6.7 arrastran 20 de los 22 fallos, la 6.6 tiene 19, y 6.5 y 6.4 tienen 17, porque el runtime cliente de la Interactivity API llegó en 6.4 y la clase PHP en 6.5. De 6.3 a 5.9 el recuento baja a 9, de 5.8 a 5.0 a 6, la 4.9 tiene 4 y las ramas 4.8 y 4.7 solo 2, una de ellas la condición de carrera. Las versiones corregidas de esas ramas van de 6.3.14 y 5.9.20 a 4.8.34 y 4.7.39. WordPress 4.6 y anteriores no reciben ninguna corrección.

El anuncio oficial, en la captura anterior, lista los descubridores de cada fallo y agradece la colaboración a los contribuidores de la release, entre ellos umut3806. Hay un apunte más en esa lista: la release actualiza los certificados raíz empaquetados por la revocación de eMudhra, la misma autoridad cuya raíz Chrome retiró de su almacén de confianza, en el fichero de certificados que WordPress usa para sus propias conexiones HTTPS salientes.

Esta noticia es la tercera del blog sobre WordPress en diez días. Las dos anteriores trataron ataques a su ecosistema de extensiones, primero el backdoor de Rank Math PRO servido desde la web del plugin y después las claves robadas de UpdraftCentral. Esta vez el problema está en el propio núcleo y, por una vez, no en una extensión.

El gráfico de W3Techs recoge la cuota de WordPress entre todas las webs, que ha bajado desde algo más del 43 % en octubre de 2025 hasta el 39,5 % del 30 de octubre de 2026. Con los datos del mismo día, la plataforma sigue detrás del 58,2 % de los sitios con un CMS identificable, y el reparto por versiones da el 67,6 % a la rama 7, el 25,6 % a la 6, el 4,7 % a la 5 y el 2 % a la 4. Ese último grupo incluye a quienes siguen en 4.6 o anteriores, sin parche. W3Techs no publica un desglose por país, y en el momento de escribir esta noticia no había cifra española de exposición ni aviso de INCIBE-CERT sobre 7.1.4, aunque el CERT sí publicó avisos para las releases de seguridad de WordPress del 3 y el 13 de agosto.

Según el recuento de The Repository, 7.1.4 es la séptima release de seguridad del núcleo desde mediados de julio y la cuarta en la rama 7.1 desde su lanzamiento en agosto. 7.1.1 corrigió 11 fallos el 17 de septiembre, 7.1.2 cerró un RCE crítico cinco días después y 7.1.3 arregló siete vulnerabilidades el 6 de octubre. El resto de los 22 fallos de esta release exige una cuenta de Contributor o superior en casi todos los casos. Siete de las 17 fichas corresponden a la Interactivity API y comparten una raíz, según Patchstack. KSES, el filtro que decide qué HTML puede guardar un usuario sin unfiltered_html, admitía cualquier atributo data-* con cualquier valor, y todas las directivas de esa API son atributos data-wp. Un Contributor podía escribir directivas en una entrada y el runtime las ejecutaba en el navegador del visitante. Entre esos fallos hay una denegación de servicio que cuelga la pestaña del visitante, no el servidor. Dos vulnerabilidades más no exigen cuenta: la condición de carrera y la exposición de changesets del Customizer sin publicar.

Bloquear wp-content/upgrade en Nginx y Apache antes de tocar nada más

El orden importa porque la ventana se abre también al instalar 7.1.4, ya que el actualizador que descomprime el paquete nuevo es el antiguo, y la limpieza vulnerable se ejecuta una última vez. Si la web tiene actualizaciones automáticas, lo normal es que a estas alturas ya esté en 7.1.4 o en el backport de su rama. Si se va a actualizar a mano, la regla del servidor web va primero.

Estas son las reglas para el servidor web, que van antes de cualquier otro paso. En Nginx va dentro del bloque server y en Apache en el vhost o en el .htaccess de la raíz, fuera del bloque que WordPress gestiona.

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

RedirectMatch 403 ^/wp-content/upgrade/

1. Deniega el acceso web a wp-content/upgrade en Nginx o Apache con las reglas anteriores y comprueba con curl que la ruta devuelve 403.
2. Confirma la versión instalada con wp core version o en Escritorio, Actualizaciones. Si la rama es 7.0, 6.9 o anterior, la versión corregida es la de la lista de HelpHub (7.0.8, 6.9.11, 6.8.12 y así hasta 4.7.39). Si sigue en 4.6 o anterior, migra a una rama con soporte.
3. Verifica la integridad del núcleo con wp core verify-checksums y busca ficheros PHP ajenos en el directorio de actualización, que tras 7.1.4 solo debe contener index.php.
4. Comprueba la fecha de modificación de wp-config.php y que DB_HOST, DB_NAME y DB_USER apuntan a tu base de datos. Un wp-config.php que señale a un host desconocido es señal de compromiso.
5. Busca en los logs de acceso peticiones a /wp-content/upgrade/ que terminen en setup-config.php o install.php. El tráfico legítimo no tiene motivo para pedir ninguna de las dos rutas.
6. Si usas Wordfence, confirma que el firewall funciona en modo Extended Protection, que se carga antes de que la petición alcance el PHP pedido. La regla no sustituye al parche.
7. Revisa quién tiene rol de Contributor o superior, porque 20 de los 22 fallos arrancan desde una cuenta con ese nivel.
8. Si encuentras indicios, aísla la web, conserva los logs y notifícalo a INCIBE-CERT si eres empresa o particular, y al CCN-CERT si gestionas un sitio del sector público.

Para la comprobación posterior sirven estos comandos, pensados para ejecutarse en la raíz de la instalación.

wp core version
wp core verify-checksums
find wp-content/upgrade -type f -name '*.php' ! -path 'wp-content/upgrade/index.php' -ls
stat -c '%y %n' wp-config.php
grep -E '/wp-content/upgrade/.*(setup-config|install)\.php' /var/log/nginx/access.log
curl -s -o /dev/null -w '%{http_code}\n' https://tu-dominio.es/wp-content/upgrade/

El grep del log es la parte que más vale la pena automatizar, y hay herramientas de gestión de logs de código abierto con las que montar esa alerta en un hosting propio. Quien dependa de un hosting compartido tendrá que pedir al proveedor el acceso al log o la regla de bloqueo, porque un plugin no puede aplicarla.

Patchstack y Wordfence coinciden en que la regla del servidor web cierra el único fallo de la release que no necesita cuenta. Nosotros añadiríamos que la regla debería quedarse incluso después de parchear, porque el directorio sigue siendo accesible por URL y 7.1.4 solo hace impredecible su nombre. Lo mismo vale para el RCE sin autenticación de Drupal de hace unas semanas o para los servidores PHP que siguen pendientes del parche de PHP2Shell. Cada capa que se cierra en el servidor es una carrera menos que el atacante puede ganar.

Dudas habituales sobre cómo actualizar WordPress tras 7.1.4

Cómo actualizar WordPress manualmente

Antes de descargar el paquete, aplica la regla que bloquea wp-content/upgrade en el servidor web, porque la descompresión de 7.1.4 la hace todavía el actualizador antiguo. Después, desde Escritorio, Actualizaciones, pulsa Actualizar ahora, o usa wp core update desde la terminal. Si subes los ficheros por FTP, respeta wp-config.php y wp-content y sustituye el resto, y termina con wp core verify-checksums para confirmar que ningún fichero del núcleo difiere del oficial.

Cuánto tarda en actualizar WordPress

Una actualización completa del núcleo dura segundos en la mayoría de los hostings, y precisamente esa duración es la ventana que explota el fallo de 7.1.4. Si el proceso se queda a medias, el sitio muestra un aviso de mantenimiento mientras exista el fichero .maintenance en la raíz, y la opción core_updater.lock conserva un valor antiguo. Borrar el fichero y repetir la actualización resuelve lo habitual, pero antes conviene revisar el log del servidor por si la interrupción no fue casual.

Cómo actualizar WordPress sin perder datos

Haz una copia de la base de datos y de wp-content antes de pulsar el botón, porque las actualizaciones del núcleo no tocan ese directorio pero sí pueden fallar a medias. WordPress guarda además una copia temporal de plugins y temas en upgrade-temp-backup durante cada actualización. Tras actualizar, comprueba que el plugin de copias y el tema siguen activos y que la versión que aparece en el panel es 7.1.4 o la de tu rama.