La CISA confirma ataques reales contra el fallo de WordPress que se abre durante las actualizaciones: más de 13.000 en un solo día

La CISA confirma ataques reales contra el fallo de WordPress que se abre durante las actualizaciones: más de 13.000 en un solo día 2

Ya no es una advertencia teórica. La agencia de ciberseguridad de Estados Unidos, la CISA, confirmó el martes 3 de noviembre que el fallo de WordPress corregido en la versión 7.1.4 se está explotando en ataques reales y lo añadió a su catálogo de vulnerabilidades explotadas. Wordfence, por su parte, bloqueó 13.095 ataques en 24 horas contra esta brecha, según BleepingComputer. Cualquier web que siga en una versión anterior está expuesta a que alguien ejecute código en su servidor.

Un fallo que se abre justo al actualizar

La vulnerabilidad, registrada como CVE-2026-119977, es una condición de carrera del tipo TOCTOU (del momento de la comprobación al momento del uso) en el núcleo de WordPress. Según la CISA, el problema está en las rutas temporales predecibles y accesibles desde la web que WordPress usa durante las actualizaciones completas del core. Un atacante que acierte esa ventana puede ejecutar código sin tener cuenta en la web.

The Hacker News le asigna una puntuación CVSS de 8,1, de gravedad alta, y BleepingComputer recuerda que se trata de un ataque de complejidad elevada, porque depende de dar con ese breve intervalo. El fallo lo descubrió Umut Bayram, investigador de Picus Security, y el equipo de seguridad de WordPress lo corrigió en WordPress 7.1.4, publicada el 28 de octubre con la recomendación de actualizar de inmediato.

Qué ha hecho la CISA y qué cifras hay

Al incluirlo en su catálogo KEV, la CISA obliga a las agencias civiles federales de Estados Unidos a proteger sus sistemas antes del 6 de noviembre, en virtud de la directiva BOD 26-04. La orden solo vincula a esos organismos, pero la agencia pide a todas las organizaciones, también a las privadas, que apliquen el parche cuanto antes. No ha dado detalles de cómo se está explotando.

Los datos de ataques confirman que hay interés. Además de los 13.095 ataques bloqueados en un día que recogió Wordfence en su actualización del fin de semana, The Hacker News cita unos 12.632 intentos frenados en las 24 horas previas a su artículo. En las primeras 21 horas tras el parche ya se habían registrado más de 18.500 peticiones contra las rutas del instalador setup-config.php.

La firma Previdian, por su parte, detectó en sus señuelos tres intentos de explotación el 30 de octubre procedentes de una dirección IP ubicada en Reino Unido. Es decir, los atacantes empezaron a probar la brecha apenas dos días después de que se publicara la corrección.

No es el primer aviso grave de este año

El contexto no ayuda. En julio, WordPress tuvo que parchear en la versión 7.0.2 la cadena de fallos conocida como wp2shell, que combinaba una confusión en las rutas por lotes de la REST API con una inyección SQL. Según BleepingComputer, los exploits públicos aparecieron un día después del parche y los ataques contra servidores sin actualizar empezaron pocos días más tarde, con webshells persistentes y plugins maliciosos.

En septiembre, un grupo de habla china usó esa misma cadena para robar datos de las bases de datos de pequeñas empresas y organismos públicos. El patrón se repite: entre la publicación de un parche del núcleo y los primeros ataques masivos pasan horas o pocos días, no semanas.

Qué deberían hacer ya los responsables de webs WordPress

Lo primero es comprobar la versión de cada instalación y actualizar a WordPress 7.1.4 o posterior sin esperar. En agencias con muchos clientes, conviene revisar también las webs con las actualizaciones automáticas desactivadas, los entornos de pruebas accesibles desde internet y las instalaciones olvidadas, que suelen ser las primeras en caer.

Lo segundo es buscar señales de intrusión. The Hacker News sugiere revisar los registros del servidor en busca de peticiones a rutas temporales del instalador como setup-config.php, y BleepingComputer recomienda comprobar si hay indicios de compromiso, sobre todo tras los ataques de wp2shell. Usuarios administradores desconocidos, plugins que nadie ha instalado o archivos PHP nuevos son señales que justifican una revisión a fondo del servidor.


También podría ser de tu interés:

Deja un comentario