Más de 18.500 intentos de explotación en 21 horas revelan una ventana de exposición estructural en el proceso de actualización del CMS más usado del mundo
Una vulnerabilidad crítica en WordPress que permite ejecución remota de código durante el proceso de actualización del núcleo del sistema ya está siendo explotada de forma activa. La Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) incorporó la falla CVE-2026-119977 a su catálogo de vulnerabilidades explotadas conocidas (KEV) y ordenó a las agencias federales corregirla antes del 6 de noviembre de 2026. Wordfence, proveedor de seguridad especializado en WordPress, registró el primer intento de explotación apenas nueve minutos después de desplegar su regla de firewall, y contabilizó más de 18.500 solicitudes dirigidas a rutas de staging vulnerables en las primeras 21 horas. La falla afecta versiones de WordPress desde la 4.7 hasta la 7.1.3, y fue corregida en la versión 7.1.4.
Cómo una condición de carrera en directorios de staging abre la puerta a atacantes no autenticados
CVE-2026-119977 tiene un puntaje CVSS de 8.1 y surge de una debilidad en el diseño del proceso de actualización del núcleo de WordPress. Durante las actualizaciones, el sistema crea directorios de staging con nombres predecibles y accesibles públicamente desde la web. Un atacante no autenticado puede explotar una condición de carrera — una ventana temporal en la que el sistema está en un estado intermedio vulnerable — para ejecutar código malicioso en el servidor mientras la actualización está en curso. La explotación exitosa permite comprometer completamente el sitio afectado sin necesidad de credenciales previas.
La telemetría de Wordfence muestra que los atacantes están probando múltiples variaciones de nombres de directorios de staging y versiones para maximizar las probabilidades de interceptar la ventana de actualización. Dos de las fuentes de ataque más grandes sondearon grupos pequeños de sitios de forma repetida durante aproximadamente 14.5 horas, un patrón consistente con intentos de capturar la breve ventana de actualización. Las cifras documentan intentos de explotación, no compromisos confirmados, pero la velocidad de adopción del exploit — nueve minutos desde el despliegue de la regla de firewall hasta el primer intento — indica que el conocimiento técnico de la falla ya circula entre actores de amenaza.
Por qué México, Brasil y Argentina quedan expuestos por su dependencia masiva de WordPress
WordPress alimenta más del 43% de todos los sitios web a nivel global, y en América Latina esa proporción es similar o superior en sectores clave como medios de comunicación, comercio electrónico y gobierno local. México, Brasil y Argentina concentran la mayor cantidad de instalaciones de WordPress en la región, muchas de ellas en infraestructuras de pequeñas y medianas empresas que carecen de equipos de seguridad dedicados. La naturaleza de CVE-2026-119977 — que no requiere autenticación previa y explota un proceso automatizado que ocurre en segundo plano — la convierte en un vector especialmente peligroso para organizaciones que aplican actualizaciones sin supervisión técnica continua.
Aunque no hay datos públicos de explotación exitosa específica en LATAM hasta el momento, la exposición estructural es clara: cualquier sitio WordPress en la región que ejecute versiones entre 4.7 y 7.1.3 y que inicie una actualización del núcleo durante el período de escaneo activo queda expuesto a la condición de carrera. La ventana de vulnerabilidad es breve — dura solo mientras la actualización está en progreso — pero los atacantes están sondeando de forma continua para interceptar ese momento preciso. La falta de visibilidad sobre cuándo ocurren las actualizaciones en sitios sin monitoreo profesional amplifica el riesgo.
El patrón de explotación inmediata que CISA ya había visto en otras fallas de WordPress
La inclusión de CVE-2026-119977 en el catálogo KEV de CISA responde a evidencia de explotación activa en estado salvaje, no a una evaluación teórica de riesgo. Según la Directiva Operativa Vinculante (BOD) 22-01, las agencias federales del gobierno de Estados Unidos (FCEB) tienen hasta el 6 de noviembre de 2026 para aplicar el parche. Esta directiva, emitida en 2021, obliga a las agencias a corregir vulnerabilidades del catálogo KEV dentro de plazos específicos para proteger sus redes contra ataques que explotan fallas conocidas. Aunque la directiva aplica solo a entidades federales estadounidenses, CISA recomienda explícitamente que organizaciones privadas revisen el catálogo y aborden las vulnerabilidades en su propia infraestructura.
El patrón de explotación inmediata posterior a la publicación de un parche es recurrente en el ecosistema WordPress. La combinación de una base de instalación masiva, actualizaciones no siempre inmediatas y la disponibilidad pública de detalles técnicos tras el lanzamiento de un parche crea una ventana de oportunidad para atacantes que pueden automatizar escaneos a escala. En este caso, la velocidad de respuesta — nueve minutos desde el despliegue de la regla de firewall hasta el primer intento — sugiere que actores de amenaza monitoreaban activamente los anuncios de seguridad de WordPress y tenían exploits listos para desplegar.
Qué significa que Wordfence registre 18.500 intentos pero ningún compromiso confirmado
Las cifras de Wordfence documentan solicitudes dirigidas a rutas de instalación de staging vulnerables, no compromisos exitosos. Esto no significa que no haya ocurrido ninguna explotación exitosa — solo que Wordfence, como proveedor de firewall, puede contar intentos bloqueados pero no tiene visibilidad sobre sitios sin su protección que hayan sido comprometidos. La ausencia de reportes públicos de compromisos confirmados puede deberse a varios factores: la ventana de explotación es extremadamente breve y requiere sincronización precisa, muchos sitios ya aplicaron el parche antes de ser sondeados, o los compromisos exitosos aún no han sido detectados por los administradores de los sitios afectados.
La naturaleza de la condición de carrera hace que la explotación exitosa dependa de timing: el atacante debe enviar la solicitud maliciosa exactamente durante el proceso de actualización, que puede durar solo segundos. Los patrones de sondeo repetido durante 14.5 horas que Wordfence observó en dos fuentes principales son consistentes con intentos de maximizar las probabilidades de interceptar esa ventana. La falta de confirmación de compromisos no reduce la gravedad de la falla — solo refleja las limitaciones de visibilidad en un ecosistema descentralizado como WordPress.
Nuestro análisis
CVE-2026-119977 expone un problema de diseño estructural en el proceso de actualización de WordPress que va más allá de un bug puntual: el uso de directorios de staging con nombres predecibles y accesibles públicamente durante actualizaciones del núcleo crea una superficie de ataque inherente que solo puede mitigarse mediante cambios arquitectónicos, no solo mediante parches reactivos. La velocidad de adopción del exploit — nueve minutos desde la publicación de la regla de firewall hasta el primer intento — confirma un patrón ya documentado en vulnerabilidades anteriores de WordPress: actores de amenaza monitoreando anuncios de seguridad y desplegando exploits automatizados antes de que la mayoría de los sitios apliquen parches. La inclusión en el catálogo KEV de CISA y la orden de corrección en 24 horas para agencias federales reflejan que la explotación activa ya está ocurriendo, aunque la falta de reportes públicos de compromisos confirmados sugiere que la ventana de explotación — breve y dependiente de timing preciso — está limitando el impacto observable hasta ahora.
Lo que todavía no se sabe es cuántos sitios WordPress en América Latina ejecutaron actualizaciones durante el período de escaneo activo sin protección de firewall y quedaron expuestos a la condición de carrera sin que sus administradores lo detectaran. La dependencia masiva de WordPress en sectores críticos de la región — medios, comercio electrónico, gobierno local — combinada con la falta de equipos de seguridad dedicados en muchas organizaciones pequeñas y medianas, crea un escenario donde compromisos exitosos podrían permanecer sin detectar durante semanas o meses. ¿Cuántos sitios en LATAM están ejecutando versiones vulnerables sin visibilidad sobre si fueron sondeados durante una actualización, y cuánto tiempo pasará antes de que un compromiso exitoso se manifieste en un incidente público?