WordPress tiene un fallo que solo existe mientras se actualiza. La Agencia de Ciberseguridad de Estados Unidos lo añadió el 3 de noviembre a su catálogo de vulnerabilidades explotadas y dio a las agencias federales hasta el 6 de noviembre para aplicar la corrección, un plazo de tres días que reserva para los casos en los que hay constancia de ataques en curso. Fuera de ese calendario oficial, cualquier instalación que siga sin el parche queda expuesta a la misma técnica.
El fallo está registrado como WordPress CVE-2026-119977, tiene una puntuación de 8,1 sobre 10 y afecta a las versiones del core de la 4.7 a la 7.1.3 y a las ramas que el proyecto todavía mantiene. La causa es una condición de carrera del tipo tiempo de comprobación contra tiempo de uso, documentada por MITRE como CWE-367, que se dispara cuando WordPress instala una actualización completa del paquete y descomprime archivos, incluido el instalador, en una ruta predecible dentro de la carpeta de subidas.
Cualquier sitio que haya actualizado el core en los últimos meses ha abierto esa ventana al menos una vez, así que la pregunta útil ya no es si el fallo te afecta, sino si alguien lo usó mientras estaba abierto.
¿Qué falla exactamente en la actualización?
Una actualización completa del core no sobrescribe archivos uno a uno. WordPress descarga el paquete, lo descomprime en un directorio temporal bajo `wp-content/upgrade`, y desde ahí mueve los archivos a su ubicación definitiva. Ese directorio se nombra con un patrón predecible, así que cualquiera que conozca la versión del sitio puede construir la ruta y pedirla por HTTP mientras la actualización está en marcha.
La condición de carrera aparece en ese intervalo. El proceso comprueba que la ruta está libre, descomprime y mueve, y entre la comprobación y el uso hay una ventana en la que el instalador está accesible en una ubicación conocida. Un atacante que llegue en ese momento ejecuta código sin haberse autenticado nunca, porque el instalador se sirve como un archivo más del sitio.
Lo relevante para el administrador es que no hace falta un fallo de contraseñas ni una cuenta comprometida. Basta con alcanzar la URL correcta en el segundo correcto, y ese segundo es el que un escaneo automatizado puede estar esperando desde hace semanas. El análisis de PCrisk detalla que la explotación no deja un intento de acceso fallido en los registros, porque técnicamente no lo hubo.
Un ataque así no se parece a los que aparecen en las películas. No hay barrido de contraseñas ni explotación de un formulario, solo una petición HTTP normal que el servidor atiende sin sospechar, y esa normalidad es lo que hace tan difícil detectarla después.
La ventana importa más que la versión
La duración del intervalo depende de la velocidad del servidor y del tamaño del paquete, dos variables que en hosting compartido se mueven mucho. En una máquina con poca memoria y un disco lento, el proceso de descomprimir y mover puede tardar segundos o minutos, y cada segundo extra amplía la exposición.
Hay un agravante que no viene en el aviso. Muchos sitios no actualizan el core desde el panel, sino desde una tarea programada o desde un panel de hosting que ejecuta la actualización en lote sobre decenas de instalaciones. En ese escenario la ventana no se abre una vez: se abre en cada sitio, a la misma hora y con el mismo patrón, lo que convierte un fallo oportunista en un calendario predecible.
La predictibilidad es la parte que más debería preocupar a un proveedor de hosting compartido. Un atacante que conoce la hora del despliegue no necesita escanear todo internet, le basta con vigilar los servidores que ya identificó y esperar el momento.
La recomendación de actualizar sigue siendo correcta y no cambia, porque la alternativa es convivir con todos los fallos que el parche sí cierra. Lo que cambia es la lectura posterior, ya que un sitio actualizado no es automáticamente un sitio limpio y la ventana pudo abrirse sin dejar rastro visible en el panel.
Lo que debes revisar
La comprobación empieza por la versión, y en este caso la versión correcta es la que el proyecto publicó como parche tras el aviso de CISA. Si el sitio está por debajo de la 7.1.3, la actualización es urgente por sí sola. El calendario de tres días que recogió el seguimiento de CISA se aplica a las agencias federales y sirve como referencia de urgencia para el resto.
Después hay que mirar lo que la actualización no borra. El directorio `wp-content/upgrade` debería estar vacío cuando no hay ninguna actualización en curso, y un archivo con nombre de instalador que sigue ahí días después merece una revisión. Conviene revisar también los registros de acceso del servidor buscando peticiones a esa ruta, porque un intento fallido deja la misma huella que uno que funcionó.
La ventana es corta y eso engaña. Un administrador que busque ataques de horas verá poco, mientras que un escaneo automatizado que lleva semanas probando la misma ruta cada minuto acumula cientos de peticiones en el registro sin que nadie las lea, y ahí está la evidencia que hace falta para saber si hubo suerte.
No olvides los plugins
Otra revisión útil es la de usuarios y plugins. Un atacante que ejecutó código durante la ventana pudo crear un administrador nuevo, modificar un archivo del tema activo o instalar un plugin desde una URL propia. Comparar la lista de administradores con la que había hace un mes y revisar la fecha de modificación de los archivos del tema detecta la mayoría de esos movimientos sin necesidad de herramientas forenses.
Si el sitio no puede actualizarse hoy, hay dos medidas que reducen la exposición sin tocar el código. La primera es bloquear por configuración del servidor el acceso público al directorio de subidas y al instalador, con una regla que devuelva un 403 a cualquier petición que apunte a esa ruta. La segunda es desactivar las actualizaciones automáticas del core y ejecutarlas en una ventana con el sitio en mantenimiento, con lo que la ventana deja de coincidir con el tráfico.
Ninguna de las dos es un parche y no sustituyen a la actualización. Sirven para el intervalo en el que el sitio todavía no puede actualizarse y para los sitios con versiones antiguas que ya no reciben soporte, que son muchos más de los que la industria admite.
El parche no cierra la puerta que ya se abrió
La lección de este CVE va contra la intuición que el sector repite desde hace años. Actualizar el core sigue siendo la primera medida de seguridad de un WordPress y aun así, en este caso, la acción principal también era la que abría la vulnerabilidad, un patrón que ya apareció en el análisis de los CVE que el kernel no puede arreglar a escala de parche semanal.
Eso obliga a cambiar la lista de comprobación. En lugar de preguntar solo por la versión instalada, un administrador debería poder responder cuándo se actualizó por última vez, si el directorio de actualización quedó limpio después y si alguien pidió esas rutas durante el proceso. Las tres respuestas están en los registros del propio servidor y casi nadie las mira.
Quien quiera el contexto completo de lo que ocurrió esa semana en PHP, con el error de validación que permitió ejecutar código antes de que arrancara la aplicación, lo tiene en la pieza sobre PHP2Shell. La metodología para ordenar todo esto aparece en la guía sobre cómo leer un CVE si te afecta, y el patrón de la ventana de actualización volverá en cada aviso que implique un proceso de despliegue.
