WordPress: explotan un fallo del proceso de actualización para ejecutar código en los servidores, advierte la CISA

La CISA añadió el 3 de noviembre de 2026 a su catálogo de vulnerabilidades explotadas activamente CVE-2026-119977, una condición de carrera en las actualizaciones del núcleo de WordPress que permite a un atacante sin cuenta ejecutar código en el servidor durante la actualización. WordPress la corrigió en la versión 7.1.4, publicada el 28 de octubre; afecta a las versiones 4.7 a 7.1.3.

Qué ha pasado

El 3 de noviembre de 2026, la agencia estadounidense CISA incluyó el fallo CVE-2026-119977 del núcleo de WordPress en su catálogo KEV, lo que confirma que se está usando en ataques. Las agencias federales tienen hasta el 6 de noviembre para corregirlo y deben además realizar un análisis forense. WordPress lo había solucionado en la versión 7.1.4, publicada el 28 de octubre junto con otras once correcciones de seguridad, y lo describió como una debilidad del proceso de actualización que puede llevar a la ejecución remota de código durante la ventana de actualización.

Cómo entran los atacantes

Según el registro CVE, publicado por Wordfence, las actualizaciones completas del núcleo usan rutas temporales predecibles y accesibles desde la web. Un atacante que gane la carrera (un fallo de tipo time-of-check to time-of-use, con una puntuación de 8,1 en CVSS 3.1) puede ejecutar código en el servidor sin cuenta alguna mientras se realiza la actualización. Son vulnerables todas las ramas de 4.7.0 a 7.1.3. El ataque es complejo, pero real: según BleepingComputer, Wordfence afirma haber bloqueado 13 095 intentos en 24 horas.

Qué hacer ahora

  1. Compruebe la versión de cada sitio: wp core version con WP-CLI, o Escritorio > Actualizaciones.
  2. Actualice a 7.1.4 (wp core update). En ramas antiguas, WordPress indica que publica correcciones retroportadas hasta la 4.7: instale la última versión de su rama y planifique el paso a la 7.1.
  3. Como precaución, bloquee el acceso web al directorio wp-content/upgrade/ (location ^~ /wp-content/upgrade/ { deny all; } en Nginx, Require all denied en Apache), que ningún visitante necesita.
  4. Busque rastros: ejecute wp core verify-checksums, busque archivos PHP en wp-content/upgrade/, cuentas de administrador desconocidas y archivos modificados recientemente, y revise los registros web en torno a las últimas actualizaciones.

Nuestra opinión

Aquí el punto débil era el propio proceso de actualización: no basta con actualizar, también hay que proteger el momento en que se instala la actualización. En los sitios de empresa conviene actualizar de forma controlada, cerrar el acceso web a los directorios de trabajo y verificar la integridad de los archivos tras cada actualización.

Fuentes

Cómo elegimos, verificamos y redactamos nuestros análisis →

¿Está expuesto su propio servidor? Haga una prueba gratuita, solo con información pública y sin intrusión:

Comprobar un servidor Comprobar un sitio

¿Le preocupa que sus servidores estén expuestos? Nuestro equipo audita, parchea y supervisa infraestructuras Linux y cloud 24/7.

Hablar con un experto Nuestros servicios de servidores gestionados →