El RCE del actualizador de WordPress entra en KEV con tres días de plazo

Tres días de plazo. Es lo que CISA ha dado a las agencias federales de Estados Unidos para corregir CVE-2026-119977, la condición de carrera del actualizador de WordPress que entró el 3 de noviembre de 2026 en el catálogo KEV con la marca de explotación activa y fecha límite del 6 de noviembre. Desde que WordPress publicó el parche el 28 de octubre, el fallo ha sumado un identificador CVE con CVSS 8,1 en NVD, el análisis de su descubridor, reglas de Trend Micro y Qualys y, el 4 de noviembre, una prueba de concepto en GitHub acompañada de un segundo repositorio que se hace pasar por ella.

• CISA añadió CVE-2026-119977 al catálogo KEV el 3 de noviembre de 2026 y, bajo la BOD 26-04, da a las agencias federales hasta el 6 de noviembre.
• Afecta a WordPress 4.7.0 a 7.1.3 y está corregido en 7.1.4 y en los backports de cada rama hasta 4.7.39.
• La evidencia pública son intentos, 17.510 bloqueados por Wordfence en 24 horas a 5 de noviembre y tres contra un honeypot de Previdian el 30 de octubre, sin ningún compromiso confirmado.
• Desde el 4 de noviembre hay una PoC en GitHub y un repositorio señuelo que dice saltarse el parche.
• Parchea, cierra el directorio de actualización desde el servidor web y revisa los logs de la ventana de cada actualización desde el 28 de octubre.

Lo que CISA tiene para hablar de explotación activa y lo que no publica

El aviso de CISA del 3 de noviembre se limita a una frase de plantilla, «This type of vulnerability is a frequent attack vector for malicious cyber actors» (este tipo de vulnerabilidad es un vector de ataque frecuente para los actores maliciosos), y la entrada del catálogo KEV atribuye el problema a «predictable, web-accessible staging paths used during full-package core upgrades» (rutas de preparación predecibles y accesibles por web usadas en las actualizaciones completas del núcleo). No hay indicadores de compromiso, ni víctimas, ni atribución. El campo de uso conocido en campañas de ransomware figura como desconocido y el de triaje forense, como obligatorio. La decisión SSVC que NVD publica junto a la ficha, firmada por CISA el mismo 3 de noviembre, califica la explotación como activa, el ataque como no automatizable y el impacto técnico como total.

Esta noticia continúa la que publicamos el 30 de octubre sobre el parche de WordPress 7.1.4, que explicaba el mecanismo del fallo y las reglas de Nginx y Apache para cerrar el directorio wp-content/upgrade. Entonces el CVE no existía y el catálogo KEV no lo recogía. Lo que ha cambiado desde entonces es la evidencia pública de ataques, que sigue procediendo de dos empresas privadas. Wordfence contó más de 18.500 peticiones contra rutas de setup-config.php en las primeras 21 horas, cifra que subió a 62.969 ataques bloqueados en 24 horas el 30 de octubre, según recogió The Hacker News de Alex Thomas, responsable del equipo de respuesta a amenazas de Wordfence. El volumen ha bajado después, con 13.095 bloqueos diarios en la actualización del fin de semana y 12.632 el 4 de noviembre.

La captura anterior de la ficha de Wordfence, tomada a las 07:20 UTC del 5 de noviembre, muestra el contador en 17.510 ataques bloqueados en las 24 horas anteriores, junto al CVSS 8,1 y el vector completo. Wordfence describió en su informe del 29 de octubre a dos fuentes que sondearon pequeños grupos de sitios durante 14,5 horas seguidas, un «behavior consistent with trying to catch the brief upgrade window» (comportamiento coherente con intentar cazar la breve ventana de actualización). Ninguna de las cifras corresponde a compromisos confirmados y la propia empresa no ha publicado ninguno.

La segunda evidencia es más pequeña y más concreta. Los sensores de Previdian, una empresa que mantiene su propio feed de vulnerabilidades explotadas, registraron tres intentos de explotación contra un honeypot a las 05:46 UTC del 30 de octubre desde una única dirección IP geolocalizada en Reino Unido. Según su ficha de CVE-2026-119977, no ha vuelto a ver actividad desde entonces y añadió el fallo a su feed a las 14:00 UTC de ese mismo día, cuatro días antes que CISA. Los sistemas de decepción sirven precisamente para eso, para separar a quien escanea de quien intenta entrar, y en este caso la muestra es de tres peticiones.

La ficha de Previdian, en la captura, resume el estado a 5 de noviembre: confianza confirmada, intentos de explotación observados, primera y última observación el 30 de octubre y una probabilidad EPSS del 1 %. Esa probabilidad tan baja frente a una entrada en KEV es la paradoja de este fallo. Explotarlo exige acertar en una ventana de segundos, pero cada actualización completa del núcleo vuelve a ofrecerla.

Tres días bajo la BOD 26-04 y la cuarta entrada de WordPress Core en KEV este año

El plazo de tres días no es casual. Desde el 10 de junio de 2026 CISA aplica la directiva BOD 26-04, que reordena los plazos de las BOD 19-02 y 22-01 en un modelo graduado según cuatro criterios: exposición del activo, presencia en KEV, posibilidad de automatizar el exploit e impacto tras la explotación. Las vulnerabilidades que dan control total de un activo expuesto a internet llevan tres días, y la directiva fija además cuándo una agencia debe comprobar si el sistema ya estaba comprometido antes de parchear. Hemos contado en el feed JSON del catálogo del 4 de noviembre que 151 de las 284 entradas añadidas en 2026 llevan ese plazo de tres días, 86 tienen catorce y 44 tienen veintiuno. Security Affairs y otros medios citaron la BOD 22-01 al informar de esta inclusión, pero el aviso de CISA y la propia entrada del catálogo remiten a la 26-04.

El mismo feed sitúa el fallo en su contexto. Es la cuarta vulnerabilidad del núcleo de WordPress que entra en KEV en 2026, tras CVE-2026-60137 y CVE-2026-63030, la cadena wp2shell añadida el 21 de julio, y CVE-2026-87902, una inclusión remota de ficheros añadida el 25 de septiembre. Antes de este año el catálogo solo recogía tres plugins de WordPress, los tres incorporados en noviembre de 2021 al crearse. El fallo de FortiOS usado por PEERSTITCH recibió en octubre el mismo plazo de tres días, y la comparación sirve para medir lo que CISA entiende por control total.

NVD publicó la ficha del CVE el 31 de octubre a las 06:16 UTC y la pasó a estado analizado el 4 de noviembre. La puntuación es la de Wordfence, que actúa como CNA, y NVD no ha emitido una propia. La discrepancia con WordPress se mantiene: el proyecto califica el fallo como Low en su aviso de GitHub, según ThreatDefence y Ostorlab, y su anuncio de 7.1.4 seguía sin mencionar el identificador CVE a las 07:00 UTC del 5 de noviembre. Para quien tenga que justificar una ventana de mantenimiento urgente, el argumento está en KEV y no en el aviso del fabricante, algo que ya vimos con el fallo de Ivanti Connect Secure a principios de mes.

De WordPress 2.7 a la ventana de segundos, lo que Umut Bayram cuenta ahora de su hallazgo

El anuncio de WordPress acreditó a Umut Bayram sin cargo ni empresa. Picus Security publicó su análisis firmado, con última actualización del 5 de noviembre, y la empresa lo presenta como investigador propio. El texto retrocede más de lo que decían los avisos. El comportamiento que hace posible el ataque existe desde WordPress 2.7, de 2008, aunque la corrección solo llega a las ramas con soporte, de 4.7 en adelante. Entre 2.7.0 y 2.7.1 el directorio de trabajo era fijo, wp-content/upgrade/core. De 2.8.0 a 4.3.35 el nombre se derivaba del fichero del paquete y era predecible. De 4.4.0 a 5.8.18 llevaba un sufijo aleatorio de seis caracteres, de modo que solo era explotable si la ruta se filtraba por otra vía. Y a partir de 5.9.0 el tratamiento de la cabecera Content-Disposition volvió a hacerlo predecible hasta el parche, que añade un sufijo de 16 caracteres. Bayram escribe que la investigación le llevó unas cuatro horas.

La cadena que describe tiene ocho pasos y termina de una forma distinta a la que cabría esperar de un RCE. El atacante calcula la ruta de preparación, que depende del rango de versiones, y espera a que una actualización completa descomprima el paquete en wp-content/upgrade. Entre la extracción y la copia pide el setup-config.php de la copia temporal sin autenticarse y le entrega los datos de una base de datos vacía que controla. El instalador escribe un wp-config.php dentro del árbol temporal, el paso de copia de la versión vulnerable no lo excluía y el fichero sobrescribe el wp-config.php de la web. A partir de ahí la web se conecta a la base de datos del atacante, muestra el asistente de instalación, el atacante crea la primera cuenta de administrador y, en una instalación normal, sube un plugin que ejecuta PHP en el servidor.

La figura de Picus muestra la línea que cierra ese último paso. En update_core, la lista de exclusiones de la copia desde el directorio de trabajo pasa de contener wp-content y version.php a incluir también wp-config.php, con un comentario que avisa de que ese fichero puede proceder del directorio temporal. Es el cambio que Patchstack echó en falta en el anuncio oficial y el que convierte la ventana de segundos en una ventana sin salida, porque aunque el atacante llegue al instalador temporal, su wp-config.php ya no se promociona a la raíz. Los otros dos cambios, el nombre impredecible del directorio y el index.php que la limpieza ya respeta, los explicamos con el commit en la noticia anterior.

Una PoC en GitHub, un repositorio señuelo y las firmas de Trend Micro y Qualys

La API de búsqueda de GitHub devolvía el 5 de noviembre tres repositorios con el identificador del fallo, todos creados el día 4. El primero, a las 04:15 UTC, es un escáner local de foxcornlab que se describe como solo de detección, sin payloads ni sondeos remotos. El segundo, a las 10:12 UTC y con dos estrellas, es el que Anton Guzhevskiy, Principal Product Researcher de ThreatDefence, da por prueba de concepto funcional en su guía de caza, actualizada ese mismo 5 de noviembre, y planta un wp-config.php en la copia temporal tal como describe Bayram. El tercero, a las 18:16 UTC, lleva en el nombre que salta el parche de 7.1.4, pero según ThreatDefence no contiene código, solo un enlace acortado de descarga, y el investigador lo considera un probable señuelo de malware. El agregador Sploitus lo lista con ese mismo enlace acortado como única descarga. No hemos podido abrir los tres repositorios desde el entorno de redacción y no enlazamos ninguno.

Que exista PoC pública seis días después del parche cambia poco para quien ya actualizó y mucho para quien actualiza a mano y tarde. También conviene leerlo junto a la nota de Trend Micro, que escribe que «exploitation is timing-dependent and limited to servers actively performing an upgrade» (la explotación depende del momento y se limita a servidores que están ejecutando una actualización). Los fabricantes de seguridad han publicado ya sus firmas, y la tabla recoge las que hemos podido comprobar en la nota de Trend Micro, el boletín de Qualys y las fichas de Wordfence y Previdian. Ninguna sustituye al parche, y la de Wordfence tiene el límite que ya contamos, porque el exploit pide el fichero PHP temporal sin cargar WordPress.

Los CERT nacionales han ido detrás del catálogo. El Centro Canadiense de Ciberseguridad publicó el aviso AV26-1117 el 3 de noviembre, el NCSC neerlandés el NCSC-2026-0466 el 4 de noviembre y CERT-FR había emitido el 29 de octubre el CERTFR-2026-AVI-1420 sobre la release, sin mencionar el CVE porque aún no existía. INCIBE-CERT no había publicado aviso alguno sobre WordPress 7.1.4 ni sobre este CVE a las 07:00 UTC del 5 de noviembre, según su listado de alerta temprana. Con un 39,5 % de las webs del mundo sobre WordPress, el dato español más cercano sigue siendo el de los proveedores de hosting, que son quienes pueden aplicar la regla de servidor web a miles de instalaciones de golpe, como ya ocurrió con el parche de emergencia de PHP en octubre.

Nuestra lectura es que KEV ha resuelto en tres días una discusión que los laboratorios llevaban una semana teniendo. Patchstack no consideraba práctico el ataque y WordPress lo califica de Low, mientras Wordfence le asignó 8,1 y documentó decenas de miles de intentos diarios. CISA no publica qué prueba de compromiso tiene, y es posible que su evidencia sea la misma telemetría de intentos que la de Wordfence y Previdian. Para un administrador el debate es irrelevante, porque cada actualización del núcleo reabre la ventana y la regla del servidor web cuesta dos líneas. En un hosting compartido, en cambio, la inclusión en KEV es el argumento que faltaba para aplicar esa regla a todos los clientes sin esperar a que cada uno actualice.

Qué revisar en los logs de la última actualización antes del viernes

El parche y la regla del servidor web van primero, y ambos están explicados en la noticia del 30 de octubre. Lo que añade la inclusión en KEV es la obligación, para las agencias federales, y la conveniencia, para todos los demás, de comprobar si alguien ganó la carrera antes de que se aplicara el parche. ThreatDefence propone acotar la búsqueda a la ventana de cada actualización, desde cinco minutos antes hasta diez minutos después, y buscar ahí cualquier petición a ficheros PHP bajo wp-content/upgrade, sobre todo si devolvió un 200, y cualquier POST a un setup-config.php temporal. Estos comandos cubren esa revisión en un servidor propio con Nginx y WP-CLI, con la fecha de la última actualización como referencia.

# Fecha de la última actualización del núcleo
stat -c '%y' wp-includes/version.php
# Peticiones a PHP bajo el directorio de actualización, con cualquier código de respuesta
grep -E '"(GET|POST) /wp-content/upgrade/[^" ]*\.php' /var/log/nginx/access.log*
# Las que devolvieron 200 son las que importan
grep -E '"(GET|POST) /wp-content/upgrade/[^" ]*\.php[^"]*" 200' /var/log/nginx/access.log*
# Cuentas de administrador con su fecha de alta
wp user list --role=administrator --fields=user_login,user_registered,user_email
# Plugins y temas modificados en los últimos siete días
find wp-content/plugins wp-content/themes -maxdepth 1 -mtime -7 -ls
# Base de datos a la que apunta la web
grep -E "DB_(HOST|NAME|USER)" wp-config.php

1. Confirma que cada instalación corre 7.1.4 o el backport de su rama, incluidas las de staging, las gestionadas con Composer y las que tienen las actualizaciones automáticas desactivadas. CISA da hasta el 6 de noviembre a las agencias federales, y es una referencia razonable para cualquiera.
2. Extrae del log de acceso la ventana de cada actualización del núcleo desde el 28 de octubre y revisa las peticiones a wp-content/upgrade. Un GET a setup-config.php o install.php con respuesta 200 dentro de esa ventana es un indicio directo.
3. Comprueba que DB_HOST, DB_NAME, DB_USER y el prefijo de tablas de wp-config.php siguen apuntando a tu base de datos y que la fecha de modificación del fichero no coincide con una actualización.
4. Busca cuentas de administrador dadas de alta después del 28 de octubre, plugins o temas que nadie instaló y ficheros PHP sueltos en wp-content/upgrade o en wp-content/uploads.
5. En el host, revisa si el proceso del servidor web o de PHP ha lanzado shells o herramientas de descarga, y si hay conexiones salientes a direcciones públicas por el puerto 3306, que es la huella de una web hablando con la base de datos del atacante.
6. Si encuentras un indicio, saca la web de producción, conserva ficheros, base de datos y logs, reconstruye desde una copia conocida en la versión corregida y rota credenciales de base de datos, salts, contraseñas de administrador y claves de API y de hosting. Avisa a INCIBE-CERT, que atiende a empresas y particulares, o al CCN-CERT cuando el sitio pertenece al sector público.

Ni Wordfence ni Patchstack han publicado direcciones IP, user-agents ni nombres de webshell, así que la caza depende de rutas, tiempos y cambios en ficheros, y una plataforma de gestión de logs que conserve los logs de acceso de semanas atrás es la diferencia entre poder hacerla y no. Quien use Wordfence Free tiene hasta el 27 de noviembre sin regla de firewall, y WordPress 7.2, prevista para el 8 de diciembre, abrirá la siguiente ventana de actualización completa en millones de sitios a la vez.