WordPress: condición de carrera con RCE e intentos de explotación

📌 Novedades posteriores: WordPress, CVE-2026-119977: CISA confirma la explotación activa (3 de noviembre de 2026)

El 28 de octubre de 2026 WordPress publicó la versión 7.1.4, que, entre otras correcciones, cierra una condición de carrera (race condition) en el proceso de actualización del núcleo que se puede explotar sin autenticación para ejecutar código en remoto. Según Defiant, la empresa que desarrolla Wordfence, los primeros intentos de explotación llegaron pocas horas después de la publicación de los parches. La noticia la recogen SecurityWeek, heise Security y The Hacker News; los detalles técnicos que siguen proceden del artículo de SecurityWeek, que cita el análisis de Defiant y es el único texto completo que hemos podido analizar.

Qué ha pasado

Durante una actualización, WordPress descomprime los archivos de la nueva versión en un directorio temporal de preparación (staging) antes de instalarlos. Según Defiant, la ruta de ese directorio es predecible y, en muchos servidores, accesible desde la web. Durante unos segundos, hasta que WordPress limpia los archivos temporales, un atacante que conozca o adivine la ruta puede llegar a los archivos recién descomprimidos, incluidos los del instalador.

Cuando se publicaron las fuentes todavía no se había asignado un CVE. Defiant califica el fallo de gravedad alta, pero con una complejidad de ataque elevada.

Detalles técnicos

• Producto: núcleo de WordPress, proceso de actualización.
• Versión corregida: 7.1.4; según SecurityWeek, la corrección también se ha llevado a las ramas anteriores, hasta la 4.7.
• Tipo: condición de carrera con ejecución remota de código (RCE), sin necesidad de una cuenta en el sitio.
• Condiciones, según Defiant: una actualización con el paquete completo, que incluye también los archivos del instalador; acceso público por web y ejecución de PHP en el directorio de staging; una ruta de staging predecible o descubierta; y tiempo suficiente para completar el ataque antes de que WordPress borre los archivos temporales.
• Corrección: la 7.1.4 hace aleatorio el nombre del directorio de staging, añade un archivo índice de protección e impide promover de forma insegura los datos de configuración presentes en la copia de staging.
• MITRE ATT&CK: T1190 (Exploit Public-Facing Application).

Por tanto, la ventana de explotación se abre solo mientras el sitio se actualiza con un paquete completo. Por eso, según Defiant, los atacantes consultan sin parar las rutas vulnerables, con la esperanza de acertar justo en esos pocos segundos. Las peticiones observadas apuntan a setup-config.php, el script con el que WordPress crea la configuración inicial, dentro de la copia de staging. Las fuentes disponibles no describen la cadena completa que lleva desde el archivo alcanzado hasta la ejecución de código.

En total, la 7.1.4 corrige 22 fallos de seguridad, entre ellos varios XSS, problemas en la Interactivity API, una divulgación de información sin autenticación y una debilidad de autorización. Además, actualiza los certificados raíz incluidos tras la reciente revocación de eMudhra.

Intentos de explotación: qué dicen las fuentes

Según Defiant, la primera petición detectada por la nueva regla del firewall de Wordfence llegó nueve minutos después de activarla; en las primeras 21 horas su telemetría registró más de 18.500 peticiones dirigidas a las rutas de setup-config.php en la copia de staging. The Hacker News, en cambio, titula con casi 63.000 intentos en 24 horas: el texto del artículo no estaba disponible y no sabemos qué peticiones se contaron, así que las dos cifras no son directamente comparables. heise Security también informa de intentos de explotación observados.

Wordfence no ha comunicado compromisos con éxito.

Impacto para las empresas europeas e italianas

WordPress es la base de muchas webs corporativas, portales de servicios y tiendas online, a menudo gestionados por agencias o proveedores de hosting. La alta complejidad reduce las probabilidades de éxito de cada intento, pero el escaneo es automático y continuo: cada actualización completa que se ejecuta en un servidor donde el directorio de staging es accesible desde la web se convierte en una oportunidad. Un ataque con éxito lleva a la ejecución de código en el servidor, con acceso a las páginas, a la base de datos y a los datos enviados por los formularios.

Para las entidades sujetas a NIS2, el compromiso de un sitio expuesto es un evento que hay que valorar para la notificación al CSIRT nacional (en Italia, CSIRT Italia de la ACN); si la base de datos contiene datos personales, también hay que considerar la notificación a la autoridad de protección de datos en 72 horas que exige el RGPD. Los centros sanitarios y las administraciones públicas que usan WordPress para citas o formularios online deberían empezar por esos sitios.

Qué hacer ahora

1. Inventario: haz una lista de todas las instalaciones de WordPress de la empresa, incluidas las de pruebas y las gestionadas por agencias o proveedores externos, y pide a estos últimos una confirmación por escrito de la actualización.
2. Actualiza a la 7.1.4, o a la versión corregida de tu rama si usas una versión anterior. Comprueba la versión desde el escritorio o con wp core version.
3. Bloquea el acceso web al directorio de staging (buena práctica general, no indicada por las fuentes). En WordPress las actualizaciones suelen usar wp-content/upgrade/: denegar desde el servidor web el acceso HTTP y la ejecución de PHP en ese directorio elimina la condición del acceso público, también durante la actualización. Las fuentes no dicen si la actualización a la 7.1.4, ejecutada desde una versión vulnerable, abre a su vez la ventana: por prudencia, aplica el bloqueo antes de actualizar.
4. Revisa el WAF: si delante de tus sitios hay un web application firewall, comprueba que sus reglas para WordPress estén actualizadas.
5. Busca rastros en los logs del servidor web: peticiones a setup-config.php fuera de su ruta normal, en especial bajo wp-content/upgrade/, y sobre todo respuestas con código 200 en los minutos de una actualización.
6. Comprueba la integridad: wp core verify-checksums, cambios recientes en wp-config.php, nuevos usuarios administradores, archivos PHP inesperados en wp-content/. Si encuentras rastros, aísla el sitio, conserva los logs, restaura desde una copia limpia, cambia contraseñas, credenciales de la base de datos y claves secretas, y después valora las obligaciones de notificación.

Cómo ayuda ARXDOME

ARX Expose muestra qué servicios expone tu empresa en Internet y qué productos se reconocen en ellos, incluidos los sitios WordPress olvidados. Con ARX Scout Assessment, a petición y con tu autorización, una evaluación de vulnerabilidades no invasiva señala software obsoleto y paneles de administración expuestos. ARX Sentry recoge logs y eventos de los servidores monitorizados, útiles para buscar peticiones a las rutas del instalador.

Última actualización: 30 de octubre de 2026