El parche llegó a tiempo, pero los atacantes no han tardado nada en reaccionar. La empresa de seguridad Wordfence ha detectado más de 18.500 peticiones maliciosas en 21 horas dirigidas al fallo más grave que corrigió WordPress 7.1.4, la versión de seguridad publicada el 28 de octubre. Se trata de una vulnerabilidad que permite ejecutar código en el servidor sin necesidad de iniciar sesión, y que afecta a todas las versiones desde la 4.7 hasta la 7.1.3. Si una web no se ha actualizado todavía, ahora sí es urgente.
Nueve minutos para el primer intento
Según los datos de Wordfence que recogen medios especializados como GBHackers y Daily CyberSecurity, la compañía desplegó una regla de protección en su cortafuegos a las 20:30 UTC del 28 de octubre, unas tres horas después del anuncio oficial. El primer intento de explotación que encajaba con esa regla apareció solo nueve minutos después.
En las primeras 21 horas de vigilancia, el cortafuegos registró más de 18.500 peticiones contra las rutas temporales del instalador. Dos orígenes concretos estuvieron sondeando de forma repetida pequeños grupos de webs durante unas 14,5 horas, mientras que otros probaban distintas carpetas y nombres de versión. Wordfence advierte de que sus datos muestran intentos activos, no cuántas webs han sido comprometidas, si es que lo ha sido alguna.
Un fallo que se abre durante la propia actualización
La vulnerabilidad la descubrió el investigador Umut Bayram y tiene una puntuación CVSS de 8,1, aunque todavía no tiene un identificador CVE asignado. El problema está en el proceso de actualización del núcleo: cuando WordPress se actualiza con el paquete completo, descomprime los archivos en una carpeta con un nombre predecible dentro de wp-content/upgrade, incluido el instalador.
Si el servidor permite acceder a esa carpeta desde internet y ejecutar PHP en ella, un atacante que llegue a tiempo al archivo setup-config.php que queda en esa zona temporal puede ejecutar código en el servidor. La ventana es muy corta: en las pruebas de laboratorio de Wordfence, la carpeta solo existía unos segundos. Por eso los atacantes no lanzan una única petición, sino que sondean de forma automática y repetida a la espera de pillar una actualización en curso.
Las valoraciones del riesgo no coinciden del todo. Patchstack le da una puntuación de 9 sobre 10, pero considera su explotación «poco práctica» por lo ajustado de esa ventana. La actividad que ha detectado Wordfence demuestra, en cualquier caso, que hay quien lo está intentando a gran escala.
Qué corrige WordPress 7.1.4
La nueva versión cambia la forma en que se prepara la actualización: según Wordfence, aleatoriza el nombre de la carpeta temporal, añade una protección de índice y bloquea el uso inseguro de los datos de configuración que quedan en esa zona. Las correcciones se han llevado a todas las ramas que todavía reciben parches de seguridad, hasta WordPress 4.7, aunque solo la última versión tiene soporte activo.
El paquete incluía además otros arreglos, sobre todo fallos de cross-site scripting almacenado en el editor de bloques y en la Interactivity API, problemas de exposición de información y de permisos. Pero ninguno ha despertado la atención de los atacantes como este, que no exige tener ninguna cuenta en la web.
Un detalle importante para quien use el plugin gratuito de Wordfence: los clientes de pago de Premium, Care y Response recibieron la regla de protección el mismo 28 de octubre, pero los usuarios de la versión gratuita no la tendrán hasta el 27 de noviembre. Hasta entonces, su única defensa real es tener el núcleo actualizado.
Qué deberían hacer ya los responsables de webs WordPress
Lo primero es comprobar la versión instalada en Escritorio, Actualizaciones, y confirmar que cada sitio está en la 7.1.4 o en el parche correspondiente de su rama. Las fuentes insisten en no dar por hecho que las actualizaciones automáticas en segundo plano ya se han completado: en agencias y redes de sitios, conviene revisarlo uno por uno o con la herramienta de gestión habitual.
Si por algún motivo no se puede actualizar de inmediato, Patchstack recomienda bloquear el acceso web a wp-content/upgrade desde la configuración del servidor y asegurarse de que esa carpeta no se puede listar. Quien use Wordfence puede activar la protección extendida, que carga el cortafuegos antes de que se ejecute cualquier archivo PHP solicitado directamente.
Y actualizar no basta para saber si una web expuesta está limpia. Lo prudente es revisar los registros del servidor en busca de peticiones extrañas a archivos PHP dentro de wp-content/upgrade, comprobar que no han aparecido administradores ni plugins desconocidos y escanear la instalación en busca de archivos modificados. Con WordPress presente en más del 43 % de las webs, según W3Techs, este tipo de fallos se convierte en objetivo prioritario en cuestión de horas.