Fallo en la actualización de WordPress bajo ataque: casi 63.000 intentos de explotación en 24 horas

Los atacantes no perdieron el tiempo. Apenas dos días después de la publicación de WordPress 7.1.4, el 28 de octubre de 2026, los intentos de explotar la vulnerabilidad de severidad alta que corrige esa versión ya se contaban por decenas de miles al día. El fallo permite la ejecución remota de código sin autenticación en sitios que ejecutan WordPress Core desde la versión 4.7 hasta la 7.1.3 y tiene una puntuación CVSS de 8,1. En el momento de publicar este artículo no se le ha asignado un identificador CVE.

Qué ocurrió

La debilidad está en un lugar poco llamativo: la forma en que WordPress descomprime una actualización completa del núcleo. Cuando un sitio instala una versión completa (y no una actualización parcial), los archivos nuevos se extraen en una carpeta temporal de preparación bajo wp-content/upgrade antes de moverse a su ubicación definitiva. Dos detalles convierten ese paso rutinario en una superficie de ataque:

• la ruta de la carpeta temporal es predecible y, en muchas configuraciones de alojamiento, es accesible desde la web y ejecuta PHP;
• la copia preparada incluye el instalador de WordPress, con setup-config.php incluido.

Un atacante sin autenticar que solicite el instalador preparado en el momento exacto puede usarlo contra la copia a medio instalar y llegar a ejecutar código PHP en el servidor. Se trata de una condición de carrera: en laboratorio la ventana dura solo unos segundos y se cierra cuando WordPress termina la actualización y elimina los archivos temporales.

Para que el ataque tenga éxito deben cumplirse a la vez todas estas condiciones:

1. se está aplicando una actualización completa que contiene los archivos del instalador;
2. el árbol temporal es accesible públicamente desde la web y PHP se ejecuta desde él;
3. el atacante conoce o adivina la ruta de la carpeta temporal;
4. el atacante completa la secuencia antes de la limpieza.

Por qué importa

Una ventana de pocos segundos parece inexplotable. El tráfico dice lo contrario. La telemetría de cortafuegos para WordPress registró cerca de 63.000 solicitudes bloqueadas dirigidas a este fallo en un solo periodo de 24 horas. Dos de las mayores fuentes martillearon pequeños grupos de sitios durante unas catorce horas y media cada una, consultando una y otra vez la ruta del instalador con la esperanza de coincidir con una actualización en curso. Otras se dispersaron probando numerosas variantes de carpeta temporal y de nombre de versión hasta dar con la correcta.

No todas las solicitudes alcanzaron la ruta vulnerable exacta, pero el sondeo sostenido y las pruebas ajustadas a la estructura de archivos demuestran que los atacantes entendieron rápido la condición de carrera y construyeron herramientas para ella. Como el desencadenante es el propio proceso de actualización del sitio, los más expuestos son precisamente los sitios que hacen lo correcto: actualizarse. Los alojados en hosting compartido, donde la carpeta de actualización suele ser legible desde la web, son el objetivo más natural.

Qué hacer

• Actualice a WordPress 7.1.4 ahora. Todas las versiones desde la 4.7 hasta la 7.1.3 están afectadas. Compruebe la versión en cada sitio, no solo en los que recuerda.
• Revise los registros del servidor web en busca de solicitudes a archivos PHP bajo wp-content/upgrade, en especial accesos repetidos a setup-config.php o a subcarpetas con nombre de versión. El sondeo repetido de esa ruta desde un mismo origen es una señal clara.
• Busque persistencia. Revise las cuentas de administrador, los plugins instalados y los plugins must-use, y localice archivos PHP que usted no haya colocado, sobre todo en los directorios de subidas y de temas.
• Endurezca la carpeta temporal. Si su alojamiento lo permite, deniegue el acceso web a wp-content/upgrade o desactive la ejecución de PHP dentro de ella. Esto también mitiga futuras variantes de la misma idea.
• Siga aplicando parches. El fallo solo queda expuesto mientras se ejecuta una actualización, así que la solución es estar en una versión en la que el paso de preparación sea seguro, no dejar de actualizar.

Fallos como este pasan desapercibidos justamente porque el componente vulnerable no es un plugin ni un tema, sino unos segundos dentro de un proceso rutinario. Mantener un inventario preciso de la versión de WordPress que ejecuta cada sitio y recibir una alerta el día en que una versión se queda atrás es el tipo de problema que resuelve nuestro servicio de escaneo de vulnerabilidades: señala las versiones del núcleo desactualizadas en toda su infraestructura para que un retraso de dos días no se convierta en uno de dos meses.