El investigador que descubrió el fallo de WordPress que ya se está atacando avisa de que la propia actualización que lo corrige deja una última ventana abierta. Afecta a las webs que siguen en una versión entre la 4.7 y la 7.1.3. La solución es cerrar el acceso a una carpeta antes de pulsar «Actualizar ahora».
Lo que se sabe
- El fallo de fondo: según el aviso de WordPress en GitHub (29 de octubre), durante una actualización del núcleo con el paquete completo WordPress descomprimía los archivos nuevos en una carpeta predecible y accesible desde internet. Un atacante sin cuenta que llegue a tiempo podría ejecutar código en el servidor. Se corrigió en WordPress 7.1.4 y en una versión por cada rama, hasta la 4.7.39.
- Ya hay ataques: la agencia de ciberseguridad de EE. UU. (CISA) añadió el fallo, CVE-2026-119977, a su catálogo de vulnerabilidades explotadas el 3 de noviembre.
- Lo nuevo: Umut Bayram, de Picus Security, explica en su análisis (actualizado el 5 de noviembre) que una actualización usa código de dos versiones. La descompresión la hace el actualizador que ya está instalado, es decir, el viejo. Por eso, en el salto de una versión vulnerable a la corregida, la carpeta temporal sigue siendo predecible.
- Qué puede pasar en ese salto: según el investigador, el atacante ya no puede sustituir la configuración de la web, porque esa parte del arreglo sí funciona desde el primer momento. Pero aún podría ejecutar código en el servidor, con los permisos de la web, mientras dura la actualización.
- Qué recomienda: bloquear el acceso web a la carpeta wp-content/upgrade/ y comprobar que responde con un error 403 antes de actualizar; o actualizar a mano, descomprimiendo el paquete fuera de la carpeta pública. Avisa de que el comando wp core update de WP-CLI no evita el problema, porque usa el mismo actualizador.
- La nota de gravedad sigue dividida: el aviso de WordPress lo califica de gravedad baja; Wordfence le da 8,1 sobre 10.
Qué cambia y qué no
- Cambia el orden de los pasos. Hasta ahora el consejo era «actualiza ya». Para una web que sigue sin parchear, ahora es «cierra la carpeta y después actualiza».
- No cambia el arreglo. No hay versión nueva: la corrección sigue siendo la 7.1.4 o la versión corregida de tu rama.
- Después del salto, el riesgo baja. Según el investigador, una vez instalada la versión corregida, las actualizaciones siguientes usan una carpeta temporal con nombre aleatorio.
- Lo que no dice la fuente: no habla de las actualizaciones automáticas en segundo plano ni da cifras de cuánto dura la ventana.
Qué hacer según tu caso
- Mira tu versión en Escritorio → Actualizaciones. Si ya dice 7.1.4 o la versión corregida de tu rama, el salto ya ocurrió: revisa si hubo intrusión con los pasos de la noticia relacionada de abajo, sobre todo si la web se actualizó a mano o tarde.
- Si todavía no está al día, no pulses «Actualizar ahora» todavía. Haz antes una copia de seguridad completa (archivos y base de datos).
- Cierra la carpeta. En un hosting compartido, lo habitual es poder editar el archivo .htaccess de la raíz de WordPress. El investigador propone añadir, encima del bloque de reglas de WordPress, la línea `RedirectMatch 403 ^/wp-content/upgrade/`. Su artículo trae también la regla para nginx y para la configuración de Apache. No crees un .htaccess dentro de la propia carpeta: el actualizador viejo la vacía antes de descomprimir.
- Comprueba desde el navegador. Abre tudominio.com/wp-content/upgrade/. Tiene que salir un error 403 («Forbidden» o «Prohibido»). Si sale otra cosa, la regla no está funcionando: no actualices aún.
- Actualiza a la 7.1.4 o a la versión corregida de tu rama. Según el investigador, WordPress nunca necesita servir esa carpeta por la web, así que la regla no rompe las actualizaciones siguientes.
- Si no puedes tocar el servidor, pregunta por escrito a tu hosting: «¿Bloqueáis el acceso web a wp-content/upgrade/ antes de actualizar WordPress? ¿Qué versión tiene mi web y cuándo se actualizó?».
Relacionado: WordPress: atacan un fallo de la actualización del núcleo
Fuentes
- Picus Security, Umut Bayram, «CVE-2026-119977: When Updating WordPress Becomes the Vulnerability», actualizado el 5 de noviembre de 2026 (en inglés)
- WordPress, aviso GHSA-4w3m-c66w-69mg en GitHub, 29 de octubre de 2026 (en inglés)
- CISA, «CISA Adds One Known Exploited Vulnerability to Catalog», 3 de noviembre de 2026 (en inglés)
- The Hacker News, 6 de noviembre de 2026 (en inglés)
Actualizaciones: si WordPress publica una medida oficial para el salto a la versión corregida, se añadirá aquí con su enlace.