---
title: "Octubre negro en WordPress: más de 70.000 ataques contra el actualizador"
description: "CVE-2026-119977 permite ejecutar código sin autenticación durante las actualizaciones de WordPress 4.7 a 7.1.3. Wordfence llegó a bloquear más de 70.000 intentos en 24 horas. Qué hacer y qué plugins también están en el punto de mira."
url: https://wpdirecto.com/octubre-negro-wordpress-cve-2026-119977-actualizador/
date: 2026-11-01
modified: 2026-11-01
author: "Editor WPDirecto"
image: https://wpdirecto.com/wp-content/uploads/2026/11/octubre-negro-wordpress-cve-2026-119977-actualizador.png
categories: ["Actualidad", "Seguridad"]
type: post
lang: es
---

# Octubre negro en WordPress: más de 70.000 ataques contra el actualizador

**Wordfence llegó a bloquear más de 70.000 intentos de ataque en 24 horas contra CVE-2026-119977, una vulnerabilidad del propio núcleo de WordPress que permite ejecutar código PHP en el servidor sin autenticación aprovechando los segundos que dura una actualización.** El fallo afecta a las versiones 4.7 a 7.1.3, tiene una puntuación CVSS 3.1 de 8,1 (alta) y está corregido en WordPress 7.1.4, publicada el 28/10/2026, y en versiones parcheadas de todas las ramas anteriores hasta la 4.7.

**Las claves de la vulnerabilidad del actualizador de WordPress en 20 segundos**

- CVE-2026-119977 permite ejecutar código PHP sin autenticación durante una actualización del núcleo.
- Afecta a WordPress 4.7 a 7.1.3 y se corrige en 7.1.4 y en sus versiones equivalentes.
- Wordfence llegó a bloquear más de 70.000 intentos en 24 horas, sin compromisos confirmados por ahora.
- Conviene bloquear el acceso público a wp-content/upgrade/.

wpdirecto ya contó que [WordPress 7.1.4 corrige fallos de seguridad y pide actualizar ya](https://wpdirecto.com/wordpress-7-1-4-corrige-12-fallos-de-seguridad/). Según el anuncio oficial de [WordPress](https://wordpress.org/support/wordpress-version/version-7-1-4/), la versión resuelve 22 vulnerabilidades agrupadas en 17 avisos y actualiza los certificados raíz incluidos en el núcleo. Lo que ha cambiado desde entonces es que el fallo más grave, una condición de carrera durante las actualizaciones, ya tiene identificador, CVE-2026-119977, y está siendo atacado de forma automatizada. El hallazgo se atribuye a Umut Bayram, de Picus Security.

## Qué falla durante la actualización

Cuando WordPress instala una actualización completa, descomprime el paquete en una carpeta temporal dentro de `wp-content/upgrade/` antes de copiar los archivos a su sitio. Según el análisis técnico de [Ostorlab](https://blog.ostorlab.co/wordpress-core-upgrade-window-rce-cve-2026-119977.html), el nombre de esa carpeta derivaba solo del nombre del paquete, por ejemplo `wordpress-7.1.4`, así que era predecible, y la carpeta suele ser accesible desde internet. Dentro estaba una copia del instalador, `wp-admin/setup-config.php`, cuya protección solo comprueba si existe un `wp-config.php` a su lado, algo que no ocurre en el paquete recién descomprimido.

Eso abre una ventana de unos segundos en la que un atacante puede llegar al instalador temporal antes de que se borre. Además, antes de la 7.1.4, el paso de copia no excluía `wp-config.php`, de modo que un archivo de configuración creado en la carpeta temporal podía acabar en la raíz del sitio y persistir después de la actualización, apuntando la web a una base de datos controlada por el atacante. El atacante no necesita acertar a la primera: le basta con lanzar peticiones repetidas y esperar a coincidir con una actualización. Es una condición de carrera de tipo TOCTOU (CWE-367), en la que el sistema se comprueba en un estado y se usa en otro.

Para explotarla tienen que darse varias condiciones a la vez: una versión afectada, una actualización aplicada con el actualizador de WordPress, una carpeta de actualización accesible por web con PHP ejecutable y que el atacante llegue antes de la limpieza. No hace falta cuenta ni interacción del usuario. WordPress califica la condición de carrera en sí como de gravedad baja, y la diferencia con el 8,1 del registro CVE se explica por la alta complejidad del ataque frente al impacto si se consigue.

## Más de 70.000 intentos en 24 horas

El contador de Wordfence, que muestra los ataques bloqueados en las 24 horas anteriores, marcó 70.095 el 30 de octubre a las 16:55 (hora UTC), según [Brandefense](https://brandefense.io/security-news/wordpress-7-1-4-security-update-upgrade-window/). Es una cifra que varía con el tiempo: The Hacker News publicó 62.969 citando a Wordfence y, al día siguiente, el mismo contador marcaba 60.471. La primera coincidencia con la regla del cortafuegos llegó nueve minutos después de desplegarla, hubo más de 18.500 peticiones contra rutas del instalador temporal en las primeras 21 horas y dos de las principales fuentes estuvieron sondeando grupos reducidos de sitios durante unas 14,5 horas.

Son intentos bloqueados, no instalaciones comprometidas: ni Wordfence ni WordPress han informado de ataques con éxito. Pero muestran actividad dirigida contra esta vulnerabilidad pocas horas después del parche. Un detalle importante: la regla de Wordfence llegó el 28 de octubre a los clientes de pago, y los usuarios de la versión gratuita no la recibirán hasta el 27 de noviembre. Además, las peticiones atacan directamente archivos PHP sin cargar WordPress, por lo que la protección depende de que el cortafuegos esté en modo optimizado.

## Qué hace el parche y qué deben hacer los administradores

WordPress 7.1.4 añade un sufijo aleatorio de 16 caracteres al nombre de la carpeta temporal, escribe un `index.php` en el directorio de actualización y añade `wp-config.php` a la lista de archivos que no se copian a la raíz. Hay versiones corregidas para cada rama afectada, por ejemplo 7.0.8, 6.9.11, 6.8.12, 6.7.11 o 6.6.11, y así hasta la 4.7.39. WordPress 4.6 y anteriores ya no reciben actualizaciones de seguridad. El parche no impide el acceso web a la carpeta, por lo que conviene añadir defensas a nivel de servidor:

- Instalar WordPress 7.1.4 o la versión corregida de su rama y comprobarlo en Escritorio > Actualizaciones.
- Bloquear desde el servidor web el acceso público a `wp-content/upgrade/`.
- Revisar los registros en busca de peticiones a archivos PHP de esa carpeta.
- Comprobar la integridad del núcleo y buscar archivos, plugins o cuentas de administrador desconocidos.
- Confirmar que el cortafuegos de aplicaciones sigue activo durante las tareas de mantenimiento.

Un análisis limpio no demuestra que la web no se viera comprometida antes de parchear, por lo que las webs que se actualizaron mientras había peticiones sospechosas deberían revisarse con más detalle.

## Plugins y temas: un mes igual de complicado

El fallo del núcleo cierra un octubre complicado también para plugins y temas. The Hacker News informó el 12 de octubre de la [explotación activa de Bricksforge](https://thehackernews.com/2026/10/attackers-exploit-cvss-100-bricksforge.html), un complemento para el constructor Bricks, con la vulnerabilidad CVE-2026-85097, de puntuación máxima (CVSS 10), que permite subir archivos y ejecutar código sin autenticación en versiones hasta la 3.1.8.9. Patchstack detectó ataques desde el 7 de octubre. En la misma campaña se aprovecharon fallos de tipo XSS en WPC Product Bundles for WooCommerce (CVE-2026-93836, corregido en 8.6.7) y Ninja Forms (CVE-2026-94504, corregido en 3.15.4) para instalar un plugin con puerta trasera, crear un administrador oculto y una URL de acceso mágico. En esos casos, actualizar no elimina una infección previa.

El contexto general tampoco ayuda. OpenSecurity contó que en octubre [las CVE publicadas en 2026 ya casi duplican todo 2025](https://www.opensecurity.es/octubre-negro-cve-2026-nvd-record-vulnerabilidades/), y wpdirecto explicó el 21 de octubre [qué suponen para WordPress los fallos críticos de PHP](https://wpdirecto.com/fallos-criticos-php-wordpress-que-hacer/). Con tantos frentes abiertos, la lección del mes es que el propio mantenimiento, incluida la actualización, también forma parte de la superficie de ataque.

## Preguntas frecuentes

### ¿Qué es CVE-2026-119977?

Una vulnerabilidad del núcleo de WordPress, de puntuación 8,1, que permite ejecutar código PHP sin autenticación aprovechando la carpeta temporal que se usa durante una actualización.

### ¿Qué versiones de WordPress están afectadas?

Desde la 4.7 hasta la 7.1.3. Está corregida en la 7.1.4 y en versiones equivalentes para cada rama, como 7.0.8, 6.9.11 o 6.8.12.

### ¿Hay webs comprometidas por este fallo?

No se han confirmado. Wordfence llegó a bloquear más de 70.000 intentos en 24 horas, pero son intentos, no compromisos.

### ¿Cómo protegerse además de actualizar?

Bloqueando el acceso público a wp-content/upgrade/ desde el servidor web, revisando los registros y comprobando que no hay archivos, plugins o administradores desconocidos.

**Fuentes:**

- [WordPress.org: WordPress 7.1.4](https://wordpress.org/support/wordpress-version/version-7-1-4/)
- [Brandefense: WordPress 7.1.4 Security Update](https://brandefense.io/security-news/wordpress-7-1-4-security-update-upgrade-window/)
- [The Hacker News: WordPress RCE flaw draws nearly 63,000 attack attempts](https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html)
- [Ostorlab: WordPress Core Upgrade-Window RCE (CVE-2026-119977)](https://blog.ostorlab.co/wordpress-core-upgrade-window-rce-cve-2026-119977.html)
- [Cyber Press: Hackers exploit WordPress RCE flaw](https://cyberpress.org/hackers-exploit-wordpress-rce-flaw/)
- [The Hacker News: Attackers exploit CVSS 10.0 Bricksforge flaw](https://thehackernews.com/2026/10/attackers-exploit-cvss-100-bricksforge.html)