WordPress 7.1.4: el fallo que se aprovecha justo mientras tu web se actualiza

Publicado el 6 noviembre 2026 · Equipo mitza.es

El 28 de octubre de 2026 WordPress publicó la versión 7.1.4, una actualización de seguridad que corrige una debilidad en el propio proceso de actualización del núcleo. Seis días después, el 3 de noviembre, la agencia estadounidense CISA añadió el fallo, identificado como CVE-2026-119977, a su catálogo de vulnerabilidades explotadas activamente (KEV). Es decir: ya no es un riesgo teórico. Resumimos lo que está confirmado a fecha de 6 de noviembre de 2026 y lo que todavía no lo está.

Qué ha pasado, paso a paso

• 28 de octubre: WordPress.org publica la 7.1.4 como versión de seguridad. El anuncio describe «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» y la atribuye a Umut Bayram, el investigador que la reportó.
• 3 de noviembre: CISA incluye CVE-2026-119977 en el catálogo KEV, «con base en evidencias de explotación activa». La fecha límite que fija para las agencias federales de EE. UU. es el 6 de noviembre.
• Antes de la alerta: según el análisis de SOC Prime, que recoge telemetría de honeypots publicada por The Hacker News, hubo intentos de explotación ya el 30 de octubre. Son intentos registrados, no ataques con éxito confirmado.

Una precisión: el anuncio de WordPress.org no cita el número de CVE. La relación entre ese aviso y CVE-2026-119977 se establece por la descripción del fallo y por el investigador que lo reportó; CISA enlaza la versión 7.1.4 en su propia ficha.

Qué es exactamente este fallo

CISA lo clasifica como una condición de carrera de tipo time-of-check time-of-use (TOCTOU, CWE-367) y explica que podría permitir a atacantes sin autenticar ejecutar código en el servidor durante la «ventana de actualización». La causa que cita es técnica pero fácil de entender con una analogía:

Cuando WordPress actualiza su núcleo con un paquete completo, descarga los archivos nuevos y los deja preparados en una zona intermedia antes de sustituir a los antiguos. Según CISA, esas rutas de preparación eran predecibles y accesibles desde la web. Es como si, mientras cambias la cerradura de casa, dejaras la caja con las llaves nuevas en el felpudo durante unos minutos: el peligro no existe el resto del año, pero durante esos minutos cualquiera que pase por allí puede aprovecharlo.

Por lo publicado, el riesgo se concentra en ese intervalo, y SOC Prime valora la complejidad del ataque como alta (puntuación CVSS 3.1 de 8,1 según su análisis; no hemos podido contrastarla en la base de datos NVD). Eso no es un motivo para esperar: el parche está disponible y WordPress recomienda actualizar de inmediato.

Versiones afectadas

SOC Prime señala que el fallo afecta a WordPress desde la versión 4.7 hasta la 7.1.3, y que la corrección se ha trasladado a las ramas antiguas que aún reciben parches de seguridad. WordPress.org confirma esto último: las correcciones se han portado «a todas las ramas elegibles para recibir correcciones de seguridad (actualmente hasta la 4.7)», pero avisa de que esas versiones antiguas se están publicando a medida que están listas. Si tu web está en una rama antigua, comprueba en el panel de actualizaciones si ya tienes disponible la versión de tu rama o, tras hacer una copia y una prueba, salta a la 7.1.4.

Qué hacer hoy: checklist

1. Comprueba tu versión. En el panel, entra en Escritorio → Actualizaciones. Si no es la 7.1.4 (o la corrección de tu rama), actualiza.
2. Haz una copia antes de actualizar, sin retrasar la actualización por ello. Si no tienes un sistema ordenado, aquí explicamos la regla 3-2-1 de copias de seguridad.
3. No des por hecho que la actualización automática terminó bien. WordPress.org indica que, en los sitios con actualizaciones en segundo plano, el proceso empieza solo. Verifica en el panel que la versión es la correcta y que no hay un aviso de actualización fallida.
4. Pregunta a tu hosting. Algunos proveedores de WordPress gestionado actualizan por ti. Pídele que te confirme por escrito versión y fecha.
5. Revisa si hubo actividad rara si tu web hizo una actualización del núcleo en las últimas semanas: usuarios administradores que no reconoces, archivos nuevos o modificados en la raíz y en wp-content, cambios en wp-config.php o en .htaccess. Según SOC Prime, las peticiones observadas apuntaban a rutas temporales del instalador (como setup-config.php), así que también puedes buscar esas rutas en los registros de acceso de tu servidor.
6. Cambia credenciales si tienes dudas (administradores, base de datos, SFTP) y revisa los plugins instalados: elimina los que no uses.
7. Anota fecha y acciones. Si hubiera datos personales afectados, esa cronología te servirá para valorar con tu asesor si hay que notificar a la AEPD.

Dos matices honestos: la ficha de CISA indica que no se sabe si se usa en campañas de ransomware y que exige un triaje forense según su directiva BOD 26-04, dirigida a las agencias federales de EE. UU. Para una pyme, la traducción práctica es: si tu web actualizó su núcleo en las últimas semanas con una versión vulnerable, merece una revisión, no solo un parche.

Si crees que tu web ya está comprometida

Señales como redirecciones raras, páginas que no has creado, usuarios nuevos, avisos de Google o un hosting que suspende la cuenta son motivo de actuar con orden. Hemos preparado una guía paso a paso: mi web WordPress está hackeada: qué hacer, señales, limpieza y prevención. Para una revisión profesional, nuestra auditoría de seguridad web comprueba versiones, usuarios, archivos y configuración del servidor.

Por qué esto se repite y cómo reducir el riesgo

Se suma a otros avisos graves de WordPress que hemos contado este otoño: el fallo de CVE-2026-87902 en la 7.1.2, la familia wp2shell y los plugins explotados en octubre. WordPress mueve una parte enorme de internet, así que es el objetivo más rentable. No significa que no deba usarse; significa que no puede dejarse sin mantenimiento.

• Mantén un calendario de actualizaciones del núcleo, los plugins y el tema, y un plazo máximo para los parches críticos.
• Usa un entorno de pruebas (staging) para ensayar actualizaciones importantes antes de aplicarlas en producción.
• Pon un cortafuegos de aplicación web (WAF): reduce intentos, pero no sustituye a actualizar, porque el fallo está en el propio WordPress. Si quieres entender la primera línea de defensa, lee qué es un firewall y qué necesita una pyme.
• Activa verificación en dos pasos y contraseñas únicas para todos los administradores.
• Delega el mantenimiento si no es tu trabajo: tienes el desglose de qué incluye en mantenimiento web: qué incluye y cuánto cuesta.

Preguntas rápidas

¿Me afecta si mi WordPress está en WordPress.com?

Los avisos que hemos revisado hablan de instalaciones de WordPress que actualizan su propio núcleo. Si tu web está en una plataforma gestionada, pregunta a tu proveedor si ya ha aplicado la corrección; no hemos encontrado una declaración específica de WordPress.com al respecto.

¿Sirve de algo desactivar plugins?

No para este fallo: está en el núcleo, no en un plugin. La medida eficaz es actualizar a la versión corregida.

¿Tengo que preocuparme si ya actualicé?

Si tu web actualizó su núcleo antes del 28 de octubre, esa actualización la hizo una versión vulnerable; el riesgo concreto depende de si alguien atacó justo entonces. Merece una revisión rápida de usuarios y archivos. Si actualizaste después, comprueba solo que la versión es la correcta.

Cómo te ayudamos en Mitza

Actualizamos y revisamos WordPress dentro de nuestro servicio de mantenimiento web, con copias, pruebas previas y aviso si algo falla. Si prefieres empezar por saber en qué estado está tu web, cuéntanos tu caso desde la página de contacto.

Lectura relacionada: el zero-day de Ivanti Connect Secure y mantenimiento informático para pymes.