Las vulnerabilidades en plugins de WordPress ya no son un riesgo técnico marginal: concentran el 91% de todos los fallos de seguridad descubiertos en el gestor de contenidos durante 2025, según el informe State of WordPress Security in 2026 de Patchstack. Para un equipo de marketing que gestiona su propia web, o para el responsable técnico que la mantiene, esto cambia la pregunta de fondo: ya no es si el sitio corre WordPress, sino qué plugins tiene instalados, quién los revisa y con qué frecuencia. Este artículo repasa qué dice el dato, por qué ocurre y qué proceso reduce de verdad la exposición.
Vulnerabilidades en plugins de WordPress: qué mide el informe
Patchstack registró 11.334 vulnerabilidades nuevas en el ecosistema WordPress durante 2025, un 42% más que el año anterior. De ese total, el 91% apareció en plugins y el 9% en temas; el núcleo de WordPress, mantenido por un equipo central con revisión de código estricta, sumó solo seis. El desglose por gravedad tampoco es tranquilizador: 1.966 vulnerabilidades, el 17% del total, se clasificaron como de severidad alta, con un crecimiento del 113% respecto a 2024.
El mensaje del informe es claro para quien decide sobre una web corporativa, no solo para quien la programa: el riesgo no está en el software base de WordPress, sino en la cadena de componentes de terceros que se instalan encima para añadir funciones como formularios, tiendas o constructores visuales. Cuantos más plugins activos, mayor la superficie expuesta, con independencia del tamaño de la empresa que hay detrás.
Por qué los plugins concentran el riesgo
Un plugin lo escribe un desarrollador o un equipo pequeño, sin la revisión centralizada que aplica el núcleo de WordPress antes de publicar una versión. El resultado es una calidad de código muy desigual: unos pasan controles de seguridad serios y otros no pasan ninguno. Muchos de esos fallos son graves por diseño, no por casualidad: el 43% de las vulnerabilidades detectadas en 2025 eran explotables sin autenticación, es decir, un atacante no necesita ni una cuenta de usuario para aprovecharlas, solo encontrar la URL correcta.
Componentes premium, más expuestos
Los plugins de pago o freemium no salen mejor parados. Representaron el 29% de los informes de vulnerabilidad válidos en 2025, y el 59% de esos casos se clasificaron como de prioridad alta por su potencial para ataques masivos automatizados. Patchstack añade un dato incómodo para quien paga una licencia pensando que eso implica más seguridad: el 76% de las vulnerabilidades en componentes premium se explotaron en ataques reales, y estos componentes acumulan el triple de vulnerabilidades explotadas conocidas (KEV) que los gratuitos. Al distribuirse fuera del repositorio oficial de WordPress.org, dependen de servidores de licencias propios y de sistemas de actualización que no siempre siguen el mismo estándar de revisión.
El parche que no llega a tiempo
El 46% de las vulnerabilidades de 2025 no tenía parche disponible en el momento de hacerse pública. Eso significa que, cuando la información sale, el sitio ya está expuesto y no hay una actualización que instalar para cerrar el agujero de inmediato. La ventana entre el aviso y el ataque además es corta: en las vulnerabilidades más buscadas por los atacantes, la explotación masiva arranca en apenas 5 horas, y en torno a la mitad de los fallos de impacto alto se explotan en las primeras 24 horas tras conocerse.
Ventana de exposición de 30 días
Un mes después de publicarse, el 23% de las vulnerabilidades seguía sin parche. En ese margen no hace falta que un atacante concreto se fije en la web del cliente: existen bots que rastrean internet de forma automática buscando instalaciones de un plugin con una versión conocida como vulnerable, sin distinguir el tamaño del negocio detrás. Una tienda online pequeña con un formulario de contacto mal protegido entra en el mismo barrido que una web corporativa grande, porque el bot no elige objetivo, elige huella técnica: una cadena de versión concreta en el código fuente de la página.
Una vulnerabilidad crítica es aquella con una puntuación CVSS de 9 o más sobre 10: permite comprometer el sitio sin necesidad de credenciales ni de que la víctima haga nada, solo que el atacante encuentre la URL vulnerable.
Qué le cuesta a una empresa un plugin vulnerable
El daño técnico inmediato —inyección de código, robo de credenciales de administrador, acceso a la base de datos con los formularios de leads o de clientes— es solo la primera factura. Detrás viene el tiempo de limpieza, que en un sitio comprometido no se limita a actualizar el plugin: hay que revisar archivos, cambiar contraseñas y credenciales, y comprobar que no ha quedado una puerta trasera oculta en el código, algo que un plugin instalado sin control de versiones puede tardar días en confirmar.
El golpe reputacional además del técnico
Cuando Google detecta contenido malicioso o redirecciones no autorizadas en un sitio, lo marca en sus resultados de búsqueda como sitio que «puede estar hackeado» y puede añadirlo a su lista de páginas no seguras, con el consiguiente aviso en el navegador a cualquier visitante. Recuperar la posición perdida en ese periodo, una vez limpiado el sitio y solicitada la revisión, se cuenta en semanas, no en horas. Para una empresa que invierte en marketing de contenidos y en posicionamiento, un backend sin mantenimiento activo puede borrar en un fin de semana lo que ha costado meses construir.
Auditoría de plugins antes de cada actualización
Reducir la exposición no exige dejar de usar plugins, exige gestionarlos con el mismo criterio con el que se audita cualquier otro proveedor externo. Antes de instalar uno nuevo, o de mantener uno antiguo en producción, conviene comprobar de forma sistemática:
- Fecha de la última actualización y número de instalaciones activas en el repositorio de WordPress.org, como indicador de mantenimiento real por parte del desarrollador.
- Historial de vulnerabilidades del plugin y de su autor, para saber si corrige fallos con rapidez o los deja acumularse.
- Si el plugin sigue siendo necesario: cada componente activo, se use o no, suma superficie de ataque al sitio.
- Actualizaciones probadas primero en un entorno de pruebas, nunca directamente en producción, para no romper la web con un cambio de versión mayor.
Este trabajo es exactamente el que cubre una auditoría de mantenimiento de WordPress: no consiste en aplicar actualizaciones sin mirar, sino en decidir cuáles aplicar ya, cuáles probar antes y qué plugins conviene eliminar del todo.
Mantenimiento web frente a instalar y olvidar
Buena parte de las webs corporativas se lanzan con un proyecto de desarrollo cerrado y sin contrato de mantenimiento posterior: el plugin se instala, cumple su función el día del lanzamiento y nadie vuelve a revisarlo salvo que algo falle de forma visible. Con datos como el 46% de vulnerabilidades sin parche al publicarse y una ventana de explotación de horas, ese modelo deja el sitio expuesto la mayor parte de su vida útil. El mantenimiento continuo —monitorización de vulnerabilidades conocidas, pruebas en entorno de staging, aplicación de parches en días y no en meses, copia de seguridad antes de cada cambio— no es un gasto añadido al desarrollo: es la parte del proyecto que sigue existiendo después de la entrega.
Presupuestar una web solo por lo que cuesta construirla, dejando fuera el sostenimiento a partir del segundo mes, es la decisión que después convierte una vulnerabilidad conocida en un incidente real. Un desarrollo a medida bien planteado deja escrito desde el principio quién revisa el código de terceros y con qué periodicidad, del mismo modo que una auditoría de seguridad informática revisa el resto de la infraestructura técnica de la empresa.
Preguntas frecuentes sobre vulnerabilidades en plugins de WordPress
¿Cuántos plugins de WordPress tienen vulnerabilidades conocidas?
En 2025 se registraron 11.334 vulnerabilidades nuevas en todo el ecosistema WordPress, el 91% en plugins, según Patchstack. No hay una cifra fija de plugins vulnerables porque cambia cada semana: el informe habla de más de 250 vulnerabilidades nuevas de media por semana al cierre del año.
¿Cómo sé si un plugin instalado es vulnerable?
Se comprueba cruzando el nombre y la versión instalada con bases de datos públicas de vulnerabilidades, como las que publican Patchstack o WPScan, y viendo si el desarrollador ya ha liberado una versión corregida. Un análisis de seguridad periódico automatiza esa comprobación en lugar de revisar cada plugin a mano.
¿Basta con activar las actualizaciones automáticas?
Ayuda, pero no resuelve el 46% de los casos en los que no existe parche en el momento de la divulgación. Las actualizaciones automáticas cierran el hueco cuando el desarrollador ya ha publicado la corrección; hasta entonces hace falta una medida adicional, como un firewall de aplicación web o desactivar la función afectada.
¿Qué diferencia hay entre un plugin gratuito y uno premium en seguridad?
Ninguna a favor del premium: el 76% de las vulnerabilidades en componentes de pago se explotaron en ataques reales y estos acumulan el triple de vulnerabilidades explotadas conocidas que los gratuitos. Pagar por una licencia no sustituye la auditoría ni garantiza un desarrollo más cuidado.