Durante unos segundos, cada vez que un WordPress vulnerable instala un paquete completo del núcleo, quien llegue a tiempo puede ejecutar código en el servidor sin haber iniciado sesión. El fallo, CVE-2026-119977, afecta a las versiones 4.7 a 7.1.3 y se corrigió el 28 de octubre en WordPress 7.1.4. Desde el 3 de noviembre figura en el catálogo de CISA de vulnerabilidades explotadas (KEV), según The Hacker News.
El ataque solo funciona mientras el sitio se actualiza: el procedimiento que debería protegerlo es el que lo expone. Desde el mismo día del parche, Wordfence observa tráfico automatizado que sondea sitios una y otra vez para acertar con ese instante.
¿Cómo se pasó del parche al catálogo KEV en seis días?
La secuencia, reconstruida con los datos de WordPress, Wordfence y CISA, fue esta:
- 28 de octubre. WordPress publica la 7.1.4 con 22 correcciones de seguridad. Entre ellas está una condición de carrera en la actualización del núcleo que comunicó el investigador Umut Bayram. Ese día salen también versiones corregidas para las ramas antiguas.
- Ese mismo día, Wordfence detecta los primeros sondeos y despliega una regla de cortafuegos unas tres horas después de la publicación, según webhosting.today.
- 30 de octubre. The Hacker News informa de que Wordfence bloqueó 62.969 ataques en 24 horas contra este fallo. El mismo día, los señuelos de Previdian registran tres intentos desde una IP geolocalizada en el Reino Unido.
- 31 de octubre. Wordfence asigna el identificador CVE-2026-119977, con una puntuación CVSS de 8,1.
- 3 de noviembre. CISA lo incorpora al KEV y da a las agencias federales civiles de EE. UU. hasta el 6 de noviembre para corregirlo.
El margen de tres días coincide con el plazo más corto del nuevo esquema federal de parcheo que analizamos en el artículo sobre la BOD 26-04 de CISA. A una empresa europea le sirve de referencia cuando el activo da a internet y el fallo ya se explota.
Las cifras de Wordfence cuentan intentos bloqueados, no intrusiones. La empresa no ha comunicado compromisos con éxito, según recoge Techaeris. En otra medición contó más de 18.500 peticiones a las rutas provisionales en las 21 horas siguientes a activar su regla, y el 4 de noviembre hablaba de 12.632 intentos bloqueados en el último día. Son ventanas distintas y no deben sumarse. CISA tampoco ha detallado qué pruebas le llevaron a incluir el fallo en el catálogo.
¿Qué ocurre exactamente durante la actualización?
Cuando WordPress instala un paquete completo del núcleo, primero lo descomprime en un directorio de trabajo dentro de wp-content/upgrade/ y después copia los ficheros a su ubicación definitiva. Según el análisis de Patchstack, antes de la 7.1.4 se daban tres circunstancias a la vez:
- El nombre de ese directorio de trabajo era predecible.
- El paso de limpieza borraba el
index.phpque impide listar el contenido de la carpeta. - La copia provisional incluía
wp-admin/setup-config.php, el asistente de instalación, que puede ejecutarse sin la configuración del sitio.
Si el servidor web sirve y ejecuta PHP en esa ruta, quien solicite el asistente en el momento justo encuentra un instalador operativo al margen de la instalación en producción, y desde ahí puede llegar a ejecutar código. En el laboratorio de Wordfence la ventana duró solo unos segundos. Por eso el tráfico observado consiste en consultas repetidas y pacientes: las dos fuentes más activas pasaron unas 14,5 horas sondeando grupos reducidos de sitios.
Según Patchstack, el código vulnerable procede de WordPress 2.8. La corrección añade 16 caracteres aleatorios al nombre del directorio, conserva el index.php e impide que la configuración generada en la copia provisional pase a la instalación, lo que Patchstack describe como dejar de copiar wp-config.php desde la carpeta de trabajo.
¿Por qué un cortafuegos escrito en PHP no lo detiene?
En su modo habitual, los plugins de seguridad que filtran peticiones desde dentro de WordPress no ven este ataque. La petición maliciosa va directa a un fichero PHP de la copia provisional, sin cargar antes el WordPress del sitio, así que un WAF integrado en la aplicación no llega a ejecutarse. Wordfence solo lo cubre con su modo de protección ampliada, que intercepta las peticiones directas a ficheros PHP. El bloqueo eficaz se aplica en el servidor web, el proxy inverso o la CDN.
¿Quién está expuesto y por qué las valoraciones no coinciden?
Están afectadas todas las versiones entre la 4.7 y la 7.1.3, según la ficha de Rapid7 y el aviso del proyecto. Para que el ataque prospere, Wordfence enumera cuatro condiciones: que se instale un paquete completo con los ficheros del instalador, que el árbol provisional sea accesible por web con PHP activo, que la ruta sea predecible o descubrible y que el atacante llegue antes de que WordPress borre los temporales.
Activar las actualizaciones automáticas no cierra la ventana; la reabre. Patchstack subraya que cada actualización de un sitio sin corregir, incluidas las desatendidas, vuelve a crear el directorio provisional.
La gravedad depende de a quién se consulte, y la discrepancia es reveladora:
| Fuente | Valoración | En qué se basa |
|---|---|---|
| WordPress | Gravedad baja | Aviso de seguridad del proyecto, según webhosting.today |
| Wordfence | CVSS 8,1 (alta) | Sin autenticación ni interacción del usuario, pero con complejidad de ataque alta |
| Patchstack | Complejidad alta; «no práctico de explotar» | Hay que acertar la ruta en una ventana de segundos |
| CISA | Incluido en el catálogo KEV | Pruebas de explotación activa; plazo federal hasta el 6 de noviembre |
Fuentes: webhosting.today, The Hacker News y Patchstack.
Wordfence y Patchstack miden lo difícil que es acertar un intento; WordPress no detalla en qué basa su valoración. CISA mide otra cosa: si alguien lo está intentando en serio. Un atacante que puede repetir el intento durante horas sin coste convierte una complejidad alta en una cuestión de paciencia. Por eso cruzar la explotación observada con la exposición, como hacen los modelos que combinan KEV, EPSS y SSVC, ordena mejor las prioridades que el CVSS por sí solo.
Hay dos grupos que merecen atención aparte. Las instalaciones en la 4.6 o anteriores quedan fuera del aviso porque ya no reciben parches de seguridad; como el código vulnerable procede de la 2.8, lo razonable es considerarlas expuestas. Y en muchas organizaciones el inventario de WordPress va más allá de la web corporativa: micrositios de campañas, blogs de marca montados por agencias, entornos de preproducción publicados por error. Son los sitios que nadie actualiza a mano y los que suelen aparecer en una revisión de superficie de ataque.
En alojamientos gestionados, la exposición depende de si el proveedor ya bloquea esa ruta para todos sus clientes. Pídale confirmación por escrito.
¿Cómo saber si alguien aprovechó la ventana?
La señal principal está en los registros del servidor web: peticiones a ficheros PHP bajo wp-content/upgrade/, sobre todo a setup-config.php. Una búsqueda sencilla en los registros de acceso de nginx, incluidos los comprimidos:
zgrep -E '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log*
Encontrar peticiones no demuestra un compromiso, porque la mayoría serán sondeos que llegaron fuera de la ventana. Lo que hay que cruzar es su hora y su código de respuesta con el registro de actualizaciones del núcleo. Una respuesta 200 sobre un fichero de esa carpeta, coincidiendo con una actualización, basta para abrir una investigación.
Dentro de WordPress, los indicadores de compromiso que señalan Wordfence y The Hacker News son cuentas de administrador desconocidas, plugins que nadie instaló y ficheros PHP sin explicación. Con WP-CLI se revisan en pocos minutos:
wp core version
wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_registered
wp plugin list --fields=name,status,version
find wp-content -name '*.php' -newermt '2026-10-28' -not -path '*/cache/*'
Si algo no encaja, el sitio debe tratarse como comprometido. Hay que aislarlo, preservar registros y una copia del sistema de ficheros antes de limpiar, y rotar las credenciales de base de datos y las claves de wp-config.php, que un atacante con ejecución de código habrá podido leer. Desde ese punto es trabajo de respuesta a incidentes: reinstalar sin más borra justo las pruebas que hacen falta.
¿Qué versión instalar y qué hacer si hoy no se puede actualizar?
WordPress ha publicado la corrección para todas las ramas desde la 4.7. Solo la 7.1 tiene soporte activo; las demás reciben los arreglos como cortesía. Según la nota de la versión, cuanto más antigua es la rama, menos de los 22 fallos le afectan:
| Rama | Versión corregida | Fallos de los 22 que le afectan |
|---|---|---|
| 7.1 | 7.1.4 | 22 |
| 7.0 | 7.0.8 | 22 |
| 6.9 | 6.9.11 | 22 |
| 6.8 y 6.7 | 6.8.12 y 6.7.11 | 20 |
| 6.6 | 6.6.11 | 19 |
| 6.5 y 6.4 | 6.5.14 y 6.4.14 | 17 |
| 5.9 a 6.3 | Versión puntual de cada rama (de 5.9.20 a 6.3.14) | 9 |
| 5.0 a 5.8 | Versión puntual de cada rama | 6 |
| 4.9 | 4.9.35 | 4 |
| 4.7 y 4.8 | 4.7.39 y 4.8.34 | 2 |
| 4.6 o anterior | Sin corrección | Sin datos |
Fuente: WordPress.org.
Como las ramas antiguas dependen de esa cortesía y no del soporte activo, el destino razonable es la 7.1.4. El orden de los pasos también importa: si actualizar abre la ventana, lo sensato es cerrarla antes de pulsar el botón.
Patchstack recomienda denegar el acceso web a wp-content/upgrade/ y comprobar que el directorio no se puede listar. Alex Thomas, de Defiant, la empresa detrás de Wordfence, coincidió en declaraciones a Techaeris en que bloquearlo en el servidor o en la CDN antes de actualizar es el mejor orden. En nginx:
location ^~ /wp-content/upgrade/ { deny all; }
En Apache, con un .htaccess dentro de ese directorio o con un bloque equivalente en la configuración del sitio:
Require all denied
Options -Indexes
Entre actualizaciones, la carpeta solo debería contener un index.php. Los proveedores de alojamiento pueden aplicar la regla a todos los sitios de un servidor a la vez, lo que cubre también a los que aún no se han actualizado. Wordfence insiste en que la medida reduce la exposición pero no sustituye al parche. Es una medida de bastionado (hardening) que debería venir de serie en la plantilla de todo servidor WordPress, haya o no un CVE abierto, y una comprobación que encaja en un programa de gestión de vulnerabilidades.
La 7.1.4 trae además la actualización de los certificados raíz incluidos en WordPress tras la retirada de eMudhra, el caso que explicamos al hablar de las claves débiles de una autoridad de certificación.
¿Qué vigilar en los próximos días?
Hay dos fechas marcadas. El 6 de noviembre vence el plazo federal. El 27 de noviembre llega la regla de Wordfence a los usuarios de su versión gratuita, con el retraso habitual de 30 días. Después de eso el riesgo no caduca: cada sitio sin corregir volverá a exponerse en su siguiente actualización completa del núcleo.
También hay que confirmar que las actualizaciones automáticas se aplicaron de verdad. Un sitio configurado para actualizarse solo que sigue en la 7.1.3 es exactamente lo que buscan los sondeos.
El mecanismo de actualización forma parte de la superficie de ataque desde hace tiempo. En 2016, Wordfence ya describió un fallo en la infraestructura de actualización de WordPress que habría permitido distribuir código a una cuarta parte de la web. Este año hemos visto actualizaciones manipuladas en AOMEI Backupper y puertas traseras en sitios WordPress que estaban al día con sus actualizaciones. El parche sigue siendo la defensa principal, pero el procedimiento que lo instala debería revisarse con el mismo rigor que el código que corrige.
Las configuraciones y comandos de este artículo son orientativos y deben probarse en un entorno de preproducción antes de aplicarse en sistemas productivos. Los datos de explotación proceden de WordPress, Wordfence, Patchstack y CISA tal como se publicaron hasta el 5 de noviembre de 2026 y pueden cambiar a medida que se conozcan más detalles.
Preguntas frecuentes
¿Mi WordPress es vulnerable si tiene activadas las actualizaciones automáticas?
▾
Lo es mientras no haya llegado a la versión corregida de su rama. La actualización automática no impide el ataque: cada actualización completa del núcleo en un sitio sin corregir vuelve a crear el directorio provisional durante unos segundos. Una vez instalada la 7.1.4 (o la versión corregida de su rama), el nombre del directorio deja de ser predecible. Compruebe la versión con wp core version o en el escritorio de WordPress, sin dar por hecho que la actualización se aplicó.
¿Basta con tener un plugin de seguridad como Wordfence?
▾
No en su modo habitual. El cortafuegos del plugin forma parte del sitio y la copia provisional del núcleo se ejecuta al margen de él, así que la petición le pasa por delante. Wordfence lo cubre con su protección ampliada, que filtra las peticiones directas a ficheros PHP; los clientes de pago recibieron la regla el 28 de octubre y los de la versión gratuita la recibirán el 27 de noviembre. El bloqueo en el servidor web es independiente del plugin y protege también a los sitios sin actualizar.
¿Por qué WordPress lo califica de gravedad baja si CISA lo da por explotado?
▾
Porque responden a preguntas distintas. La etiqueta de gravedad del proyecto (que no explica su criterio) y la valoración de Patchstack pesan la dificultad de acertar una ventana de segundos; el catálogo KEV solo recoge fallos con pruebas de explotación. Para decidir cuándo parchear, lo que manda es que el sitio esté en internet y que haya atacantes probando, no la etiqueta.
¿Qué pasa con los sitios en WordPress 4.6 o anterior?
▾
No reciben corrección. Mientras se planifica la migración, la barrera principal es denegar el acceso web a wp-content/upgrade/ en el servidor, el proxy o la CDN y evitar lanzar actualizaciones completas del núcleo sin ese bloqueo. Un sitio tan antiguo acumula además muchos otros fallos sin corregir, así que debe figurar en el inventario como activo de alto riesgo.
¿Cómo distingo un sondeo de una intrusión en los registros?
▾
Un sondeo es una petición a wp-content/upgrade/ que recibe un 404 o un 403 porque llegó fuera de la ventana o encontró el bloqueo. Una respuesta 200 a un fichero PHP de esa carpeta que coincida con una actualización del núcleo ya justifica investigar; si además aparecen administradores nuevos, plugins desconocidos o ficheros PHP recientes, el caso pasa a tratarse como incidente.
¿Afecta también a las actualizaciones de plugins y temas?
▾
Las fuentes publicadas describen el vector solo en actualizaciones completas del núcleo, porque el riesgo nace de que la copia provisional incluye el asistente de instalación setup-config.php. No hay datos que extiendan el problema a plugins o temas. Aun así, bloquear el acceso web a wp-content/upgrade/ es una medida de bajo impacto que protege también todo lo que se descomprima en esa carpeta.
¿Tiene sentido aplicar el plazo de tres días de CISA en una empresa europea?
▾
No es obligatorio, pero sí razonable como referencia. En la BOD 26-04, estar en el catálogo KEV y en un activo expuesto a internet son dos de las variables que empujan hacia el plazo de tres días, y un WordPress público con CVE-2026-119977 reúne ambas. Para entidades sujetas a NIS2, poder demostrar que una vulnerabilidad del catálogo KEV se trató en días y no en semanas es una prueba útil ante un auditor de que la gestión de vulnerabilidades funciona.
