La falla de WordPress que se abre durante las actualizaciones del núcleo ya está en explotación activa. La CISA, la agencia de ciberseguridad del gobierno de Estados Unidos, la sumó el 3 de noviembre a su catálogo de vulnerabilidades explotadas, y las agencias federales tienen hasta el viernes 6 de noviembre para dejar sus sistemas corregidos.
El cambio de categoría es el dato. El 30 de octubre, esta misma debilidad se contaba como una oleada de intentos: Wordfence bloqueó 62.969 ataques en 24 horas y el fallo ni siquiera tenía identificador oficial, como quedó contado en el fallo de WordPress que permite ejecución remota de código. Hoy el panorama es otro. El registro CVE-2026-119977 se publicó el 31 de octubre y la CISA afirma que la entrada en su catálogo se basa en evidencia de explotación activa, no en sospechas.
La directiva que mueve el plazo se llama BOD 26-04. Obliga a las agencias civiles federales y trae una exigencia extra que cualquier empresa debería copiar: comprobar si el sistema ya estaba comprometido antes de que llegara el parche. La agencia pidió además a los defensores de redes del sector privado que traten esta corrección como prioridad, aunque la orden formal solo cubra al gobierno. Para un medio local, una tienda en línea o la página de un bufete, el tamaño del sitio da igual: comparten el mismo núcleo y la misma ventana de segundos.
Una ventana de segundos dentro de wp-content/upgrade
El fallo vive en el propio mecanismo de actualización. Cuando WordPress instala un paquete completo, descomprime la copia nueva en una carpeta temporal de ruta predecible dentro de wp-content/upgrade, y esa copia incluye el instalador. Un atacante sin cuenta que pida el archivo setup-config.php justo en esos segundos puede terminar ejecutando código en el servidor. Es una condición de carrera de tipo TOCTOU (time-of-check time-of-use): algo cambia entre la comprobación y el uso, y el atacante se cuela en ese hueco.
Las versiones afectadas van de la 4.7 a la 7.1.3. Wordfence, la firma que asignó el CVE, lo puntuó 8,1 sobre 10 en la escala CVSS (Common Vulnerability Scoring System), con complejidad de ataque alta por lo estrecha que es la ventana; el aviso de seguridad del propio WordPress lo califica de gravedad baja. Las dos lecturas conviven: acertar el momento es difícil, pero el premio para quien acierta es el control del servidor. El fallo lo reportó Umut Bayram, investigador de Picus Security, y la corrección llegó el 28 de octubre con WordPress 7.1.4, que aleatoriza la carpeta temporal y le añade una guarda de índice. Hay versiones corregidas para cada rama hasta la 4.7; la 4.6 y las anteriores se quedan sin nada.
Los atacantes no esperaron al catálogo. Wordfence desplegó su regla de cortafuegos el 28 de octubre a las 20:30 UTC, unas tres horas después del anuncio, y la primera petición que la activó llegó nueve minutos más tarde. En las primeras 21 horas contó más de 18.500 peticiones contra las rutas del instalador, con dos fuentes que sondearon grupos pequeños de sitios durante unas 14,5 horas, como quien vigila una puerta esperando a que alguien la abra. En la actualización del aviso publicada el fin de semana, la firma contó 13.095 ataques bloqueados en 24 horas. Ninguna de esas cifras equivale a sitios caídos: Wordfence no ha reportado una sola intrusión consumada por esta vía.
Qué revisar antes del viernes en cualquier sitio WordPress
La comprobación toma un minuto: en Escritorio, Actualizaciones, la versión instalada debe ser la 7.1.4 o la corregida de su rama. Las actualizaciones automáticas en segundo plano ya movieron a la mayoría de los sitios, pero la orden de la CISA parte de no darlo por hecho y verificarlo a mano. Quien use la versión gratuita de Wordfence no debe confiarse al cortafuegos: su regla contra este fallo llega el 27 de noviembre, casi un mes después que la de los clientes de pago, y la petición maliciosa va directa a un archivo PHP sin cargar WordPress, así que solo la intercepta el modo de protección extendida.
Toca buscar además en los registros del servidor. Peticiones a archivos PHP dentro de wp-content/upgrade, cuentas de administrador que nadie reconozca y extensiones recién aparecidas son las tres señales que la propia Wordfence recomienda rastrear en sitios que pasaron días sin corregir. Esa revisión es la parte forense que la directiva BOD 26-04 quiere ver cumplida dentro del plazo, y conservar los registros antes de limpiar nada forma parte del trabajo.
Queda una ironía práctica: actualizar a la 7.1.4 también abre la ventana una última vez, porque el paquete lo descomprime el código viejo. Mejor hacerlo hoy, con el sitio vigilado, que el viernes con las prisas del plazo. Los sitios que ya corrieron la actualización automática solo tienen pendiente la verificación de la versión y esa ojeada a los registros del servidor. La CISA no ha dicho quién está explotando la falla de WordPress ni cuántos sitios han caído, y su ficha marca como desconocido el uso en ataques de ransomware. El 6 de noviembre, en cambio, está escrito en el catálogo.
Fuente: BleepingComputer
