Saltar al contenido
ConsultoriaNet
Desarrollo web y digitalización

WordPress 7.1.4: qué revisar al actualizar

WordPress 7.1.4 corrige fallos de seguridad del propio WordPress que no se arreglan con plugins. Cómo comprobar tu versión y qué probar después.

Por · 29 de octubre de 2026 · 7 min de lectura
Iconos de línea verde menta sobre fondo azul: un escudo con una marca de verificación, una flecha circular de actualización y una lista con casillas, con un pequeño punto ámbar
En esta página

El 28 de octubre de 2026, WordPress publicó la versión 7.1.4. Es una actualización solo de seguridad, y el anuncio oficial pide aplicarla de inmediato. Corrige fallos del propio WordPress, la base sobre la que funcionan tu web, tu tienda y todos tus plugins.

Para quien dirige un negocio, lo importante es esto: tener los plugins al día no cubre esta corrección. Tampoco que el hosting haya actualizado su servidor. Es una pieza distinta y hay que comprobarla aparte. Te explicamos qué se corrigió, cómo saber si tu web ya la tiene y qué probar cuando esté aplicada.

En 30 segundos
  • WordPress 7.1.4 corrige doce fallos de seguridad del núcleo, es decir, del propio WordPress. Actualizar plugins, el tema o el PHP del servidor no los corrige.
  • Muchas webs la reciben solas, porque WordPress instala por su cuenta las actualizaciones menores de seguridad. Pero eso se puede desactivar, así que hay que mirar el número de versión, no suponerlo.
  • Si tu web está en una versión antigua de WordPress, la corrección puede llegar más tarde o no llegar: solo la última versión recibe soporte completo.

Qué se corrigió

Una web en WordPress tiene tres capas que se actualizan por separado: el núcleo (WordPress en sí), los plugins y el tema. Debajo está el servidor, con PHP, que es cosa del hosting. Esta actualización es de la primera capa.

Según el anuncio oficial de WordPress 7.1.4, consultado el 29 de octubre de 2026, la versión corrige doce problemas de seguridad y actualiza los certificados que WordPress usa para comunicarse de forma segura con otros servicios. Los más relevantes para un negocio son estos:

  • Un fallo en el propio proceso de actualización que podría permitir ejecutar código en el servidor mientras la actualización está en curso. Es el más grave de la lista. El anuncio no explica en qué condiciones puede aprovecharse, y Search Engine Journal señala justo eso: no se sabe si hace falta haber iniciado sesión.
  • Varios fallos de tipo XSS (secuencias de comandos en sitios cruzados). En palabras simples: alguien consigue guardar en la web un fragmento de código que después se ejecuta en el navegador de quien la visita o la administra. Afectan a bloques del editor, al personalizador, a los comentarios y a otras partes.
  • Datos que se podían ver sin permiso, como cambios del personalizador aún sin publicar o notas internas visibles para usuarios que no deberían leerlas.

Search Engine Journal añade que muchos de estos fallos exigen tener una cuenta con cierto nivel de acceso en la web (por ejemplo, de colaborador), lo que los hace más difíciles de aprovechar, pero que no es así en todos los casos. El anuncio no informa de ataques en curso. No es motivo para alarmarse, pero sí para no dejarlo para el mes que viene.

Para ubicar esta versión en el calendario, estas son las fechas de las fuentes oficiales:

  1. 6 oct 2026WordPress 7.1.3, actualización de mantenimiento y seguridad con siete correcciones de seguridad.
  2. 28 oct 2026WordPress 7.1.4, solo de seguridad. El anuncio pide actualizar de inmediato.
  3. 8 dic 2026Fecha prevista de WordPress 7.2, la próxima versión grande. Hoy está en fase de pruebas (beta).

Cómo saber si tu web ya la tiene

WordPress instala solo, por defecto, las actualizaciones menores del núcleo: las de mantenimiento y seguridad, como esta. Lo explica la documentación de WordPress sobre actualizaciones automáticas. El anuncio de la 7.1.4 lo confirma: las webs con esas actualizaciones activas se actualizan por su cuenta.

El problema es que esa función se puede apagar, y a veces está apagada sin que el dueño de la web lo sepa: la desactivó un desarrollador, la bloquea un plugin o el hosting la gestiona a su manera. Por eso no basta con suponer. Hay que mirar el número:

En WordPress:EscritorioActualizacionesVersión instalada

Si ahí ves «Tienes la última versión de WordPress» y el número es 7.1.4 o posterior, la corrección está aplicada. Si aparece un aviso para actualizar, no lo está.

La lectura según lo que encuentres:

¿Qué hacer según tu versión?
Lo que vesQué significaQué hacer
7.1.4 o posteriorLa corrección está aplicadaProbar formularios, compras y acceso (más abajo)
7.1.3 o anterior en la rama 7.1Falta la correcciónActualizar ya, con una copia de seguridad antes
Una versión de una rama más antigua (por ejemplo, 6.x)Puede recibir la corrección más tarde, o no recibirlaPlanificar el paso a la versión actual con quien mantiene la web
7.2 en betaUna versión de pruebas, no pensada para una web en producciónVolver a una versión estable con quien mantiene la web

Sobre las versiones antiguas, el anuncio dice que las correcciones se llevan «como cortesía» a las ramas que aún pueden recibir arreglos de seguridad, desde la 4.7, y que esas versiones se publicarán a medida que estén listas. También recuerda que solo la última versión tiene soporte activo. En la práctica: si tu web sigue en una versión vieja, no des por hecho que hoy ya está protegida.

Qué pedirle a quien mantiene tu web

Si la web la lleva una agencia, un desarrollador o el equipo de tu hosting, no hace falta que entres tú a actualizar. Lo que sí conviene es pedir respuestas que se puedan comprobar:

Pregunta 1
¿Qué versión de WordPress tiene hoy mi web? Si tienes más de una web o una copia de pruebas, la de cada una.
Pregunta 2
¿Cuándo se aplicó la 7.1.4? Una fecha. Si todavía no se aplicó, cuándo se va a aplicar.
Pregunta 3
¿Hay una copia de seguridad reciente que se pueda restaurar? No solo que exista: que alguien haya comprobado que funciona.
Pregunta 4
¿Las actualizaciones automáticas del núcleo están activas? Si están apagadas, por qué, y quién se encarga de aplicar las de seguridad.

La última pregunta es la más útil a largo plazo. Apagar las actualizaciones automáticas puede tener sentido en webs con desarrollos a medida, pero entonces alguien tiene que estar pendiente de cada anuncio de seguridad. Si nadie lo está, el riesgo solo cambia de lugar.

Antes y después de actualizar

Una actualización menor como esta rara vez rompe algo, porque solo corrige fallos. Aun así, en webs con plugins antiguos o código a medida puede aparecer algún problema. El orden razonable es este:

  1. Copia de seguridad antes. Que se pueda restaurar, no solo que exista. Lo explicamos en probar una copia de seguridad de WordPress.
  2. Actualizar el núcleo. Desde el escritorio, en Actualizaciones, o dejando que lo haga la actualización automática.
  3. Probar lo que trae clientes, en el móvil y en la computadora:
    • Los formularios. Un envío de prueba que llegue de verdad a quien tiene que llegar. Si falla, el recorrido para encontrar dónde se corta está en el formulario de WordPress dice «enviado», pero el correo no llega.
    • El proceso de compra, si tienes tienda: un pedido de prueba hasta la página de confirmación y el correo al cliente.
    • El acceso al panel. Que tú y tu equipo puedan entrar y editar como siempre.

Si algo deja de funcionar, lo habitual es que la causa sea un plugin o el tema que no estaba preparado. La salida no es volver a la versión anterior de WordPress y quedarse ahí, sino corregir o sustituir esa pieza.

Lo que no conviene hacer

  • Dar por hecho que estás protegido porque los plugins están al día. Esta corrección es del núcleo, no de los plugins.
  • Confundir esta actualización con la beta de WordPress 7.2. La 7.1.4 es la versión estable con las correcciones; la beta es para pruebas y no debería estar en una web que atiende clientes.
  • Instalar un plugin que promete «blindar» WordPress en lugar de actualizar. Un plugin de seguridad puede sumar protección, pero no corrige el código del núcleo. La corrección es la actualización.
  • Suponer que tu web fue atacada. El anuncio no lo indica. Si notas algo raro, como usuarios que no reconoces o cambios que nadie hizo, eso merece una revisión aparte.

Esta es la segunda pieza de un mismo trabajo. La primera, el servidor, la contamos en parches de PHP: qué pedirle a tu hosting. La tercera son los plugins: cuáles conviene dejar en automático y cuáles no está en actualizaciones automáticas en WordPress.

Auditoría gratuita

¿Quieres que lo revisemos en tu sitio?

Auditoría inicial gratuita, con respuesta en 24 horas laborables.

Respuesta en 24 hSin compromisoEspañol e inglés

También puedes escribir a hola@consultorianet.com.

Si todavía no tienes web, déjalo vacío y cuéntanos el proyecto.
Objetivo, plazo y lo que ya hayas probado. Cuanto más concreto, más útil será la respuesta.

También puedes escribir a hola@consultorianet.com.