WordPress y seguridad en 2026: ¿debemos preocuparnos por tantas actualizaciones?

Si administras una web en WordPress y durante los últimos meses has tenido la sensación de estar actualizando constantemente, no eres el único.

2026 está siendo un año especialmente activo en materia de seguridad para WordPress. En apenas unos meses hemos visto varias versiones destinadas a corregir vulnerabilidades y algunas de ellas han solucionado problemas considerados críticos.

La última ha sido WordPress 7.1.3, publicada el 6 de octubre de 2026, con siete correcciones de seguridad y cuatro correcciones adicionales de errores. Entre los problemas solucionados encontramos vulnerabilidades XSS, una posible denegación de servicio, una inyección SQL de segundo orden y diferentes problemas relacionados con permisos y exposición de información.

Y llega solo dos semanas después de WordPress 7.1.2.

Es normal, por tanto, hacerse una pregunta:

¿Qué está pasando con WordPress? ¿Sigue siendo seguro utilizarlo?

La respuesta corta es que sí. Pero la respuesta interesante necesita algunos matices.

2026 está siendo un año movido para la seguridad de WordPress

No estamos hablando simplemente de pequeñas actualizaciones de mantenimiento.

En julio se publicó WordPress 7.0.2 para corregir una vulnerabilidad crítica y otra de gravedad alta. La situación fue suficientemente importante como para que WordPress activase actualizaciones automáticas en las versiones afectadas.

En agosto llegó WordPress 7.0.4, que solucionaba una vulnerabilidad que podía permitir ejecución remota de código a usuarios con determinados permisos en configuraciones concretas.

El 17 de septiembre apareció WordPress 7.1.1 con once correcciones de seguridad, además de numerosas correcciones en el Core y el editor de bloques.

Cinco días después, el 22 de septiembre, WordPress 7.1.2 solucionaba una vulnerabilidad calificada oficialmente como crítica. Bajo unas condiciones concretas de servidor y del tema utilizado, un atacante no autenticado podía provocar la inclusión de determinados archivos PHP locales, pudiendo llegar a conseguir ejecución remota de código.

Y el 6 de octubre llega WordPress 7.1.3 con otras siete correcciones de seguridad.

Visto así, la sensación de estar ante una sucesión inusual de actualizaciones resulta bastante comprensible.

Pero que se descubran vulnerabilidades no significa necesariamente que WordPress sea ahora menos seguro.

Una vulnerabilidad encontrada también es una vulnerabilidad que puede corregirse

Existe cierta paradoja cuando hablamos de seguridad informática.

Cuantos más investigadores analizan un software, más vulnerabilidades aparecen. Y cuanto mayor es su base de usuarios, mayor es también el interés en estudiarlo, tanto por parte de investigadores de seguridad como de posibles atacantes.

WordPress tiene ambas características.

A día de hoy se utiliza en aproximadamente cuatro de cada diez webs y continúa siendo, con mucha diferencia, el gestor de contenidos más utilizado del mundo.

Es una superficie enorme.

Un problema de seguridad en WordPress puede afectar potencialmente a millones de instalaciones, así que existe un incentivo extraordinario para buscar vulnerabilidades en su código.

Lo importante, por tanto, no es únicamente contar cuántos fallos aparecen. También importa cómo se comunican, cuánto se tarda en corregirlos y cómo se distribuyen posteriormente esas correcciones.

Que una vulnerabilidad se descubra, se comunique de forma responsable y termine solucionada mediante una actualización es precisamente cómo debería funcionar un ecosistema de software maduro.

Eso no significa que debamos restarle importancia.

Este año ha habido vulnerabilidades serias en el propio Core y algunas han requerido una actuación inmediata. Lo razonable no es alarmarse, pero tampoco ignorarlas.

WordPress no es solo WordPress

Hay otra cuestión fundamental para entender la seguridad de cualquier instalación.

Cuando hablamos coloquialmente de una “web WordPress”, en realidad estamos hablando de un conjunto de software bastante más amplio:

WordPress Core, plugins, theme, desarrollos personalizados, librerías PHP y JavaScript, versión de PHP, servidor web, base de datos, sistema operativo, servicios externos, usuarios y configuración del servidor.

Y cada nueva pieza amplía la superficie de ataque.

Este punto es especialmente importante porque la gran mayoría de vulnerabilidades conocidas del ecosistema WordPress no corresponden al propio Core.

Los datos recopilados durante 2026 por plataformas especializadas en seguridad WordPress sitúan aproximadamente un 89 % de las vulnerabilidades registradas en plugins y alrededor de un 10 % en themes. El Core representa únicamente una pequeña parte del total.

Por eso instalar indiscriminadamente plugins para resolver cualquier pequeña funcionalidad tiene consecuencias.

Cada plugin incorpora código de un tercero que tendremos que mantener durante toda la vida del proyecto.

No significa que debamos evitar los plugins. Son una de las grandes ventajas de WordPress. Pero sí significa que hay que seleccionarlos con criterio.

¿Entonces WordPress es seguro?

Nosotros responderíamos que sí, con una condición importante:

WordPress es seguro cuando se mantiene correctamente.

Y esto es aplicable prácticamente a cualquier software conectado a Internet.

Una instalación actualizada, con plugins bien mantenidos, un servidor correctamente configurado, copias de seguridad, usuarios protegidos y una política razonable de mantenimiento es muy diferente de una instalación que lleva dos años sin actualizarse.

El problema aparece cuando seguimos pensando en una página web como un producto que se termina.

Se diseña, se desarrolla, se publica… y se olvida.

Una web moderna es software en producción.

Y el software necesita mantenimiento.

En nuestros proyectos de diseño y desarrollo web con WordPress intentamos plantear precisamente esa continuidad desde el principio: no solo importa cómo se construye una web, sino cómo podrá mantenerse después.

Actualizar tampoco debería significar pulsar botones sin mirar

Aquí aparece la otra cara del problema.

Si existe una vulnerabilidad de seguridad, debemos actualizar cuanto antes. Pero actualizar WordPress, un theme o determinados plugins también puede introducir incompatibilidades o cambiar comportamientos existentes.

Cuanto más compleja sea la web, mayor será este riesgo.

Una pequeña web corporativa con pocas dependencias no tiene las mismas necesidades que un WooCommerce, una web multidioma, una plataforma conectada con sistemas externos o un proyecto con desarrollos específicos.

Por eso en proyectos de cierta complejidad nuestro proceso no consiste simplemente en entrar en WordPress y pulsar “Actualizar todo”.

Antes hay que valorar qué se está actualizando y qué impacto puede tener.

Cuando la situación lo requiere, trabajamos sobre una copia o entorno de pruebas, realizamos las actualizaciones, comprobamos las partes críticas de la web y, una vez validado el resultado, llevamos los cambios a producción.

Es algo que también explicamos en nuestra sección de preguntas frecuentes sobre actualizaciones y mantenimiento: una actualización puede solucionar un problema de seguridad y, al mismo tiempo, generar una incompatibilidad con otro componente del proyecto.

También necesitamos copias de seguridad fiables.

No porque esperemos que algo salga mal, sino porque cualquier procedimiento profesional debe contemplar qué hacer si ocurre.

La seguridad no consiste únicamente en impedir un ataque. También consiste en tener capacidad para recuperarse rápidamente ante cualquier incidencia.

Menos dependencias también significa menos superficie de ataque

Durante los últimos años hemos ido reforzando una idea en nuestros desarrollos WordPress: utilizar únicamente las dependencias que realmente necesita cada proyecto.

No tiene demasiado sentido instalar un plugin complejo para resolver una funcionalidad pequeña si esta puede implementarse de una forma sencilla y controlada.

Tampoco tiene sentido mantener plugins que ya no se utilizan.

Cuantas más piezas incorpora una instalación, más actualizaciones tendremos que vigilar, más posibilidades existen de incompatibilidad y mayor es la superficie de ataque.

Un WordPress profesional no debería medirse por el número de plugins que tiene instalados, sino por lo bien elegidos que están.

Esto también afecta a la arquitectura del desarrollo. Cuando una funcionalidad propia empieza a crecer, conviene plantearse si debería seguir formando parte del theme o convertirse en un plugin independiente. Separar correctamente diseño, datos y lógica facilita mucho el mantenimiento futuro.

La seguridad empieza mucho antes de instalar un plugin de seguridad

También existe cierta tendencia a reducir la seguridad de WordPress a instalar Wordfence, Sucuri o cualquier otra herramienta similar.

Este tipo de soluciones puede formar parte de una estrategia de seguridad, pero no sustituye al mantenimiento.

La seguridad real empieza bastante antes:

• mantener actualizado el software;
• limitar usuarios y permisos;
• utilizar contraseñas robustas y autenticación adicional cuando sea necesario;
• eliminar componentes abandonados;
• proteger las copias de seguridad;
• mantener PHP y el servidor actualizados;
• revisar logs y monitorización;
• y reducir dependencias innecesarias.

Un plugin de seguridad puede añadir una capa adicional.

No puede compensar una instalación abandonada.

Y cuando aparece algo extraño tampoco conviene actuar a ciegas. Por ejemplo, si encontramos usuarios o roles sospechosos en WordPress, borrar las cuentas inmediatamente puede eliminar el síntoma sin descubrir cómo llegaron allí.

En seguridad, entender primero qué ha ocurrido suele ser tan importante como corregirlo.

¿Tiene futuro WordPress?

Esta es probablemente la otra pregunta que aparece cada vez que hay una sucesión de vulnerabilidades.

Nuestra opinión es que sí.

WordPress continúa funcionando en aproximadamente cuatro de cada diez webs y mantiene una posición extraordinariamente dominante entre los gestores de contenido.

Además, el proyecto continúa evolucionando activamente.

WordPress 7.2 está previsto para finales de 2026 y su hoja de ruta contempla específicamente nuevas iniciativas relacionadas con la seguridad, incluyendo mejoras en Application Passwords, mecanismos para almacenar secretos y credenciales de manera adecuada y sistemas de reautenticación para determinadas operaciones administrativas sensibles.

No parece precisamente un proyecto detenido.

Lo que sí está cambiando es la forma en la que creemos que debemos trabajar con WordPress.

Durante muchos años su facilidad de instalación creó la percepción de que cualquiera podía montar una web, instalar una colección de plugins y olvidarse prácticamente de su mantenimiento.

Para determinados proyectos esa etapa se está terminando.

WordPress sigue siendo una herramienta extraordinariamente flexible para crear webs corporativas, ecommerce, portales de contenido e incluso aplicaciones con desarrollos completamente personalizados.

Pero esa flexibilidad tiene un coste: hay que gestionar correctamente el ecosistema que construimos alrededor del Core.

No nos preocupa que WordPress publique actualizaciones de seguridad

De hecho, nos preocuparía bastante más lo contrario.

Que un software con millones de instalaciones no publicase nunca vulnerabilidades sería difícil de creer.

Lo que sí nos obliga este 2026 es a prestar más atención a los procesos de mantenimiento.

Especialmente cuando una web forma parte de la operativa de una empresa, recibe tráfico importante, gestiona datos personales, realiza ventas o está integrada con otros sistemas.

En estos casos actualizar deja de ser una tarea administrativa para convertirse en parte de la gestión técnica del proyecto.

Y quizá esa sea la principal conclusión que podemos sacar de este año:

el problema no es que WordPress necesite actualizaciones. El problema es seguir planteando webs WordPress como si no fueran a necesitarlas.

Y después de todo esto, quedan algunas dudas bastante razonables que solemos encontrarnos cuando hablamos de actualizaciones y seguridad en WordPress.