WordPress publicó la versión 7.1.4 el 28 de octubre de 2026, con correcciones para 22 problemas de seguridad. Uno de ellos es poco habitual: no está en un plugin ni en un tema, sino en el propio actualizador de WordPress, y puede aprovecharse sin tener una cuenta en tu sitio.
Los atacantes reaccionaron rápido. Wordfence publicó una regla de firewall la misma tarde del lanzamiento y detectó el primer intento de ataque nueve minutos después. En los días siguientes llegó a bloquear decenas de miles de intentos cada 24 horas. En esta guía te explicamos en qué consiste el fallo, qué versiones lo corrigen y cómo actualizar sin dejar la puerta abierta mientras lo haces.
Puntos clave
- WordPress 7.1.4 (28 de octubre de 2026) corrige 22 problemas de seguridad. Todos los sitios deberían estar en esta versión o en la versión corregida de su rama.
- El fallo principal, CVE-2026-119977, permite a un atacante sin cuenta ejecutar código durante una actualización del núcleo. Wordfence lo califica con un 8.1 (Alto).
- Los atacantes empezaron a hacer pruebas a los nueve minutos de publicarse la primera regla de firewall, y desde entonces se registran decenas de miles de intentos al día.
- Bloquea el acceso web a wp-content/upgrade/ antes de actualizar; después, actualiza y busca señales de intrusión.
- WordPress 4.6 y versiones anteriores no reciben ninguna corrección. Esos sitios necesitan una actualización completa.
En resumen Añade la regla de una línea que verás más abajo para bloquear el acceso web a wp-content/upgrade/, actualiza a 7.1.4 (o a la versión corregida de tu rama) y, después, comprueba que no haya usuarios administradores desconocidos. Si tu sitio usa WordPress 4.6 o una versión anterior, no hay corrección: necesita una actualización completa.
En qué consiste el fallo del actualizador
El fallo está registrado como CVE-2026-119977. Wordfence lo califica con un 8.1 sobre 10 (Alto). WordPress le asigna una puntuación más baja, porque es difícil de explotar, pero "difícil" no significa "seguro" cuando hay bots que pueden intentarlo miles de veces al día.
Cuando WordPress instala una actualización completa del núcleo, primero descomprime los archivos nuevos en una carpeta dentro de wp-content/upgrade/. En las versiones afectadas, esa carpeta tenía un nombre predecible y, en muchos servidores, era accesible desde la web. Durante unos segundos, cualquiera podía abrir la copia del instalador de WordPress que contenía y apuntarla a una base de datos controlada por el atacante, lo que le permitía ejecutar código en tu servidor.
Tienen que coincidir cuatro condiciones: debe estar ejecutándose una actualización de paquete completo, la carpeta debe ser accesible desde la web, el atacante debe encontrar su ruta y tiene que ganar la carrera antes de que WordPress haga limpieza. Los bots se encargan de las tres últimas consultando los sitios una y otra vez, y por eso las cifras de intentos son tan altas.
La versión 7.1.4 lo soluciona añadiendo 16 caracteres aleatorios al nombre de la carpeta temporal, manteniendo un archivo index.php de protección en la carpeta de actualización y negándose a copiar la configuración desde la copia temporal. Las otras 21 correcciones abarcan cross-site scripting, problemas de la Interactivity API, divulgación de información a visitantes sin sesión iniciada, comprobaciones de permisos y una actualización de los certificados raíz incluidos.
Qué versiones están corregidas
La corrección se ha portado a todas las ramas que siguen recibiendo actualizaciones de seguridad. Actualiza como mínimo a:
- 7.1.4 en la rama 7.1, o 7.0.8 en la 7.0;
- 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 o 6.4.14 en las ramas 6.x;
- la versión corregida correspondiente en las ramas 6.x más antiguas, 5.x y 4.7–4.9, hasta 4.7.39.
WordPress 4.6 y versiones anteriores no reciben corrección. Además, las versiones portadas solo cubren problemas de seguridad, así que lo ideal para cualquier sitio es la última versión, 7.1.4.
Paso 1: bloquea primero la carpeta de actualización
El momento vulnerable es la propia actualización, así que cierra la ventana antes de actualizar. Añade esta regla al archivo .htaccess de la carpeta raíz de tu sitio (en cPanel, File Manager › public_html, con los archivos ocultos visibles), encima del bloque # BEGIN WordPress:
# Block web access to WordPress update staging files (CVE-2026-119977)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>Colócala en el .htaccess de la raíz, no dentro de la carpeta de actualización: WordPress vacía esa carpeta antes de cada actualización. La regla no afecta a las actualizaciones, porque WordPress lee esos archivos en el servidor, no a través de la web. Funciona en los servidores LiteSpeed de WebGee y en cualquier servidor compatible con Apache.
Paso 2: actualiza
Haz antes una copia de seguridad reciente. En el hosting cPanel de WebGee, JetBackup puede crear una al momento en unos pocos clics. Después, actualiza desde Escritorio › Actualizaciones › Actualizar a la versión 7.1.4, o por SSH:
# Check the current version
wp core version
# Update core, then the database if asked
wp core update
wp core update-db
# Confirm
wp core versionLos sitios con actualizaciones automáticas en segundo plano ya deberían estar en 7.1.4, pero compruébalo de todos modos. Las actualizaciones automáticas fallan sin avisar más a menudo de lo que se cree, por ejemplo tras un cambio de permisos de archivos o con el disco lleno.
Paso 3: comprueba que nadie haya entrado
En el momento de escribir este artículo no se habían notificado compromisos confirmados, y no hay listas publicadas de direcciones IP ni archivos de los atacantes. Fíjate, en cambio, en comportamientos sospechosos:
Después de actualizar, revisa si hay
- Cuentas de administrador que no reconozcas (Usuarios › Todos los usuarios, filtrando por Administrador)
- Plugins que no hayas instalado, incluidos los que llevan el nombre de tu propio dominio
- Archivos PHP inesperados en wp-content/upgrade/ o wp-content/uploads/
- Solicitudes a setup-config.php u otros archivos PHP en wp-content/upgrade/ en tus registros de acceso
- Cambios en wp-config.php o .htaccess en torno al momento en que se ejecutaron las actualizaciones del núcleo
En el hosting cPanel de WebGee también puedes ejecutar un análisis de malware desde cPanel, y el informe CMS Threats de cPGuard muestra todas las instalaciones de WordPress de la cuenta con su versión del núcleo, así que una copia olvidada que siga en una versión antigua salta a la vista. Si encuentras algo, sigue nuestros pasos para limpiar malware o abre un ticket.
No te olvides de las copias Las instalaciones antiguas en carpetas como /old, /test o /staging reciben los mismos ataques que tu sitio principal, y suelen ser las que nadie actualiza. Actualízalas o elimínalas.
Cuatro actualizaciones de seguridad desde septiembre
La 7.1.4 llega después de la 7.1.1, la 7.1.2 y la 7.1.3 en menos de seis semanas, y WordPress 7.2 sale el 8 de diciembre. Mantenerse al día con todo esto por tu cuenta es un trabajo en sí mismo. Con el hosting WordPress de WebGee tienes copias de seguridad, análisis de seguridad a nivel de servidor, un entorno de staging a partir del plan Turbo e ingenieros en chat en vivo 24/7 que gestionan actualizaciones de WordPress todos los días.
Preguntas frecuentes
¿Qué versiones corrigen CVE-2026-119977?
WordPress 7.1.4, además de versiones corregidas para ramas anteriores, como 7.0.8, 6.9.11, 6.8.12 y hasta 4.7.39. WordPress 4.6 y versiones anteriores no reciben corrección.
Mi sitio se actualiza automáticamente. ¿Tengo que hacer algo?
Comprueba que la actualización se haya aplicado de verdad: en Escritorio › Actualizaciones o con wp core version deberías ver 7.1.4 o la versión corregida de tu rama. Las actualizaciones automáticas pueden fallar sin avisar, por ejemplo por problemas de permisos de archivos.
¿Se puede explotar cuando no hay ninguna actualización en curso?
No. El fallo solo existe durante los pocos segundos en que una actualización completa del núcleo está descomprimiendo archivos en wp-content/upgrade/. Por eso, bloquear esa carpeta antes de actualizar lo neutraliza.
¿Han hackeado a alguien a través de este fallo?
En el momento de escribir este artículo no se habían notificado compromisos confirmados, solo un gran número de intentos bloqueados. Eso puede cambiar rápidamente, así que no esperes.
¿Bloquear wp-content/upgrade/ impedirá las actualizaciones?
No. WordPress lee y escribe en esa carpeta directamente en el servidor; la regla solo impide que navegadores y bots soliciten archivos dentro de ella.
