Algunos sitios de WordPress pueden quedar expuestos durante la instalación del parche para una vulnerabilidad que ya está siendo explotada. El investigador que descubrió la falla advierte que la primera actualización puede usar todavía el código vulnerable del sitio. Wordfence recomienda proteger el directorio temporal antes de actualizar y aplicar la corrección sin demora.
El problema, identificado como CVE-2026-119977, afecta el proceso de actualización del núcleo del gestor. Si un atacante alcanza ciertos archivos temporales en el momento preciso, podría ejecutar código en el servidor sin tener una cuenta previa en el sitio. No es una exposición permanente: depende de las condiciones del sitio y de que el ataque coincida con la actualización.
WordPress publicó el 28 de octubre de 2026 la versión 7.1.4 con una corrección. También adaptó el parche para ramas antiguas hasta la 4.7. Su aviso de seguridad detalla las versiones afectadas y las corregidas de cada rama; el proyecto recuerda que solo la versión más reciente recibe soporte activo.
Por qué la primera actualización aún puede ser vulnerable
Al instalar un paquete completo, WordPress descomprime una copia temporal de sus archivos. Si esa copia incluye el instalador y el servidor permite acceder a él desde internet, puede abrirse una ventana de ataque mientras dura el proceso. La falla fue reportada por Umut Bayram, investigador de Picus Security.
El parche cambia la forma de crear el directorio temporal. Pero, para llegar a él desde una instalación vulnerable, primero interviene el actualizador que ya estaba instalado. Bayram explicó a The Hacker News que esto puede dejar expuestos algunos sitios una vez más durante la instalación de la corrección.
Hay una distinción: parte del arreglo ya impide que un archivo de configuración temporal sustituya al del sitio durante esa primera actualización. Aun así, Bayram advierte que una copia temporal accesible podría permitir la ejecución de código antes de que se elimine.
No todas las actualizaciones presentan las mismas condiciones. Los paquetes completos incluyen el instalador; los parciales contienen únicamente archivos que cambiaron y solo lo exponen si incluyen los archivos necesarios, explicó el investigador al medio. WordPress puede recurrir a un paquete completo si los archivos del núcleo no coinciden con las comprobaciones oficiales o si se reinstala el sistema.
Las actualizaciones automáticas también usan el actualizador del sitio. Una vez instalada la versión corregida de la rama correspondiente, las actualizaciones posteriores utilizan el mecanismo corregido, de acuerdo con Wordfence y The Hacker News.
Cómo reducir la exposición antes de actualizar
Bayram recomienda impedir desde el servidor web el acceso público al directorio wp-content/upgrade antes de instalar la corrección. WordPress utiliza esa carpeta en el disco durante el proceso; la medida busca evitar que sus archivos temporales queden disponibles desde internet.
La configuración concreta depende del servidor. El investigador advirtió a The Hacker News que colocar el archivo de restricción dentro de la propia carpeta temporal no resuelve el problema, porque el actualizador antiguo limpia su contenido antes de descomprimir los archivos. También describió una actualización manual fuera de la raíz pública del servidor como otra alternativa.
Wordfence aconseja comprobar que el sitio terminó en la versión corregida. Para las ramas 7.1, 7.0 y 6.9, el aviso de WordPress identifica como versiones con el parche la 7.1.4, la 7.0.8 y la 6.9.11, respectivamente. Las instalaciones más antiguas tienen que consultar la versión correspondiente a su rama. Las versiones 4.6 y anteriores no recibieron este parche; Bayram recomienda migrar a una versión con soporte.
La empresa de seguridad indicó que entregó una regla de protección a los usuarios de Premium, Care y Response el 28 de octubre y que prevé ofrecerla a los usuarios de la versión gratuita el 27 de noviembre. Wordfence precisa que su firewall debe estar optimizado y funcionar en el modo Extended Protection para inspeccionar las peticiones a esos archivos temporales.
Qué indican los intentos detectados
En su informe publicado el 5 de noviembre, Wordfence reportó más de 240,000 intentos de explotación bloqueados por su firewall desde la divulgación. El 30 de octubre concentró más de 74,000. La firma señala que muchas solicitudes probablemente fueron automatizadas para coincidir con el breve periodo de actualización.
Ese recuento mide intentos bloqueados por Wordfence y no equivale a 240,000 sitios comprometidos. La compañía recomienda revisar los registros del servidor y buscar cuentas de administrador, plugins o archivos inesperados; la ausencia de esas señales tampoco garantiza que no haya existido una intrusión.
La Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) incorporó la falla a su catálogo de vulnerabilidades explotadas el 3 de noviembre. Su ficha fijó el 6 de noviembre como fecha de remediación para las agencias federales civiles sujetas a su directiva y exige una revisión forense. Ese plazo no es una obligación general para todos los sitios de WordPress.
Wordfence asignó a la vulnerabilidad una puntuación de 8.1 sobre 10, considerada alta en la escala CVSS. El aviso del equipo de WordPress la clasifica como baja. Ambas fuentes coinciden en que el ataque depende de una ventana breve durante la actualización; no explican en sus fichas la diferencia entre sus clasificaciones.
