Qué ha pasado

Casi la mitad de la web corre sobre WordPress. Así que cuando el 28 de octubre tuvo que publicar la versión 7.1.4 para tapar un fallo grave de su propio núcleo, el aviso iba para millones de sitios. El fallo —CVE-2026-119977— permite a un atacante sin credenciales tomar el control de la web… durante la propia actualización del core. No hace falta un plugin raro ni una contraseña débil: basta pillar el momento exacto en que WordPress se está actualizando.

Y aquí está lo inquietante: ese momento dura solo unos segundos. Pero no hace falta acertarlo: los atacantes escanean sin parar para cazar cualquier web que esté actualizándose. Wordfence contó más de 18.500 peticiones a las rutas del instalador en las primeras 21 horas, y el 3 de noviembre CISA lo metió en su catálogo de vulnerabilidades explotadas (KEV) —la forma oficial de decir «esto ya se está usando contra servidores reales»—, con fecha límite para la administración de EE. UU. apenas tres días después.

Míralo por dentro

Antes de los comandos, mira cómo funciona. Abajo tienes el ataque paso a paso: a la izquierda, lo que pasa; en el centro, lo que envía el atacante; a la derecha, lo que responde el servidor. Cámbialo a «Corregido» y verás por qué 7.1.4 cierra la puerta.

La paradoja: el fallo vive en el momento de actualizar

Casi todo el mundo lo cuenta como «otro crítico de WordPress, actualiza». Pero lo interesante es dónde está el agujero, porque es contraintuitivo: no está en tu web funcionando, está en el proceso de actualizarla. Es lo que los de seguridad llaman una condición de carrera (CWE-367): una ventana diminuta entre dos pasos del propio WordPress.

Cuando WordPress actualiza su núcleo por paquete completo, descarga el paquete nuevo y lo descomprime en una carpeta temporal dentro de wp-content/upgrade/. El problema es que esa copia descomprimida es una instalación completa de WordPress, con su instalador incluido (wp-admin/setup-config.php). Y ese instalador no ve la configuración de tu web real —solo mira su propia carpeta, así que cree estar ante una instalación nueva— y, antes de 7.1.4, vivía en una ruta predecible (el nombre salía del propio paquete). 7.1.4 corrige las dos cosas: aleatoriza esa carpeta y hace que el instalador detecte tu web.

Con eso, el ataque es directo: mientras dura la actualización, el atacante le manda al instalador temporal unas credenciales de base de datos suyas. El instalador valida la conexión y escribe un wp-config.php malicioso; cuando WordPress copia esa carpeta sobre la instalación real, sobrescribe tu configuración con la del atacante. Si su base de datos está vacía, WordPress enseña el asistente de instalación, el atacante se crea un administrador y a partir de ahí instala un plugin con PHP y ejecuta código. Control total.

Un matiz importante, para que no cunda el pánico equivocado: esto solo lo dispara la actualización del núcleo por paquete completo. Las actualizaciones de plugins y temas no lo tocan. Pero ojo con la otra cara: las actualizaciones automáticas no te salvan, porque las del core pasan por esa misma ventana ellas solas, sin que tú mires.

No es «un WordPress raro»: es casi la mitad de la web

El alcance es lo que lo hace serio. Afecta a WordPress 4.7 hasta 7.1.3 (y el comportamiento del actualizador viene de atrás, desde la 2.7.0). Es decir: prácticamente cualquier WordPress por debajo de 7.1.4. El parche está retroportado a todas las ramas mantenidas hasta la 4.7, precisamente porque no es un caso de nicho.

Y aquí entra lo que más daño hace: WordPress es el software de set-and-forget por excelencia. Agencias con decenas de webs de clientes, pymes que montaron su web hace años y no la han vuelto a tocar, proyectos heredados sin nadie claro al mando. Son justo los sitios donde nadie comprueba la versión y donde una actualización automática se dispara de madrugada sin que haya un alma delante. Ahí es donde una ventana de segundos, escaneada sin parar, acaba encontrando a alguien.

Cómo saber si te afecta (y si te han tocado)

Dos cosas distintas: qué versión tienes y si alguien aprovechó la ventana. Si estás en 7.1.4 o superior, el actualizador ya está corregido.

# 1 · ¿qué versión de WordPress tienes? (segura: 7.1.4 o superior)
wp core version

# …sin WP-CLI, leyendo el fichero:
grep "wp_version =" wp-includes/version.php

# si gestionas varias webs en el servidor, míralas todas de golpe:
find / -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} \; 2>/dev/null

# 2 · ¿quedó PHP donde no debería? (rastro del ataque)
find wp-content/uploads wp-content/upgrade -name '*.php' -newermt '2026-10-27'

# 3 · ¿carpetas de actualización a medias? (no debería haber nada salvo index.php)
find wp-content/upgrade -mindepth 1 ! -name index.php

Y en los logs, trátalo como un posible compromiso si ves: peticiones a ficheros .php dentro de wp-content/upgrade (un visitante normal jamás pide eso), un POST a setup-config.php?step=2, un listado de /wp-content/upgrade/ que devuelve 200, o administradores nuevos creados durante una ventana de actualización.

Las trampas

Trampa 1: «tengo actualizaciones automáticas, estoy a salvo». Al revés: si tu web se actualiza sola, pasa por la ventana vulnerable ella sola, de madrugada y sin testigos. Lo que importa es haber llegado ya a 7.1.4.

Trampa 2: la versión del panel puede mentir. Fíate del fichero (wp-includes/version.php) o de wp core version. Y si gestionas varias webs, míralas todas: basta una vieja.

Trampa 3: ramas antiguas. Si sigues en 6.9 o 7.0 por compatibilidad, el parche está en su versión de rama (7.0.8, 6.9.11…), no solo en 7.1.4. Mira la que te toca.

Qué hacer, por orden

1. Actualiza a 7.1.4 (o al parche de tu rama) ya. Corrige el propio mecanismo de actualización y aleatoriza la carpeta temporal.
2. Mientras actualizas, no lo hagas con la web abierta a todo internet si puedes evitarlo. Un mantenimiento, una IP permitida o un WAF reducen la ventana a casi nada.
3. Revisa que no te tocaron, sobre todo si tu web se actualizó —a mano o sola— entre el 28 de octubre y el día que la pusiste en 7.1.4.
4. Si encuentras rastro (PHP en upgrade, un admin que no reconoces), trátalo como un compromiso: fuera de línea, revisión y restauración desde copia limpia.

La lección que no caduca

Llevamos semanas repitiendo que «actualiza» no siempre es una respuesta cómoda. Este caso le da la vuelta del todo: aquí la propia actualización era el momento del ataque. No porque actualizar esté mal —hay que hacerlo, y 7.1.4 es la solución— sino porque demuestra que la seguridad no es un estado, es cómo y cuándo haces las cosas: con qué expuesto, en qué ventana, vigilando qué.

Y deja una pregunta incómoda para quien gestiona webs ajenas: ¿cuántas de las que llevas se actualizan solas de madrugada sin que nadie mire qué pasa esos segundos? Saber en qué versión está cada una —y que a partir de 7.1.4 esa ventana ya no existe— es la diferencia entre enterarte en diez minutos o que te pille con la puerta abierta.

Si no sabes en qué versión están tus WordPress —el tuyo o los de tus clientes—, o si alguno se actualizó estos días sin que lo miraras, escríbenos y lo revisamos contigo. Es media hora, y te quedas sabiendo exactamente de qué lado estás.

Fuentes

Todo lo que se afirma aquí sale de estas fuentes. Si solo vas a abrir una, que sea la primera.

• NVD — CVE-2026-119977, la ficha oficial (CVSS 8.1, condición de carrera / CWE-367). La fuente primaria.
• CISA — Catálogo de vulnerabilidades explotadas (KEV), donde entró el 3 de noviembre con plazo federal el 6.
• Picus Security — «When Updating WordPress Becomes the Vulnerability»: el mecanismo del instalador en la carpeta temporal.
• ThreatDefence — detección y las cifras de Wordfence (más de 18.500 peticiones al instalador en 21 horas).
• SOC Prime — RCE del núcleo explotado durante las actualizaciones.
• Qualys ThreatPROTECT — el aviso de CISA sobre explotación en activo.

De la misma serie

• OpenSSH «sshole»: entrar por SSH sin saber la contraseña
• Node2Shell: el fallo no es de Node, es de Brotli
• Cuatro avisos críticos en ocho días: nginx, el kernel, PHP y Node

Si gestionas WordPress —tuyo o de clientes— y no sabes en qué versión está cada web, en MagicBoxDesk lo revisamos contigo: ciberseguridad y mantenimiento web gestionados. 📍 Alicante y Barcelona · hablemos 30 minutos.