WordPress CVE-2026-119977: atacan el momento de la actualización; pasá a 7.1.4

CISA sumó el 3 de noviembre a su catálogo de vulnerabilidades explotadas CVE-2026-119977, una falla en el núcleo de WordPress que afecta a todas las versiones de la 4.7 a la 7.1.3. El plazo para las agencias federales de Estados Unidos es el 6 de noviembre, con triaje forense obligatorio. La ficha en NVD la describe así: "This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window."

La corrección salió el 28 de octubre en WordPress 7.1.4, junto con 24 versiones más para las ramas viejas, de la 7.0.8 a la 4.7.39. Los intentos empezaron enseguida. Según el análisis de Wordfence, su regla de firewall registró el primer intento 9 minutos después de activarse, y en las primeras 21 horas contó más de 18.500 pedidos al instalador temporal que deja la actualización.

La mayoría de los sitios debería recibir la corrección sola, por las actualizaciones automáticas. Lo que conviene hacer hoy es confirmar que llegó, cerrar una carpeta a la web y revisar los registros si el sitio estuvo sin parche.

¿Cómo funciona CVE-2026-119977 durante la actualización de WordPress?

Cuando WordPress se actualiza con el paquete completo, descomprime la versión nueva en una carpeta dentro de wp-content/upgrade/. Hasta la 7.1.3, el nombre de esa carpeta salía del nombre del paquete: se podía adivinar. Esa copia temporal es un WordPress entero, con su propio instalador. Y en muchos servidores, wp-content/upgrade/ se sirve por la web como cualquier otra carpeta.

Wordfence lo resume: un atacante sin cuenta "who requests the installer at precisely the right moment can interact with the staged WordPress copy and progress to PHP code execution". La ventana es corta: en sus pruebas de laboratorio, la copia temporal quedaba disponible unos segundos. Por eso los atacantes no mandan un pedido: lo repiten una y otra vez. Wordfence vio dos orígenes consultar los mismos grupos chicos de sitios durante unas 14,5 horas, esperando que alguno se actualizara.

La corrección se ve en el código. La 7.1.4 le agrega a la carpeta 16 caracteres al azar, deja un index.php para que no se pueda listar, y el paso final de la actualización ya no copia al sitio real ningún wp-config.php que esté en esa carpeta. El comentario que acompaña ese último cambio dice por qué: "Never copy a wp-config.php, which could have been written to the working directory."

Hay un detalle que ni WordPress ni Wordfence mencionan, y sale de leer el actualizador. La descompresión la hace el código de la versión instalada, no el de la nueva: el sitio que pasa de 7.1.3 a 7.1.4 descomprime con la carpeta predecible de la 7.1.3. Recién después carga el archivo de la versión nueva, que ya no copia el wp-config.php. Por eso conviene cerrar la carpeta a la web antes de actualizar, y no después.

¿Qué paquete baja un WordPress en español para pasar a 7.1.4?

Depende del idioma y de la versión de la que parte. La API de versiones de WordPress, consultada el 4 de noviembre para un sitio en 7.1.3, devuelve esto:

El paquete parcial trae solo los archivos que cambiaron, y el instalador no es uno de ellos. WordPress arma uno por cada versión anterior de la misma rama: de 7.1.0, 7.1.2 o 7.1.3 a 7.1.4, o de 7.0.7 a 7.0.8. Pero el actualizador lo usa solo si los archivos del núcleo coinciden con las sumas de verificación oficiales. Saltar de rama, por ejemplo de 7.0 a 7.1, baja un paquete que trae el instalador, y lo mismo pasa con el paquete completo en español o portugués y con un sitio de archivos modificados.

WordPress CVE-2026-119977: severidad baja para WordPress, 8,1 para Wordfence

Las tres calificaciones miden cosas distintas. WordPress la marcó "baja" en su aviso de GitHub, sin publicar un puntaje. Wordfence, que asignó el CVE, le dio 8,1 con complejidad de ataque alta (AC:H): el impacto es total, pero hay que ganar una carrera. Wordfence enumera las condiciones: una actualización con paquete completo, acceso web y de PHP a la carpeta temporal, un nombre de carpeta predecible o descubierto, y tiempo para terminar antes de que WordPress la borre.

CISA puso el foco en otro lado: explotación activa, impacto técnico total y un sitio web, que normalmente está expuesto a internet. Con esos tres datos, su directiva BOD 26-04 fija 3 días y triaje forense, el mismo criterio que se explicó en la nota sobre la falla de Ivanti Connect Secure. CISA no publica la evidencia que usó; lo que hay a la vista son los intentos de Wordfence, que la empresa presenta como bloqueados, no como compromisos confirmados.

¿Cómo sé si mi WordPress ya tiene la versión corregida?

1. En el panel. Entrá a Escritorio > Actualizaciones. Tiene que decir 7.1.4 o la versión corregida de tu rama: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 y así hasta 4.7.39. La lista completa está en el aviso de WordPress.
2. Por consola. Con WP-CLI, wp core version devuelve la versión instalada, y wp core verify-checksums confirma que los archivos del núcleo son los oficiales.
3. Si estás en 4.6 o anterior, no hay corrección: esas ramas ya no reciben parches. Hay que pasar a una versión con soporte.

¿Cómo sé si intentaron explotar CVE-2026-119977 en mi sitio?

WordPress nunca necesita que wp-content/upgrade/ se sirva por la web: escribe ahí directo en el disco. Así que cualquier pedido web a esa carpeta es sospechoso. En el registro de accesos del servidor, buscá pedidos a /wp-content/upgrade/, sobre todo a setup-config.php o install.php. En un servidor con acceso por consola, alcanza con grep "/wp-content/upgrade/" sobre el archivo de registro de accesos; en un hosting compartido, el panel suele dejar bajar ese registro.

Un pedido que recibió un 404 o un 403 no encontró nada. Uno que recibió 200 mientras el sitio se estaba actualizando es motivo de revisión completa:

• que wp-config.php siga apuntando a tu base de datos, con tu DB_HOST y tu DB_NAME;
• que no haya administradores nuevos: wp user list --role=administrator;
• que no haya plugins que no instalaste ni archivos PHP adentro de wp-content/uploads, como se explica en la nota sobre el formulario de Elementor Pro que subía un PHP;
• que wp core verify-checksums no marque archivos del núcleo cambiados.

¿Qué hago con CVE-2026-119977 si tengo WordPress?

1. Cerrá wp-content/upgrade/ a la web, antes de actualizar. Con WordPress en la raíz del dominio, en Apache o LiteSpeed, en el .htaccess de la raíz del sitio y antes del bloque de WordPress: RewriteRule ^wp-content/upgrade/ - [F,L], con RewriteEngine On arriba si no está. En nginx: location ^~ /wp-content/upgrade/ { deny all; }. No pongas el .htaccess adentro de wp-content/upgrade/: en las versiones afectadas, el actualizador vacía esa carpeta antes de cada actualización y lo borra.
2. Hacé una copia del sitio y actualizá. Pasá a 7.1.4 o a la versión corregida de tu rama, y comprobá el número en el panel. Si algo sale mal, la copia es lo que te devuelve el sitio; las opciones están en la comparativa de backup y recuperación.
3. Si el sitio lo administra tu hosting, preguntale dos cosas: si ya instaló la versión corregida, y si bloquea el acceso web a wp-content/upgrade/. Qué le toca al hosting y qué te toca a vos está en la guía sobre qué cubre el hosting en WordPress.
4. Si usás Wordfence gratis, no cuentes con el firewall. La regla llegó el 28 de octubre a los planes pagos y llega el 27 de noviembre a la versión gratis. Además, Wordfence aclara que solo sirve con la Extended Protection activa, porque el ataque pide un archivo PHP directo sin cargar WordPress. Y agrega: "Receiving the rule does not replace installing the security update."
5. Si el sitio estuvo sin parche y se actualizó en estos días, revisá los registros como se explica arriba. Wordfence pide además un escaneo completo después de actualizar.

Si además corrés una versión vieja de PHP, sumá las dos fallas críticas de PHP2Shell a la misma ventana de mantenimiento. Es la cuarta falla del núcleo de WordPress que entra al catálogo de CISA en 2026, y la segunda en poco más de un mes: la anterior fue CVE-2026-87902, corregida en la 7.1.2. Para comparar hostings que administran WordPress está la categoría de hosting y nube.

¿Quién puede ignorar CVE-2026-119977?

Quien no tenga sitios con WordPress. Y quien ya esté en una versión corregida, con el registro de accesos sin pedidos a /wp-content/upgrade/ desde el 28 de octubre. Si tu servidor ya bloqueaba esa carpeta a la web, la condición que pide la falla no se daba; igual conviene actualizar, porque la 7.1.4 corrige otras 21 vulnerabilidades, según el recuento que cita Wordfence.

Fuentes leídas: la ficha de NVD con el registro de Wordfence como autoridad de numeración; la entrada del catálogo de CISA; el anuncio de WordPress 7.1.4 y su aviso de seguridad en GitHub; el análisis de Wordfence del 29 de octubre; el código de class-wp-upgrader.php, class-core-upgrader.php y update-core.php en las versiones 7.1.3, 7.1.4, 6.9.10, 6.9.11, 4.7.38 y 4.7.39; la API de versiones de WordPress para siete idiomas y cinco versiones de partida; y el contenido de los paquetes parcial, sin contenido y completo en español de México. Sin confirmar: si algún intento terminó en un sitio comprometido, porque CISA no publicó su evidencia y Wordfence habla de pedidos bloqueados; y si la actualización a 7.1.4 desde una versión afectada es aprovechable en la práctica, que es una lectura del código y no algo que WordPress o Wordfence hayan dicho.

Preguntas frecuentes sobre CVE-2026-119977 y WordPress 7.1.4

¿Qué versión de WordPress corrige CVE-2026-119977?

La 7.1.4, publicada el 28 de octubre de 2026. Para las ramas anteriores, la versión corregida de cada una: 7.0.8, 6.9.11, 6.8.12, 6.7.11 y así hasta la 4.7.39. La 4.6 y las anteriores no reciben la corrección.

¿Si WordPress se actualiza solo, ya estoy protegido?

Lo más probable es que sí, pero hay que comprobarlo en Escritorio > Actualizaciones. Wordfence recomienda no darlo por hecho. Y si el sitio se actualizó con un paquete completo antes de que cerraras wp-content/upgrade/, revisá el registro de accesos de esos días.

¿Hace falta una cuenta en el sitio para explotar CVE-2026-119977?

No. Alcanza con pedir el instalador temporal en el momento justo, por eso los atacantes consultan los mismos sitios durante horas. La ventana dura unos segundos, según las pruebas de Wordfence.

¿Por qué WordPress dice que la severidad es baja?

WordPress no publicó el razonamiento. Wordfence explica la dificultad: hay que ganar una carrera de segundos y se dan cuatro condiciones a la vez. Le dio 8,1 porque el resultado es ejecutar código en el servidor. CISA la sumó al catálogo de explotadas con plazo de 3 días.

¿Me protege Wordfence gratis contra CVE-2026-119977?

Todavía no. La regla llega a la versión gratis el 27 de noviembre de 2026, y solo funciona con la Extended Protection activa. La protección real es actualizar y bloquear el acceso web a wp-content/upgrade/.