El 3 de noviembre de 2026, CISA, la agencia de ciberseguridad de Estados Unidos, incluyó la CVE-2026-119977 en su catálogo de vulnerabilidades explotadas activamente. El fallo está en el proceso de actualización del core de WordPress y permite que un atacante sin sesión ejecute código en el servidor mientras la actualización está en curso. La corrección salió el 28 de octubre, en WordPress 7.1.4. Que figure en el catálogo significa que la agencia tiene evidencia de explotación real, y no solo de una prueba de concepto.
La ventana que abre la propia actualización
Según el registro en el NVD, la base pública de vulnerabilidades del gobierno estadounidense, el fallo afecta a las versiones 4.7 a 7.1.3. Cuando WordPress hace una actualización con el paquete completo del core, prepara los archivos nuevos en rutas predecibles y accesibles desde la web. Quien conozca la ruta y acierte el momento puede ejecutar código antes de que la actualización termine. Es una condición de carrera: el sistema comprueba el archivo en un instante y lo usa en el siguiente, y el ataque ocurre entre los dos.
La puntuación de Wordfence, que registró la CVE, es 8,1 sobre 10. Considera alta la complejidad del ataque, porque depende de acertar esa ventana, pero no exige cuenta ni ninguna acción de nadie en el sitio.
El anuncio del 7.1.4 describe el problema como "una debilidad en el proceso de actualización de WordPress que puede llevar a la ejecución remota de código durante la ventana de actualización". La misma versión corrigió más de diez fallos adicionales, la mayoría de XSS almacenado accesible para usuarios con rol de colaborador o superior.
Quién tiene que revisar
Cualquier WordPress autoalojado entre el 4.7 y el 7.1.3 está dentro del alcance. El proyecto llevó las correcciones a todas las ramas que todavía reciben parches de seguridad, hasta la 4.7. La API de actualización de WordPress.org ofrece hoy, además del 7.1.4, versiones como 7.0.8, 6.9.11 y 6.8.12 para quien sigue en ramas antiguas. El propio anuncio recuerda que solo la versión más reciente tiene soporte activo; las ramas antiguas reciben únicamente estas correcciones de seguridad.
El riesgo es mayor donde hay muchos sitios con actualización manual y espaciada: agencias con cartera de clientes, empresas con varios sitios institucionales, instalaciones que nadie revisa desde la entrega. En esos casos la actualización del core tiende a hacerse tarde, y cada actualización iniciada desde una versión vulnerable abre la ventana descrita en la CVE.
Qué hacer ahora
El plazo del 6 de noviembre fijado por CISA solo obliga a los organismos federales estadounidenses. Para los demás, la referencia práctica es la misma: el fallo ya se está explotando, así que la corrección no debería esperar a la próxima ventana de mantenimiento.
- Confirmar la versión de cada instalación. Sirven el 7.1.4 o la versión corregida de la rama en uso, según la lista de la API de WordPress.org.
- Verificar si las actualizaciones automáticas en segundo plano están activadas. Aplican las versiones de seguridad sin intervención, pero pueden estar desactivadas, por ejemplo en sitios publicados con Git o en alojamientos que controlan la versión del core.
- Revisar los sitios que actualizaron el core mientras eran vulnerables. CISA marcó la entrada con requisito de triaje forense, lo que para los organismos federales significa investigar además de aplicar la corrección. Para un sitio privado, mi lectura es que conviene revisar archivos PHP creados o modificados cerca de la fecha de la última actualización y accesos inusuales en el mismo periodo.
Lo que los avisos todavía no dicen
CISA registra como "desconocido" el uso del fallo en campañas de ransomware, y ninguno de los avisos públicos informa cuántos sitios fueron atacados ni cómo se observó el ataque.
Tampoco está claro si la propia actualización al 7.1.4, ejecutada desde una versión vulnerable, abre la ventana una última vez. La descripción habla del código de actualización de las versiones afectadas, y es ese código el que se ejecuta cuando el sitio se actualiza. Hasta que el proyecto lo aclare, tiene sentido actualizar primero los sitios más expuestos y vigilar los registros durante y justo después de la actualización.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
