WordPress 7.1.4 salió el 28 de octubre de 2026 y corrige 22 fallos de seguridad. Uno de ellos permite ejecutar código en el servidor sin iniciar sesión mientras la web se actualiza, y Wordfence ha bloqueado más de 18.000 ataques contra él en un solo día. Hay que actualizar WordPress a la 7.1.4, o a la versión corregida de tu rama si usas una anterior. Esa misma semana, Contact Form 7 corrigió otro fallo grave en su versión 6.2.4.
Lo que nos encontramos al revisar nuestras webs
Esta semana hemos revisado las webs que mantenemos. Unas estaban en la 7.1.4 desde el mismo 28 de octubre, porque WordPress se había actualizado solo. Otras no lo habían hecho por su cuenta.
La diferencia no estaba en la web, sino en cómo se instaló. Las que no se habían actualizado llevaban un plugin obligatorio de Installatron, el instalador que usan algunos alojamientos. Ese plugin apaga las actualizaciones automáticas de WordPress y deja esa tarea en manos del panel del alojamiento. Las actualizamos a mano ese mismo día, con copia de seguridad previa, y comprobamos que seguían funcionando y que las tiendas seguían ofreciendo sus formas de pago.
El aviso oficial está en wordpress.org. El fallo más serio es el CVE-2026-119977, que Wordfence puntúa con 8,1 sobre 10. Afecta desde la versión 4.7 hasta la 7.1.3 y, según Wordfence, se debe a las rutas predecibles y accesibles desde la web que WordPress usa durante una actualización completa.
Lo que no es
No es un agujero abierto a todas horas: el atacante tiene que actuar mientras WordPress se está actualizando. Eso lo hace más difícil, pero los ataques bloqueados demuestran que ya hay quien lo intenta.
Un plugin de seguridad tampoco lo sustituye. La regla de Wordfence para este fallo llegó al momento a sus versiones de pago, y la versión gratuita la recibe 30 días después.
¿A quién le afecta y qué hay que actualizar?
- Webs con WordPress 7.1. Hay que pasar a la 7.1.4.
- Webs en versiones anteriores. Cada rama tiene su versión corregida, como la 7.0.8, la 6.9.11 o la 6.8.12, y llegan hasta la 4.7.39. Las versiones 4.6 y anteriores ya no reciben parches: la única salida es pasar a una versión con soporte.
- Webs con Contact Form 7, versiones 6.2 a 6.2.3. El fallo permite subir archivos sin iniciar sesión y se corrige en la 6.2.4. Wordfence lo puntúa con 9,8 sobre 10 y Patchstack con 8,1, porque el atacante no conoce la carpeta aleatoria donde queda el archivo. Las versiones anteriores a la 6.2 no tienen este fallo.
- Webs instaladas con Installatron. Las actualizaciones automáticas de WordPress están apagadas, así que todo depende de cómo esté configurado el panel del alojamiento.
Cómo comprobarlo en cinco minutos
- En el escritorio de WordPress, entra en Escritorio/Actualizaciones. Ahí aparece tu versión, que debe ser la 7.1.4 o la corregida de tu rama.
- Entra en Plugins/Plugins instalados y busca Contact Form 7. Si su versión está entre la 6.2 y la 6.2.3, actualízalo.
- En esa misma pantalla, abre la pestaña Imprescindibles. Si aparece WordPress automation by Installatron, WordPress no se actualizará solo: revisa en el panel del alojamiento cómo están configuradas las actualizaciones.
- Antes de actualizar, haz una copia de seguridad. Después, abre la portada, prueba el formulario de contacto y, si vendes online, comprueba que siguen apareciendo las formas de pago.
Lo que aprendimos
Que una actualización automática solo protege si está encendida. En octubre contábamos que la vulnerabilidad crítica de PHP no se arreglaba desde WordPress. Esta sí, pero dar por hecho que WordPress se actualiza solo puede dejar una web expuesta durante días.
En días como hoy, la parte del mantenimiento web que más pesa es mirar qué versión tiene cada web cuando sale un parche. Si no sabes quién actualiza la tuya, compruébalo hoy, mientras los ataques siguen buscando webs sin actualizar.
