Actualizaré la noticia si CISA, WordPress o los investigadores publican datos nuevos.

◢Qué ha pasado

El fallo está en el proceso con el que WordPress se actualiza a sí mismo. Cuando instala una versión nueva completa, prepara los archivos en unas rutas temporales que son predecibles y accesibles desde internet. Durante ese rato, que WordPress llama "ventana de actualización", un atacante que sepa dónde mirar puede adelantarse y conseguir que el servidor ejecute su código. Técnicamente es una condición de carrera, de las que en inglés se llaman TOCTOU: el sistema comprueba algo y, antes de usarlo, alguien lo cambia.

El equipo de seguridad de WordPress lo describió al publicar el parche como "una debilidad en el proceso de actualización que puede llevar a la ejecución remota de código durante la ventana de actualización", y pidió actualizar las webs de inmediato, según recoge BleepingComputer. El fallo lo encontró Umut Bayram, investigador de Picus Security.

En la ficha del NIST la puntuación es de 8,1 sobre 10, gravedad alta. No llega a crítica porque el ataque es difícil de ejecutar: hay que acertar en un momento concreto. Pero no exige ningún permiso ni que nadie haga clic en nada.

◢¿Se está explotando de verdad?

CISA dio de plazo a las agencias federales de Estados Unidos hasta el viernes 6 de noviembre para corregirla y, además, les exige un análisis forense, es decir, comprobar si ya les han entrado. Para una empresa española esos plazos no son obligatorios, pero indican la urgencia.

Según The Hacker News⁵, Wordfence vio los primeros intentos de ataque nueve minutos después de activar su regla de cortafuegos para este fallo, y dos de las fuentes más activas estuvieron unas 14,5 horas comprobando pequeños grupos de webs, algo que Wordfence relaciona con intentar pillar el momento en que una web se actualiza.

No es la primera vez este año. En julio WordPress corrigió otra cadena de fallos en su núcleo, conocida como wp2shell, y según BleepingComputer los atacantes empezaron a entrar en servidores sin parchear pocos días después.

◢Lo que no se sabe

No se sabe cuántas webs han sido atacadas con éxito, ni quién está detrás. Ninguna fuente oficial ha atribuido los ataques a ningún grupo ni país. En GitHub han aparecido programas que sus autores presentan como exploits para este fallo, pero no está comprobado que funcionen. El investigador sostiene además que el fallo viene de WordPress 2.7, de 2008; la ficha oficial sigue diciendo que afecta desde la 4.7. En cualquier caso, la 4.6 y anteriores ya no reciben parches.

◢¿Mi web está afectada?

Si tu web o la de tu empresa funciona con WordPress, entra en el panel, en Escritorio, Actualizaciones, y mira la versión instalada. Lo que importa es si tiene el parche de su rama: la ficha del NIST² da como corregidas, entre otras, la 7.1.4, la 7.0.8, la 6.9.11, la 6.8.12, la 6.7.11 y la 6.6.11, y llega hasta la 4.7.39. Si la tuya es anterior a la corregida de su rama, es vulnerable.

Si tienes las actualizaciones automáticas activadas, es posible que la web ya tenga el parche. No lo des por hecho: entra y míralo. Y ten en cuenta que la actualización automática usa el mismo proceso, así que, si aún no se ha aplicado, conviene bloquear antes la carpeta como explico más abajo. Muchas webs de pymes se hicieron hace años, las gestiona una agencia o un freelance que ya no está, y nadie sabe si se actualizan. Si es tu caso, pregunta hoy a quien te lleve la web o al proveedor de alojamiento.

Ojo con un detalle: aunque el ataque ocurre durante una actualización, la solución no es dejar de actualizar. Una web parada en una versión antigua acumula fallos conocidos que los atacantes buscan de forma automática.

◢Qué hacer ahora

Para quien gestiona la web:

• ▹Antes de actualizar, bloquear el acceso web a la carpeta wp-content/upgrade. Es la primera recomendación del investigador, Umut Bayram, porque la actualización que instala el parche todavía usa el código antiguo de la web para descomprimir los archivos y, en webs con la 5.9 o posterior, el nombre de la carpeta temporal se puede adivinar una última vez. Según recoge The Hacker News⁵, WordPress trabaja con esa carpeta directamente en disco, así que bloquearla no rompe las actualizaciones. En Nginx basta con location ^~ /wp-content/upgrade/ { deny all; }, y si solo puedes tocar el .htaccess de la raíz, con RedirectMatch 403 ^/wp-content/upgrade/ encima de las reglas de WordPress. No pongas el .htaccess dentro de esa carpeta, porque el actualizador la vacía. Comprueba que /wp-content/upgrade/ devuelve un error 403. Actualizar con wp core update de WP-CLI no evita el problema, porque usa el mismo proceso.
• ▹Después, actualizar WordPress a la versión 7.1.4 o posterior. La otra vía segura que propone el investigador es una actualización manual: copia de seguridad, descomprimir la versión nueva fuera de la carpeta pública, copiar los archivos del núcleo sin tocar wp-config.php ni wp-content y ejecutar la actualización de la base de datos. Si no puedes saltar a la 7.1.4 hoy, instala al menos el parche de tu rama, pero tómalo como un apaño: WordPress recuerda³ que solo da soporte activo a la versión más reciente.
• ▹Revisar si hay señales de intrusión. Wordfence propone buscar peticiones inesperadas a archivos PHP dentro de wp-content/upgrade, archivos PHP en esa carpeta que nadie ha puesto, usuarios administradores que nadie reconoce y plugins que nadie ha instalado. CISA exige ese análisis a sus agencias, así que conviene hacerlo también.
• ▹Si hay indicios de que alguien ha entrado, cambiar las contraseñas de los administradores y las del alojamiento y la base de datos, y pedir ayuda a quien sepa limpiar una web comprometida.
• ▹Tener una copia de seguridad reciente fuera del propio servidor.

Para la dirección, la pregunta clave es otra: ¿quién es el responsable de que la web esté al día? Una web corporativa es un servidor expuesto a internet con el nombre de tu empresa encima. Si alguien la toma, puede usarla para colgar páginas de phishing, infectar a tus visitantes o robar los datos de los formularios.

◢Qué aprender de esto

He escrito en el blog que la mayoría de ataques entran por un correo y no por el servidor, y sigue siendo así para la mayoría de empresas. Casos como este, o el de la VPN de Ivanti de hace unos días, son la excepción que hay que vigilar: cuando el fallo está en algo expuesto a internet, nadie tiene que caer en ningún engaño.

La lección práctica es tener a alguien con nombre y apellidos a cargo de cada cosa que la empresa tiene publicada, y que reciba los avisos de seguridad. Eso vale para la web, la VPN y el correo.

Si quieres que tu equipo entienda estos riesgos sin necesidad de ser técnico, es justo lo que trabajo en mis formaciones de ciberseguridad.