El investigador Umut Bayram de Picus Security descubrió una falla crítica identificada como CVE-2026-119977. El problema radica en el proceso de actualización del núcleo de WordPress, que durante la descompresión de un paquete completo crea una carpeta temporal dentro de wp-content/upgrade. En versiones entre 4.7 y 7.1.3, el nombre de esa carpeta se genera a partir del nombre del archivo descargado, lo que la hace predecible y accesible vía web.
Un atacante que logre determinar la ruta exacta y acceder al instalador (wp-admin/setup-config.php) antes de que WordPress elimine la carpeta temporal puede ejecutar código PHP con los privilegios del servidor web. La vulnerabilidad se clasifica como una condición de carrera TOCTOU, ya que el sistema verifica la ausencia de wp-config.php en el paquete antes de copiarlo, pero la verificación se hace con el código anterior a la actualización, mientras que la copia final se realiza con el código ya parcheado.
¿Cómo se explotó la falla?
El CISA incluyó la vulnerabilidad en su catálogo de vulnerabilidades explotadas earlier this week. Wordfence observó intentos de acceso nine minutes after it deployed a firewall rule for the flaw on the day of the release, y reportó que dos fuentes de ataque mantuvieron la actividad durante about 14.5 hours. En los análisis internos del equipo de seguridad, el intervalo útil para aprovechar la vulnerabilidad se reducía a seconds, lo que evidencia la naturaleza efímera pero peligrosa del vector de ataque.
Aunque no se han confirmado compromisos definitivos, la alta clasificación 8.1 en la escala CVSS muestra el potencial de daño si un atacante logra ejecutar su código. El exploit publicado en repositorios públicos de GitHub reproduce la lógica del atacante: localizar la carpeta predecible, lanzar peticiones al instalador y, si tiene éxito, sobrescribir el archivo wp-config.php real con una versión manipulada que apunta a una base de datos controlada por el atacante.
Medidas de mitigación recomendadas
La solución oficial llegó en la versión 7.1.4 y en ramas paralelas corregidas hasta 4.7. El parche introduce un sufijo aleatorio de 16 caracteres en el nombre de la carpeta temporal y evita la copia de wp-config.php desde el directorio de actualización. Sin embargo, la simple actualización no elimina el riesgo de exposición mientras el proceso se ejecuta. Se aconseja bloquear el acceso web a wp-content/upgrade mediante la configuración del servidor.
En Nginx la directiva recomendada es:location ^~ /wp-content/upgrade/ { deny all; }
En Apache se puede aplicar dentro del bloque <Directory> la sentencia:Require all denied
Si sólo se dispone de .htaccess, añada:RedirectMatch 403 ^/wp-content/upgrade/
Es importante colocar la regla en la raíz del sitio, antes de las reglas de reescritura de WordPress, y comprobar que una solicitud a /wp-content/upgrade/ devuelve un código 403. Alternativamente, se puede realizar una actualización manual fuera del árbol web: copiar los archivos del núcleo a un directorio no servido, reemplazar los componentes esenciales sin tocar wp-config.php ni wp-content, y ejecutar la migración de la base de datos.
Los sitios que aún ejecutan versiones anteriores a 4.7 (lanzadas en 2008) no reciben parches y deben migrar a una versión soportada lo antes posible. Revisar los registros del servidor en busca de peticiones a archivos .php dentro de wp-content/upgrade, verificar la existencia de cuentas de administrador desconocidas y analizar la presencia de plugins o archivos inesperados completan el proceso de auditoría post-actualización.
