Estamos en agosto de 2026 y voy a decir algo que hace unos años probablemente habría defendido justo al revés: cada vez me cuesta más recomendar WordPress para un proyecto web serio.
No porque WordPress haya dejado de funcionar. Funciona. Tampoco porque haya desaparecido. Todo lo contrario.
WordPress continúa siendo gigantesco. Según los datos de W3Techs del 25 de agosto de 2026, WordPress está presente en aproximadamente el 40,7 % de todas las webs y conserva cerca del 58,9 % del mercado de CMS conocidos.
Y precisamente ahí empieza parte del problema.
Cuando prácticamente todo el mundo utiliza una tecnología, esa tecnología se convierte en un objetivo extraordinariamente interesante.
Y si además construimos nuestra web añadiendo plugins desarrollados por decenas de proveedores diferentes, algunos mantenidos impecablemente y otros prácticamente abandonados, tenemos una combinación que en 2026 empieza a resultar bastante difícil de defender.
El problema no es exactamente WordPress
Esto hay que dejarlo claro.
El núcleo de WordPress no es necesariamente el desastre de seguridad que algunas personas imaginan.
De hecho, los datos apuntan precisamente en otra dirección.
El informe State of WordPress Security in 2026 de Patchstack contabilizó 11.334 nuevas vulnerabilidades descubiertas en el ecosistema WordPress durante 2025, un incremento del 42 % respecto al año anterior. Sin embargo, el 91 % estaba relacionado con plugins y el 9 % con temas, mientras que solamente se registraron seis vulnerabilidades en el núcleo de WordPress y fueron consideradas de baja prioridad.
El problema, por tanto, no es instalar WordPress.
El problema es lo que viene después.
Quieres un formulario.
Plugin.
Quieres SEO .
Plugin.
Quieres caché.
Plugin.
Quieres gestionar cookies.
Otro plugin.
Quieres hacer copias de seguridad.
Plugin.
Quieres conectar un CRM.
Plugin.
Quieres añadir funcionalidades a WooCommerce.
Tres plugins más.
Y cuando terminas, aquella instalación de WordPress que parecía sencilla depende de 15, 20 o 30 componentes desarrollados por empresas y programadores diferentes.
Enhorabuena: acabas de convertir tu página corporativa en una pequeña convención internacional de PHP.
El plugin gratuito que alguien programó con toda su buena voluntad
Aquí existe además un problema que no considero justo cargar exclusivamente sobre los desarrolladores.
Durante años nos hemos acostumbrado a disponer de plugins gratuitos extraordinarios.
Un programador dedica cientos de horas a desarrollar una herramienta, la publica gratuitamente, corrige errores, responde preguntas y mantiene compatibilidad con nuevas versiones de WordPress.
Todo fantástico.
Hasta que pasan los años.
Porque el desarrollador tiene que trabajar, mantener otros proyectos, pagar facturas y posiblemente descubrir esa curiosa característica del ser humano llamada querer cobrar por su trabajo.
Entonces el plugin empieza a actualizarse menos.
Después deja de actualizarse.
Pero sigue instalado en miles de páginas web.
Y ahí tenemos el problema.
Un plugin abandonado no deja automáticamente de funcionar. Puede continuar funcionando durante años.
Lo que deja de tener es alguien detrás revisando qué ocurre cuando aparecen nuevas técnicas de ataque o se descubren errores en su código.
En la base de datos de Patchstack correspondiente a 2026, alrededor del 27 % de las vulnerabilidades publicadas que recoge actualmente aparecen como no parcheadas. Además, aproximadamente el 87 % corresponden a plugins.
Todavía resulta más preocupante otro dato: Patchstack señala que el 46 % de las vulnerabilidades analizadas en 2025 no habían recibido una corrección del desarrollador cuando llegó el momento de su divulgación pública.
Eso significa que actualizar WordPress y pulsar alegremente el botón de "Actualizar plugins" ya no resuelve necesariamente el problema.
Porque no puedes instalar una actualización que no existe.
"Pues utilizo plugins de pago"
Perfecto.
Pero pagar tampoco produce mágicamente código seguro.
Es más, el informe de Patchstack de 2026 introduce un dato especialmente incómodo: encontró 1.983 informes válidos de vulnerabilidades relacionados con componentes premium o freemium, y el 76 % de las vulnerabilidades detectadas en componentes premium eran explotables en ataques reales según su clasificación.
Por tanto, el debate gratuito contra premium es demasiado simplista.
Un plugin de pago puede proporcionar mejor mantenimiento, soporte profesional, auditorías y capacidad económica para solucionar vulnerabilidades rápidamente.
Eso es importante.
Pero premium no significa invulnerable.
La cuestión realmente importante es quién mantiene ese software, con qué frecuencia se actualiza, qué política de seguridad tiene, cómo responde ante una vulnerabilidad y cuánto tiempo tarda en publicar un parche.
Y entonces llegó la inteligencia artificial
Aquí es donde creo que el escenario ha cambiado considerablemente.
Durante años existió una especie de barrera técnica natural.
Encontrar vulnerabilidades requería conocimientos.
Había que entender PHP, JavaScript, SQL, autenticación, permisos, peticiones HTTP, APIs, WordPress, hooks, nonces y bastantes conceptos adicionales.
Ahora podemos entregar grandes cantidades de código a modelos de inteligencia artificial y utilizarlos para analizar patrones, explicar código, detectar errores potenciales y acelerar auditorías de seguridad.
Esto es fantástico para los desarrolladores y para los investigadores legítimos.
Pero exactamente la misma capacidad reduce el coste de analizar software para todo el mundo.
El código abierto siempre ha podido ser auditado, y eso también constituye una de sus grandes ventajas: más ojos pueden encontrar y corregir problemas.
El problema de 2026 es la velocidad.
Ya no hablamos exclusivamente de un investigador sentado durante tres días leyendo PHP.
Podemos automatizar parte del análisis.
Podemos comparar versiones.
Podemos localizar funciones sensibles.
Podemos estudiar cambios publicados después de un parche.
Y podemos hacerlo a una escala que hace unos años requería muchísimo más trabajo.
El propio informe de Patchstack advierte de que los atacantes pueden convertir nuevas vulnerabilidades en ataques en cuestión de horas, lo que reduce enormemente la ventana disponible para reaccionar.
La IA no ha inventado las vulnerabilidades de WordPress.
Lo que está haciendo es reducir la fricción necesaria para encontrarlas, comprenderlas y automatizar procesos alrededor de ellas.
Y eso cambia bastante las reglas del juego.
¿Un niño de 12 años puede hackear WordPress preguntándole a una IA?
Aquí conviene separar la provocación de la realidad técnica.
Decir literalmente que cualquier niño de 12 años puede comprometer cualquier WordPress con cuatro instrucciones a una IA sería exagerado.
Una instalación correctamente mantenida, protegida y configurada no cae mágicamente porque alguien escriba cuatro prompts.
Pero la idea de fondo sí debería preocuparnos.
La barrera de entrada para realizar determinadas tareas técnicas está bajando radicalmente.
Una persona ya no necesita comprender cada línea de código para empezar a entender qué está haciendo un script, interpretar un error, identificar una tecnología o automatizar determinadas comprobaciones.
La IA puede actuar como profesor técnico permanente.
Eso democratiza la programación.
También democratiza parcialmente el conocimiento sobre seguridad.
Y WordPress tiene una característica irresistible para quien busca objetivos: hay millones de instalaciones extraordinariamente parecidas entre sí.
Encuentras una vulnerabilidad seria en un componente popular y el problema deja de ser "¿cómo entro en esta web?".
La pregunta pasa a ser:
¿Cuántas webs utilizan esta misma versión vulnerable?
Ese cambio de escala es fundamental.
La popularidad de WordPress empieza a jugar en su contra
Que WordPress esté instalado en aproximadamente cuatro de cada diez webs es una demostración espectacular de éxito.
Pero desde la perspectiva de un atacante también significa otra cosa:
economía de escala.
Si dedicas recursos a investigar una tecnología utilizada por el 0,01 % de Internet, tu superficie potencial es pequeña.
Si investigas vulnerabilidades de un ecosistema presente en aproximadamente el 40 % de las webs, cualquier descubrimiento potencialmente reutilizable resulta muchísimo más interesante.
No significa que WordPress sea vulnerable simplemente por ser popular.
Significa que es rentable investigar cómo atacarlo.
Es exactamente el mismo fenómeno que históricamente hemos visto con sistemas operativos, navegadores , dispositivos y aplicaciones enormemente populares.
Donde están los usuarios, aparecen los atacantes.
El verdadero sufrimiento: mantener WordPress
Para mí, aquí está actualmente el mayor problema.
Crear una web WordPress sigue siendo relativamente sencillo.
Mantenerla durante cinco o diez años ya es otra historia.
Un proyecto profesional requiere vigilar constantemente:
-
WordPress Core.
-
La versión de PHP.
-
El servidor.
-
El tema.
-
Los plugins.
-
Las dependencias.
-
Las vulnerabilidades publicadas.
-
Las copias de seguridad.
-
Los usuarios administradores.
-
Los intentos de acceso.
-
El firewall.
-
El malware.
-
Los plugins abandonados.
-
Las incompatibilidades después de actualizar.
Y encima existe una maravillosa paradoja.
Si no actualizas, puedes quedar vulnerable.
Si actualizas, puedes romper la web.
Así que pulsas "Actualizar" mirando la pantalla como quien corta el cable rojo de una bomba.
Una web seria no debería depender de veinte desconocidos
Este es probablemente mi principal problema conceptual con WordPress en 2026.
Imaginemos una empresa cuya página web es crítica para captar clientes.
Tiene WordPress.
Un tema comprado a una empresa.
Un constructor visual de otra.
Un plugin SEO de otra.
Un sistema de formularios de otra.
Un plugin de caché de otra.
Un plugin de cookies de otra.
Cinco extensiones adicionales.
WooCommerce.
Extensiones para WooCommerce.
Y alguna pequeña maravilla instalada en 2019 porque "hacía exactamente lo que necesitábamos".
La seguridad del proyecto ya no depende únicamente de tu empresa.
Depende de toda esa cadena de proveedores.
Y basta con que falle uno.
Ese es el problema arquitectónico que considero cada vez más difícil de justificar en proyectos importantes.
No es que WordPress sea imposible de securizar.
Por supuesto que puede protegerse.
Hay instalaciones extraordinariamente bien administradas.
Existen empresas especializadas, WAF, sistemas de virtual patching, monitorización, backups externos, control de integridad, staging y políticas de actualización excelentes.
Pero fíjate en la ironía.
Necesitamos incorporar cada vez más infraestructura y servicios para proteger el CMS que elegimos originalmente porque era sencillo.
WordPress barato puede terminar siendo WordPress caro
Este es otro clásico.
"WordPress es gratis."
Sí.
También Linux.
También una enorme cantidad de tecnologías empresariales.
Que el software tenga coste de licencia cero no significa que el coste de operación sea cero.
Una instalación profesional de WordPress puede necesitar:
hosting administrado + mantenimiento + plugins premium + copias externas + seguridad + monitorización + staging + actualizaciones + intervención técnica.
Y entonces descubrimos que lo gratuito era solamente el archivo ZIP .
Para un blog personal esto puede ser perfectamente asumible.
Para una pequeña web también.
Pero cuando hablamos de una empresa cuya facturación depende de formularios, reservas, ecommerce, leads o servicios online, el cálculo debería hacerse utilizando coste total y riesgo, no preguntando únicamente cuánto cuesta instalar WordPress.
¿Significa esto que nadie debería utilizar WordPress?
No.
Y sería intelectualmente bastante pobre afirmar algo así.
WordPress sigue teniendo ventajas enormes: ecosistema gigantesco, facilidad para publicar contenido, profesionales disponibles, integraciones prácticamente para cualquier necesidad y una comunidad extraordinaria.
Hay proyectos donde continúa teniendo muchísimo sentido.
Una web editorial.
Un blog.
Una página corporativa sencilla.
Un proyecto donde exista mantenimiento profesional permanente.
Una instalación extremadamente controlada y con pocos componentes.
El problema aparece cuando confundimos:
"WordPress permite hacer prácticamente cualquier cosa"
con:
"WordPress es la arquitectura adecuada para hacer cualquier cosa".
Son afirmaciones completamente diferentes.
Para proyectos críticos, cada vez me cuesta más verlo
Si hoy tuviera que plantear una aplicación donde seguridad, estabilidad y disponibilidad fueran realmente críticas, intentaría reducir al máximo la superficie de ataque y, especialmente, el número de dependencias que pueden introducir código ejecutable en el servidor.
No quiero 35 plugins.
No quiero descubrir que una funcionalidad esencial depende de un desarrollador que dejó el proyecto hace tres años.
No quiero comprobar cada mañana si alguna extensión utilizada por mis clientes acaba de aparecer en una base de datos de vulnerabilidades.
Y tampoco quiero solucionar el problema instalando otro plugin de seguridad encima de los plugins que ya tengo.
Porque llega un momento en que parece que estamos sujetando WordPress con cinta americana mientras instalamos un plugin para comprobar si la cinta americana tiene alguna vulnerabilidad.
El gran cambio de 2026 es la velocidad
Esta es posiblemente la cuestión que más debería preocupar a administradores y empresas.
En el primer semestre de 2025 ya se habían identificado 6.700 nuevas vulnerabilidades en el ecosistema WordPress, y Patchstack estimaba que el 41 % podían explotarse en ataques reales.
El informe completo publicado en 2026 elevó la cifra de 2025 a 11.334 vulnerabilidades, con un crecimiento anual del 42 %.
No todas son críticas.
No todas afectan a nuestra web.
No todas serán explotadas.
Pero la dirección resulta difícil de ignorar.
Tenemos más investigadores, mejores herramientas, programas de recompensas, automatización, inteligencia artificial y atacantes capaces de reaccionar cada vez más rápido.
Mientras tanto, seguimos teniendo instalaciones de WordPress donde alguien pregunta:
"¿Podemos actualizar ese plugin? Es que no sabemos si se romperá la plantilla."
Ese desfase entre la velocidad del atacante y la velocidad de mantenimiento de una web tradicional es lo que realmente me preocupa.
El futuro de WordPress necesita menos dependencia, no más plugins
WordPress probablemente seguirá existiendo durante muchos años.
Con una cuota cercana al 59 % entre los CMS conocidos en agosto de 2026, hablar de su desaparición inmediata sería absurdo.
Pero supervivencia y conveniencia tecnológica no son lo mismo.
Mi duda no es si WordPress seguirá existiendo.
Mi duda es qué tipo de proyectos deberían seguir construyéndose sobre WordPress durante la próxima década.
Porque en un Internet donde descubrir y explotar errores puede automatizarse cada vez más, una arquitectura basada en combinar decenas de componentes PHP de procedencias distintas necesita replantearse seriamente.
Quizá el futuro pase por instalaciones mucho más minimalistas.
Quizá por WordPress desacoplado.
Quizá por arquitecturas donde el CMS no esté directamente expuesto.
Quizá por sistemas estáticos para determinados proyectos.
O quizá WordPress consiga transformar radicalmente la seguridad y gobernanza de su ecosistema de plugins.
Pero continuar instalando WordPress, añadir 27 plugins, configurar actualizaciones automáticas y pensar que alguien se ocupará de todo parece, en agosto de 2026, una estrategia cada vez más difícil de defender.
Sobre todo porque ahora ese "alguien" que está revisando tu plugin abandonado de 2018 podría no ser su desarrollador.
Podría ser una IA.
Y puede que no esté trabajando para ti.