CISA KEV: la carrera por actualizar WordPress Core, bajo ataque activo

Esta es de las que duelen. CISA ha añadido CVE-2026-119977 —una condición de carrera de tipo time-of-check time-of-use (TOCTOU) en WordPress Core— a su catálogo de Vulnerabilidades Explotadas Conocidas, citando evidencia de explotación activa. El fallo tiene una puntuación CVSS de 8,1 y, según el aviso de CISA, podría permitir a atacantes no autenticados ejecutar código en el servidor durante la ventana de actualización. La causa raíz: rutas de staging predecibles y accesibles por web que se usan durante las actualizaciones completas del núcleo.

Léelo otra vez. La vulnerabilidad no está en un plugin, en un tema ni en una configuración predeterminada anticuada. Está en el propio mecanismo de actualización, lo que significa que aplicar el parche a un sitio vulnerable es precisamente el momento en que más expuesto está. Es el equivalente en seguridad a un truco de speedrun en el que la única forma de pasar al jefe es atravesar un muro que se vuelve intangible durante un instante: si la petición de un atacante cae dentro de esa ventana, obtiene ejecución arbitraria de código en tu máquina. Las agencias del Poder Ejecutivo Civil Federal tienen hasta el 6 de noviembre de 2026 para remediarla según la Directiva Operativa Vinculante 26-04. Todos los demás deberían tratar esa fecha como su propio plazo.

Cómo funciona aquí la primitiva TOCTOU

Los fallos TOCTOU son un género clásico: un programa comprueba una condición (el momento de comprobación) y luego actúa sobre ella (el momento de uso), y un atacante que pueda cambiar el estado en medio gana la carrera. Piensa en las carreras del sistema de archivos con intercambios de enlaces simbólicos, solo que aquí el sistema de archivos es la raíz de tu web y el temporizador es una actualización del núcleo.

Según la información de The Hacker News, Wordfence dio a conocer los detalles del fallo la semana pasada. La explotación no requiere una cuenta en el sitio. Lo que sí requiere es sincronización: el atacante tiene que caer en una ventana breve durante una actualización completa del núcleo, cuando el proceso de actualización prepara archivos en rutas predecibles accesibles por web. La entrada de CISA en el KEV nombra específicamente «rutas de staging predecibles y accesibles por web usadas durante las actualizaciones completas del núcleo» como el problema de fondo, y señala las rutas del instalador setup-config.php preparadas como el objetivo observable.

El flujo del ataque, a nivel conceptual:

1. WordPress inicia una actualización completa del núcleo y descomprime la nueva versión en una ruta de staging con un nombre predecible, accesible por HTTP.
2. Antes de que la actualización termine y el área de staging se limpie o se bloquee, el atacante envía peticiones al instalador preparado (por ejemplo, un setup-config.php en staging), compitiendo efectivamente con el paso de limpieza.
3. Si la petición cae dentro de la ventana, el atacante ejecuta el código preparado con entradas controladas por él y consigue ejecución de código como el usuario del servidor web.
4. Post-explotación: webshell, robo de credenciales desde wp-config.php, movimiento lateral: el menú habitual.

«WordPress Core contiene una vulnerabilidad de condición de carrera de tipo time-of-check time-of-use (TOCTOU) que podría permitir a atacantes no autenticados ejecutar código en el servidor durante la ventana de actualización», afirmó CISA.

Qué está confirmado, qué se afirma y qué se desconoce

Confirmado: CISA incluye CVE-2026-119977 en el KEV basándose en evidencia de explotación activa, y el criterio propio del KEV para su inclusión es un identificador CVE, evidencia de explotación y una guía clara de mitigación. Los parches se publicaron a finales del mes pasado, según The Hacker News.

La telemetría dibuja un panorama muy activo. Wordfence afirma haber registrado más de 18.500 peticiones dirigidas a rutas del instalador «setup-config.php» preparadas en las primeras 21 horas tras la divulgación pública, y en el periodo de 24 horas más reciente, en el momento del informe, estaba bloqueando 12.632 intentos de explotación. Por otro lado, el operador de honeypots Previdian registró tres intentos de explotación desde una IP geolocalizada en el Reino Unido, observados el 30 de octubre de 2026. Es un volumen compatible con escáneres más atacantes, propio de un fallo que acaba de hacerse público y es trivial de lanzar en masa.

Desconocido: ninguna fuente atribuye la explotación a un grupo concreto, y ni CISA ni la prensa indican cuántos sitios han sido comprometidos de verdad frente a cuántos solo han sido sondeados. Considera la cifra de 18.500 como tráfico de ataque, no como brechas confirmadas. Tampoco está confirmado en las fuentes qué versiones del núcleo se ven afectadas, así que la suposición prudente es que cualquier instalación que no haya aplicado la versión parcheada de finales de octubre es vulnerable.

Comprobación de exposición: ¿estás en el radio de impacto?

El primer paso es aburrido y esencial: enumerar. WordPress funciona en una parte enorme de la web pública, y en cualquier organización de tamaño medio el riesgo real no es el sitio corporativo que conoces, sino el blog que un equipo de producto montó en 2023 y olvidó. Obtén las huellas de CMS de tus datos de superficie de ataque externa, de tus cuentas de hosting y de la configuración de tu CDN. Toda instancia autoalojada de WordPress que no esté en la versión parcheada del núcleo está dentro del alcance.

Segundo paso: determina cuáles de esas instancias realizan actualizaciones completas del núcleo a través de la web pública. Los sitios protegidos con modo de mantenimiento, los actualizados con WP-CLI mediante automatización de despliegue y los clientes de hosting gestionado cuyo proveedor se encarga de las actualizaciones del núcleo tienen una ventana mucho menor. El caso de pesadilla es un sitio público donde alguien hace clic en «Actualizar ahora» en wp-admin mientras internet mira.

Detección: las peticiones cuentan la historia

Lo bonito de este fallo, desde la perspectiva del defensor, es que la explotación se oye en los registros. Los atacantes deben solicitar la ruta del instalador preparado mientras existe, y setup-config.php simplemente no debería recibir tráfico externo en un sitio maduro. Busca retroactivamente en tus registros de acceso alrededor de cualquier ventana de actualización reciente:

# Find requests hitting staged installer paths
grep -E 'setup-config\.php' /var/log/nginx/access.log* | grep -v ' 404 '
# Correlate with your upgrade windows: who requested it, and did they POST?
awk '$7 ~ /setup-config/ {print $1, $4, $6, $7, $9}' /var/log/nginx/access.log*

Un GET que devuelve 404 es ruido de fondo: internet escanea todo. ¿Un POST a esa ruta que devolvió 200, desde una IP que no es tuya, durante una ventana en la que estabas actualizando? Ese es tu incidente. Sigue el hilo: revisa si hay archivos PHP creados recientemente bajo la raíz web, usuarios administradores inesperados, un wp-config.php modificado y conexiones salientes desde el servidor web posteriores a esa marca de tiempo. Es la misma comprobación de compromiso posterior al parche que la BOD 26-04 ahora exige explícitamente a las agencias: parchea primero, y luego verifica que el parche no se aplicó sobre una máquina que ya estaba comprometida.

Mitigación: reduce la ventana y luego ciérrala

La solución definitiva es la versión parcheada del núcleo, y eso va primero: la guía del KEV de CISA es priorizar la remediación de las vulnerabilidades listadas, sin más. Pero como este fallo convierte la actualización en la superficie de ataque, cómo parcheas importa:

• Parchea de inmediato a la versión del núcleo de finales de octubre, pero hazlo con deliberación, no con un clic casual en un sitio público con mucho tráfico.
• Actualiza fuera de banda siempre que sea posible: usa WP-CLI desde el servidor (wp core update) o tu pipeline de CI/CD en lugar del actualizador activado desde la web. Sin ventana web, sin carrera web.
• Saca el sitio de la ruta pública durante las actualizaciones: activa un modo de mantenimiento que devuelva 503 a todos excepto a las IP de administración, o restringe temporalmente el acceso en el balanceador de carga.
• Deniega el acceso web a las rutas de staging e instalador en el WAF o a nivel de servidor como control compensatorio: un setup-config.php preparado que devuelva 403 es un callejón sin salida para la carrera.
• Busca tras parchear: revisa los registros en busca de accesos previos a las rutas del instalador preparadas, e inspecciona si hay webshells y cuentas no autorizadas antes de dar el asunto por cerrado.

La lección mayor para las operaciones de CMS

El problema más profundo es arquitectónico: un proceso de actualización que descomprime código ejecutable en una ubicación predecible y accesible por web es una invitación permanente. La postura correcta a largo plazo es tratar las actualizaciones como despliegues, no como clics: descarga la versión, prepárala fuera de la raíz web, cámbiala de forma atómica y nunca permitas que el instalador sea accesible para extraños. Es lo mínimo exigible en los problemas del ecosistema PHP que ya hemos cubierto, como los fallos PHP previos a la autenticación que pusieron contrarreloj a gran parte de la web.

Enhorabuena a Wordfence por la divulgación y la telemetría, y a Previdian por la confirmación con honeypots. Ahora ve a parchear, con cuidado, y revisa los registros mientras se ejecuta el actualizador.