Algunos sitios de WordPress aún pueden ser atacados mientras instalan el parche para una vulnerabilidad explotada activamente, según Umut Bayram, investigador de Picus Security que la descubrió. La actualización que instala el parche sigue descomprimiendo sus archivos usando el código antiguo y sin parchear del sitio, por lo que un atacante que actúe en el momento preciso puede ejecutar código en el servidor. El investigador aconseja bloquear el acceso web a la carpeta wp-content/upgrade del sitio antes de actualizar.
La vulnerabilidad, rastreada como CVE-2026-119977, afecta a WordPress 4.7 hasta 7.1.3. Durante una actualización del núcleo que utiliza un paquete completo, WordPress descomprime una copia de la nueva versión en una carpeta temporal dentro de wp-content/upgrade. Esa copia incluye el instalador de WordPress, y el servidor web normalmente puede acceder a ella.
Un atacante sin cuenta que pueda determinar el nombre de la carpeta y acceder al instalador antes de que WordPress elimine la copia puede acabar ejecutando código en el servidor. La Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. (CISA) añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas a principios de esta semana.
WordPress publicó el parche la semana pasada en la versión 7.1.4 y en actualizaciones equivalentes para ramas anteriores hasta la 4.7, todas listadas en su aviso de seguridad.
El parche asigna un nombre aleatorio a la carpeta temporal. Pero la actualización que instala el parche descomprime sus archivos usando el código antiguo que ya está en el sitio, como muestra el código del actualizador de WordPress. En sitios que ejecutan 5.9 o posterior, ese código antiguo nombra la carpeta según el archivo descargado, por lo que el nombre se puede predecir una última vez.
Antes del parche, un atacante podía usar el instalador para escribir un nuevo archivo de configuración, wp-config.php, en la copia temporal. La actualización luego sobrescribiría el archivo real del sitio con ese archivo. La parte del parche que impide esto ya funciona durante la actualización que lo instala, porque WordPress copia los archivos en su lugar usando el nuevo código.
Un atacante que aproveche la ventana durante esa actualización todavía puede configurar la copia temporal de WordPress con su propia base de datos, iniciar sesión en ella y ejecutar código PHP con los permisos del servidor web antes de que se elimine la copia, según Bayram en su informe técnico. Desde allí, el atacante puede leer o escribir archivos en el sitio WordPress activo.
Quién está expuesto durante la actualización
No todas las actualizaciones exponen el instalador, dice el investigador. Los paquetes completos siempre incluyen los archivos del instalador. Un paquete parcial más pequeño, creado para una versión de partida específica, expone un sitio solo si resulta que contiene esos archivos.
En sitios que permiten actualizaciones automáticas en segundo plano, WordPress instala el parche automáticamente, mediante el mismo actualizador y los mismos pasos.
The Hacker News comprobó hoy el servicio de actualizaciones de WordPress.org para varias versiones. Para actualizaciones dentro de una rama, como de 7.1.3 a 7.1.4, ofreció un paquete parcial, incluso para actualizaciones automáticas. Para un salto desde una rama anterior, como de 7.0.7 a 7.1.4, ofreció solo paquetes completos.
En 4.4 hasta 5.8, el código antiguo añade caracteres aleatorios al nombre de la carpeta. Eso oculta el nombre a menos que el sitio lo filtre de otra manera, como en un mensaje de error, según el investigador.
Una vez instalado 7.1.4 o un parche de rama, las actualizaciones posteriores usan un nombre de carpeta aleatorio, y un archivo wp-config.php en la copia temporal nunca se copia sobre el real.
Qué hacer antes de actualizar
La primera recomendación del investigador es impedir que el servidor web sirva wp-content/upgrade. WordPress trabaja con esa carpeta directamente en disco, por lo que bloquear el acceso web no rompe las actualizaciones, dice.
- Bloquear la carpeta en la configuración del servidor web. En Nginx, añadir location ^~ /wp-content/upgrade/ { deny all; }. En Apache, añadir Require all denied dentro de un bloque <Directory> para esa carpeta en la configuración del host virtual.
- Si solo se puede editar .htaccess, añadir RedirectMatch 403 ^/wp-content/upgrade/ al archivo .htaccess en la raíz de WordPress, por encima de las reglas de reescritura de WordPress.
- No colocar un archivo .htaccess dentro de wp-content/upgrade. El actualizador antiguo elimina todo en esa carpeta antes de descomprimir una actualización, por lo que el archivo desaparecería cuando se necesita.
- Confirmar que una solicitud a /wp-content/upgrade/ devuelve un error 403.
- Actualizar a 7.1.4 o a la versión corregida para su rama.
La otra ruta segura, dice, es una actualización manual realizada fuera de la raíz web, la carpeta que sirve el servidor web. Hacer una copia de seguridad de los archivos del sitio y la base de datos, descomprimir la nueva versión en una carpeta que el servidor web no sirva, copiar los archivos del núcleo en su lugar sin tocar wp-config.php ni wp-content, y luego ejecutar la actualización de la base de datos de WordPress. De esta manera, nunca se crea un instalador temporal en una carpeta accesible desde la web.
El comando wp core update de WP-CLI no es un sustituto, porque ejecuta el mismo actualizador y descomprime el paquete en la misma carpeta.
WordPress 4.6 y anteriores ya no reciben actualizaciones de seguridad, por lo que no hay parche para ellos. El investigador dice que la vulnerabilidad se remonta a WordPress 2.7, lanzado en 2008, y que esos sitios deberían migrar a una versión compatible.
Ataques y qué comprobar
La inclusión en el catálogo de CISA a principios de esta semana se basó en evidencia de explotación activa, pero la agencia no describió los ataques.
Wordfence, la empresa de seguridad de WordPress que asignó el identificador CVE, vio intentos de ataque comenzar nueve minutos después de implementar una regla de firewall para la vulnerabilidad el día del lanzamiento. Dos de las fuentes más activas estuvieron comprobando pequeños grupos de sitios durante unas 14,5 horas, lo que, según la empresa en su análisis de ataques, concuerda con intentos de atrapar el momento en que un sitio se actualiza.
Su puntuación para la vulnerabilidad en el registro CVE es de 8,1 sobre 10 en la escala CVSS. En sus pruebas de laboratorio, la ventana duró solo segundos. El aviso propio de WordPress califica la vulnerabilidad como baja.
Código que sus autores describen como un exploit para la vulnerabilidad ha aparecido en repositorios públicos de GitHub desde principios de esta semana. Uno de ellos dice que su código también funciona en sitios que todavía usan una carpeta predecible durante actualizaciones con paquete completo. No se ha establecido si el código funciona.
Para los sitios que permanecieron en una versión afectada después del lanzamiento, Wordfence sugiere buscar:
- solicitudes inesperadas a archivos PHP bajo wp-content/upgrade
- cuentas de administrador que nadie reconoce
- plugins que nadie instaló
- archivos PHP en wp-content/upgrade que nadie puso allí
Actualización
Bayram dijo a The Hacker News el 6 de noviembre que si una actualización parcial está expuesta depende de lo que contenga ese paquete específico. Un paquete parcial contiene solo los archivos que cambiaron entre dos versiones. Si esos no incluyen los archivos del instalador, la copia temporal no puede ejecutarse como una instalación de WordPress, y el instalador nunca queda accesible.
Un sitio tampoco recibe siempre un paquete parcial cuando existe uno. WordPress recurre a un paquete completo si los archivos del núcleo del sitio no coinciden con las sumas de verificación oficiales o si la actualización es una reinstalación.
El factor decisivo, dijo el investigador, "no es parcial versus completo. Es si el actualizador ya instalado en el sitio ha sido parcheado".
Deja una respuesta