CISA marca como explotada la falla de WordPress que ataca justo mientras actualizas: bloquea wp-content/upgrade antes de pasar a 7.1.4

El momento más peligroso para tu sitio puede ser el de actualizarlo. La agencia de ciberseguridad de Estados Unidos (CISA) agregó este martes 3 de noviembre de 2026 la CVE-2026-119977 de WordPress a su catálogo de vulnerabilidades explotadas (KEV), con plazo al viernes 6 de noviembre para que las dependencias federales la atiendan. El plazo obliga solo al gobierno estadounidense, pero la inclusión en KEV significa que hay evidencia de explotación real.

La falla ya tiene parche desde el 28 de octubre (WordPress 7.1.4). Lo inusual es dónde está el riesgo: en el proceso de actualización del core. Si tu sitio todavía no se actualiza, el paso que lo arregla es el mismo que abre la ventana. Por eso conviene hacerlo en orden.

Qué es la CVE-2026-119977

Según el aviso de seguridad de WordPress (GHSA-4w3m-c66w-69mg, publicado el 29 de octubre), cuando el sitio se actualiza con el paquete completo, WordPress extraía los archivos nuevos en una carpeta predecible dentro de wp-content/upgrade/, que es accesible desde internet. Un atacante sin usuario ni contraseña que alcance esos archivos antes de que termine la extracción puede ejecutar código en el servidor.

CISA la describe como una condición de carrera de tipo time-of-check time-of-use (CWE-367). Según Daily Security Review, el archivo que buscan los atacantes es el instalador setup-config.php en esa ruta temporal, y en pruebas de laboratorio la ventana dura segundos. Para ganar la carrera, los atacantes consultan los sitios una y otra vez esperando el momento de una actualización.

Las dos calificaciones no coinciden porque miden cosas distintas: WordPress pesa que la ventana es muy corta; Wordfence, que el resultado es ejecución remota sin autenticación. Con la entrada al KEV, nosotros la trataríamos como urgente.

La evidencia de ataques

Wordfence registró más de 18,500 solicitudes maliciosas contra rutas del instalador temporal en las primeras 21 horas después de liberar su regla de firewall, según Daily Security Review y el rastreador de HOL Guard. Son intentos, no sitios comprometidos confirmados: hasta donde pudimos revisar, Wordfence no ha publicado cuántos sitios fueron tomados. CISA tampoco describe víctimas concretas, pero marcó la entrada con triage forense: no basta con parchar, hay que revisar si hubo intrusión.

Cómo actualizar sin abrirle la puerta al atacante

La corrección de 7.1.4 hace aleatorio el nombre de la carpeta temporal y le agrega protección, pero la actualización que instala 7.1.4 todavía corre con el actualizador viejo, como advierte el rastreador de HOL Guard. El orden importa:

1. Respaldo completo de archivos y base de datos antes de tocar nada.
2. Bloquea el acceso web a wp-content/upgrade/ en el servidor. Según HOL Guard, los servidores que ya negaban ese acceso antes de su última actualización no eran alcanzables por la carrera. En Nginx:

   location ^~ /wp-content/upgrade/ { deny all; }
   

   
   En Apache, un archivo .htaccess dentro de esa carpeta con Require all denied. WordPress sigue escribiendo ahí; lo que se impide es que alguien lo pida desde internet. Si tu hosting es administrado y no tienes acceso a esa configuración, pídeselo hoy a tu proveedor.
3. Actualiza desde Escritorio > Actualizaciones a 7.1.4 o a la versión corregida de tu rama (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11… hasta 4.7.39, según el aviso de WordPress).
4. Confirma el número de versión al terminar. WordPress dice que los sitios con actualizaciones automáticas en segundo plano se actualizan solos, pero como te contamos con la falla de septiembre que llevó a 7.1.2, muchos hostings, temas o plugins las tienen apagadas.

Si tu sitio se despliega con Git, Composer o contenedores y tiene DISALLOW_FILE_MODS activado, el actualizador interno nunca corre y no tuvo esa ventana; aun así necesitas el código corregido en tu próximo despliegue.

Si ya actualizaste en los últimos días

Que ya estés en 7.1.4 no prueba que la actualización haya sido limpia. Revisa:

• Registros de acceso del servidor alrededor de la hora de tu última actualización del core: solicitudes a archivos .php dentro de wp-content/upgrade/, sobre todo a setup-config.php.
• Usuarios administradores que no reconozcas.
• Archivos PHP nuevos en wp-content/uploads, plugins o temas que nadie instaló.
• Plugins que no reconozcas en la lista.

Si encuentras algo, no basta con borrar el archivo: cambia contraseñas de administradores y de la base de datos, rota las claves de wp-config.php y restaura desde un respaldo previo a la fecha sospechosa.

Qué más corrige 7.1.4

El mismo paquete del 28 de octubre corrige varias fallas de XSS almacenado (Interactivity API, Customizer, bloques de categorías, listas de reproducción, imágenes y paginación de comentarios, entre otras), una de denegación de servicio y la exposición de borradores del Customizer a usuarios sin sesión. También actualiza los certificados raíz incluidos por la revocación de eMudhra. WordPress 7.2 está planeado para el 8 de diciembre.

Por qué le importa a una PyME

Muchas empresas mexicanas tienen su página, su catálogo o su tienda en WordPress y nadie asignado a mantenerla. Es otra alerta seria de WordPress en apenas dos meses, después de la falla crítica de septiembre, la cadena de suministro de Brevo que sirvió malware en 100,000 sitios y la actualización envenenada de Rank Math SEO PRO. Si vendes en línea, la temporada alta ya empezó: un sitio comprometido en noviembre cuesta ventas y datos de clientes. Ya lo vimos con la falla de Adobe Commerce previa al Buen Fin.

Lo mínimo: alguien con nombre y apellido responsable de las actualizaciones, respaldo antes de cada una y un firewall de aplicación web frente al sitio.

Fuentes: catálogo KEV de CISA (3-nov-2026), aviso GHSA-4w3m-c66w-69mg de WordPress (29-oct-2026), anuncio de WordPress 7.1.4 (28-oct-2026), Daily Security Review (30-oct-2026) y HOL Guard (3-nov-2026).