Plugins vulnerables en WordPress: auditar, actualizar, sustituir

El punto débil de una web con WordPress rara vez es el propio WordPress. Gestionar las vulnerabilidades de los plugins de WordPress se reduce a cuatro hábitos: saber exactamente qué hay instalado, actualizar rápido, borrar lo que no necesita y sustituir lo que ya nadie mantiene.

Esta guía explica cómo adquirir cada hábito, cómo reconocer un plugin abandonado y qué hacer en el caso incómodo de que una vulnerabilidad sea pública pero todavía no exista un parche. Es uno de los puntos de nuestra lista de comprobación de seguridad para WordPress y, en la mayoría de los sitios, el que más pesa.

Qué dicen las cifras sobre las vulnerabilidades de plugins de WordPress

Las cifras anuales detalladas proceden del informe de Patchstack State of WordPress Security in 2026, que analiza 2025. Patchstack es una empresa de seguridad que vende protección frente a estos riesgos, así que conviene leerlo como una fuente bien informada, no como una estadística oficial. Sus conclusiones principales:

• 11.334 vulnerabilidades nuevas en el ecosistema WordPress en 2025, un 42 % más que en 2024.
• El 91 % estaba en plugins y el 9 % en temas. El núcleo de WordPress tuvo seis, todas de prioridad baja.
• El 17 % (1.966) era de gravedad alta y susceptible de usarse en ataques masivos automatizados.
• El 46 % no tenía parche del desarrollador en el momento de su divulgación pública.
• El control de acceso defectuoso (broken access control) fue la categoría más explotada.

Dicho de otro modo: su lista de plugins es su superficie de ataque. Cada plugin es código de otro equipo al que usted confía su web y los datos que contiene.

Por qué importa la velocidad de actualización

Los atacantes no eligen las webs una a una. Rastrean internet en busca de una versión vulnerable de un plugin y explotan automáticamente cada coincidencia. Según el mismo informe, la mediana ponderada del tiempo hasta la explotación masiva de las vulnerabilidades más explotadas fue de cinco horas, y alrededor de la mitad de las vulnerabilidades de alto impacto se explotaron en menos de 24 horas.

Una ventana de mantenimiento mensual es demasiado lenta para estos casos. Las actualizaciones de seguridad necesitan una vía más rápida que las de nuevas funciones. Aplicar los parches a tiempo forma parte, además, de las medidas de seguridad «apropiadas» que exige el artículo 32 del RGPD, y la Directiva NIS2 incluye la gestión de vulnerabilidades entre sus medidas mínimas (art. 21, apartado 2, letra e) para las organizaciones sujetas a ella.

Paso 1: Mantenga un inventario de plugins

No se puede actualizar ni evaluar lo que no se conoce. Un inventario sencillo por sitio, aunque sea una hoja de cálculo, debería recoger:

• nombre del plugin, slug y versión instalada
• origen: WordPress.org, un proveedor comercial o código a medida
• por qué está instalado y quién lo pidió
• estado de la licencia y fecha de renovación de los plugins premium
• si tiene activadas las actualizaciones automáticas

Con WP-CLI puede exportar casi todo esto con un solo comando:

wp plugin list --fields=name,status,version,update_version,auto_update

Las versiones recientes de WP-CLI muestran también lo que WordPress.org sabe de cada plugin, por ejemplo si se ha cerrado:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

Los plugins que no están alojados en WordPress.org suelen aparecer aquí con valores vacíos, así que consúltelos con su proveedor. Haga lo mismo con los temas mediante wp theme list.

Paso 2: Borre los plugins que no use

Desactivar un plugin hace que WordPress deje de cargarlo, pero sus archivos siguen en el servidor. Algunas vulnerabilidades se pueden explotar solicitando directamente los archivos de un plugin, y los plugins inactivos suelen quedarse fuera de las rutinas de actualización. La propia pantalla de salud del sitio de WordPress (Herramientas → Salud del sitio) lo advierte: los plugins inactivos son un objetivo tentador para los atacantes.

Cuando ya no necesite un plugin, haga una copia de seguridad y, después, desactívelo y bórrelo en la pantalla Plugins. Desde la línea de comandos:

wp plugin uninstall old-slider --deactivate

wp plugin uninstall ejecuta la rutina de desinstalación del propio plugin, que puede borrar también sus ajustes y datos de la base de datos, y después elimina los archivos. wp plugin delete solo elimina los archivos. Exporte antes lo que todavía necesite.

Candidatos habituales: plugins de prueba que quedaron de un proyecto, funciones duplicadas (dos plugins de caché o de SEO), herramientas de migración de un solo uso y plugins cuya tarea ya cubre el núcleo de WordPress.

Paso 3: Sustituya los plugins abandonados y los «nulled»

Un plugin sin nadie que lo mantenga no recibirá un parche cuando se descubra la próxima vulnerabilidad.

Señales de que un plugin está abandonado

• Sin actualizaciones recientes. Fíjese en la fecha de «Última actualización» de la página del plugin en WordPress.org. WordPress.org también muestra un aviso cuando un plugin no se ha probado con las 3 últimas versiones mayores de WordPress.
• Cerrado en WordPress.org. Un aviso en rojo indica que el plugin se ha cerrado y ya no está disponible para su descarga. Pasados 60 días se añade el motivo, y «Security Issue» (problema de seguridad) es uno de los posibles. Sea cual sea el motivo, mientras un plugin esté cerrado no le llegará ninguna actualización a través de WordPress.org.
• Hilos de soporte sin respuesta, sobre todo los que mencionan problemas de seguridad.
• Plugins premium cuyo proveedor ya no da señales de vida: el registro de cambios no se mueve, las renovaciones de licencia fallan y el soporte no contesta.

La documentación sobre alertas y avisos de WordPress.org explica estos mensajes. Cuando los vea, planifique la sustitución antes de que una emergencia le obligue a hacerlo.

No use nunca plugins «nulled»

Los plugins «nulled» son copias pirateadas de plugins premium a las que se ha quitado la comprobación de licencia. Un tercero desconocido ha modificado el código, y nadie puede saber qué más ha cambiado. Las puertas traseras ocultas son un problema bien conocido de estas copias. Además, nunca reciben actualizaciones ni soporte, así que no podrá parchearlas cuando aparezca la próxima vulnerabilidad.

Si encuentra uno en un sitio, sustitúyalo por una copia con licencia y trate el sitio como posiblemente comprometido.

Paso 4: Actualice rápido, con actualizaciones automáticas o staging

Desde WordPress 5.5 puede activar las actualizaciones automáticas plugin por plugin en la columna «Actualizaciones automáticas» de la pantalla Plugins. Por defecto, WordPress las ejecuta dos veces al día y le envía los resultados por correo electrónico (documentación de WordPress.org). Con WP-CLI: wp plugin auto-updates enable --all.

Dada la rapidez con la que llegan los ataques, las actualizaciones automáticas son la opción por defecto adecuada para la mayoría de los plugins. El staging sigue teniendo sentido allí donde una actualización fallida cuesta dinero de verdad:

Elija lo que elija, mantenga copias de seguridad que haya restaurado al menos una vez y asegúrese de que alguien lee los correos de actualización.

Paso 5: Siga las vulnerabilidades y actúe

Dónde consultar las vulnerabilidades de plugins

• El registro de cambios (changelog) en la página del plugin en WordPress.org o en la web del proveedor. Busque entradas como «security fix», pero cuente con que algunos proveedores describen los parches de forma vaga.
• Bases de datos públicas de vulnerabilidades, como las de WPScan y Patchstack, en las que puede buscar por nombre de plugin. Ambas pertenecen a empresas que también venden servicios de seguridad.
• Avisos y boletines de los proveedores de plugins premium.

Revisar a mano decenas de plugins no es viable. Security Audit & Compliance, el plugin de auditoría de secaudit.eu, señala de serie los plugins, temas y núcleo desactualizados. Si activa la comprobación de vulnerabilidades, también compara las versiones instaladas con la base de datos de vulnerabilidades gratuita de secaudit.eu, que se genera cada noche a partir de la lista oficial de CVE; su lista de plugins nunca sale de su sitio.

Qué hacer cuando aún no hay parche

Casi la mitad de las vulnerabilidades (46 %) no tenían parche cuando se hicieron públicas. Si una afecta a un plugin que usted utiliza:

1. Evalúe su exposición. ¿Pueden los visitantes anónimos llegar a la función vulnerable, o solo los administradores con la sesión iniciada?
2. Desactive el plugin si puede prescindir de él durante un tiempo, y bórrelo si el parche no llega.
3. Sustitúyalo por una alternativa mantenida si el proveedor no da explicaciones.
4. Recurra al parcheo virtual si el plugin es imprescindible: algunos cortafuegos de aplicaciones web (WAF) y servicios de seguridad ofrecen reglas que bloquean las peticiones que coinciden con el exploit conocido. Así gana tiempo, pero el código sigue sin corregir.
5. Compruebe si ha habido una intrusión, sobre todo si el fallo llevaba tiempo siendo público antes de que usted se diera cuenta. Nuestra lista de señales de que un WordPress ha sido hackeado es un buen punto de partida.

Si vende plugins: el Reglamento de Ciberresiliencia

Para los proveedores, la gestión de vulnerabilidades se está convirtiendo en una obligación legal, y una parte ya es aplicable. Un plugin o tema de pago vendido a clientes de la UE es un «producto con elementos digitales» según el Reglamento de Ciberresiliencia (CRA), y quien lo vende es el fabricante. Desde el 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades aprovechadas activamente en sus productos a través de la plataforma única de notificación de ENISA: una alerta temprana en 24 horas, una notificación en 72 horas y un informe final en un plazo de 14 días desde que se disponga de una medida correctora.

A partir del 11 de diciembre de 2027 llegan las obligaciones principales, entre ellas las actualizaciones de seguridad durante el periodo de soporte, un proceso de gestión de vulnerabilidades, una política de divulgación coordinada y una lista de materiales de software (SBOM). Los plugins de código abierto gratuitos y no monetizados quedan, por lo general, fuera de este régimen de fabricantes. Encontrará los detalles en nuestra guía del Reglamento de Ciberresiliencia para vendedores de plugins.

Preguntas frecuentes

¿Es seguro un plugin desactivado?

No. Sus archivos siguen en el servidor y pueden contener código explotable. Borre los plugins que no use.

¿Debo activar las actualizaciones automáticas en todos los plugins?

En la mayoría, sí, junto con copias de seguridad fiables. Pruebe antes en staging los plugins críticos para el negocio, pero procure que ese retraso sea breve.

¿Y si un plugin del que dependo se ha cerrado en WordPress.org?

Trátelo como un plugin sin mantenimiento hasta que se reabra con una versión corregida, y empiece ya a buscar una alternativa.

Este artículo es información general, no asesoramiento jurídico.