Cómo proteger tu WordPress de plugins abandonados y vulnerabilidades

El plugin que instalaste hace tres años para un proyecto concreto y que nadie ha vuelto a tocar puede ser la causa del hackeo de tu web. Los plugins abandonados, aquellos que ya no reciben actualizaciones de su desarrollador, acumulan vulnerabilidades conocidas que los atacantes explotan de forma completamente automatizada. No necesitan apuntar a tu web específicamente: escanean millones de instalaciones de WordPress buscando versiones vulnerables de plugins específicos. Si la tienes, entran. Si no la tienes, pasan al siguiente. Es un proceso industrial, no un ataque dirigido, y eso lo hace más peligroso para las webs pequeñas que asumen que nadie se va a molestar en atacarlas.

1. Cómo identificar plugins en riesgo: las señales concretas

Un plugin se considera abandonado cuando su último lanzamiento lleva más de 12 meses sin actualizarse y el desarrollador no ha indicado que lo mantendrá activamente. Pero hay señales más urgentes que el tiempo:

• Sin actualizar en más de 1 año: señal de alerta. No es automáticamente inseguro, pero requiere evaluación activa. Revisa si hay vulnerabilidades conocidas con ese plugin y versión en particular.
• No probado con las dos últimas versiones de WordPress: indica que el desarrollador no está haciendo seguimiento activo de la compatibilidad. Puede funcionar, pero no hay garantía de que el código sea compatible con los cambios de seguridad del core.
• Eliminado del repositorio oficial de WordPress.org: esta es la señal más urgente. Si un plugin desaparece del repositorio oficial, normalmente es porque el equipo de WordPress encontró un problema de seguridad grave. Hay que eliminarlo de forma inmediata, no desactivarlo: eliminarlo.
• Vulnerabilidades conocidas en WPScan o CVE: herramientas como la base de datos de Wordfence o WPScan muestran qué plugins tienen vulnerabilidades conocidas sin parchear. Si tu plugin está en esa lista, es una emergencia.
• Sin actividad en los foros de soporte: si hay preguntas sin responder del desarrollador en los últimos 6 meses, el plugin está efectivamente abandonado aunque no lo diga explícitamente.

Una empresa de servicios de consultoría de Madrid con una web WordPress corporativa sufrió un hackeo en febrero de 2025 a través de un plugin de formularios de contacto abandonado. El plugin tenía una vulnerabilidad de carga de ficheros sin autenticación publicada en CVE hacía 4 meses. Los atacantes inyectaron un web shell en el servidor y lo usaron para enviar spam durante semanas antes de que el proveedor de hosting bloqueara la cuenta. El coste de limpieza y restauración superó los 2.000 euros, más el tiempo sin web y el daño reputacional con los buscadores por el spam enviado.

2. Evaluación del riesgo real: no todos los plugins sin actualizar son igual de peligrosos

Antes de entrar en pánico con cada plugin que lleva unos meses sin actualización, conviene entender que el riesgo real depende de qué hace el plugin y con qué partes de WordPress interactúa.

Un plugin que solo añade un shortcode de texto plano, genera un botón de color o muestra un contador en el sidebar, sin interacción con formularios, la base de datos ni APIs externas, tiene una superficie de ataque mínima. Si lleva un año sin actualizar y no hay vulnerabilidades conocidas, el riesgo es bajo aunque no sea cero.

Un plugin que procesa formularios de contacto, permite carga de archivos, gestiona usuarios, hace peticiones a APIs externas o maneja datos de pago tiene una superficie de ataque mucho mayor. Si ese plugin lleva más de 6 meses sin actualización y el desarrollador no responde en los foros, la sustitución es prioritaria independientemente de si hay una vulnerabilidad conocida o no. El riesgo potencial justifica la acción preventiva.

Para WordPress y WooCommerce, las categorías de mayor riesgo son: plugins de formularios con carga de ficheros, plugins de comercio con integración de pasarelas de pago, plugins de gestión de usuarios y roles, plugins con acceso a la API REST sin restricciones de autenticación.

3. Proceso de sustitución sin romper la web

La sustitución de un plugin que lleva años activo y tiene contenido o configuración dependiente de él es una operación que requiere cuidado. El proceso correcto:

• Backup completo antes de cualquier cambio: base de datos y todos los ficheros. Si algo sale mal durante la sustitución, necesitas poder volver al estado anterior en minutos. Un backup que no se ha verificado recientemente no es un backup.
• Entorno de staging para probar: una copia de la web en un subdominio (staging.tudominio.com) o en local (LocalWP, Vagrant) donde puedes verificar que el plugin sustituto funciona correctamente antes de tocar producción.
• Identificar dependencias del plugin antes de sustituirlo: shortcodes que usa el plugin en páginas y entradas, configuraciones almacenadas en la base de datos (wp_options), ficheros que crea en /uploads/, cualquier modificación en functions.php o themes que llame al plugin.
• Desactivar antes de eliminar: desactiva el plugin y verifica que la web sigue siendo funcional (o que los elementos que deja de funcionar son los esperados) antes de borrarlo del servidor.
• Eliminar completamente después de desactivar: no basta con desactivarlo. Los ficheros del plugin eliminado del servidor no pueden ser explotados aunque hubiera una vulnerabilidad en el código.

4. Limpieza de contenido legado: el trabajo que nadie anticipa

Cuando un plugin lleva años activo y se elimina, deja rastros en la base de datos y en los ficheros que hay que limpiar. Si no se limpian, pueden generar errores en el frontend, aparecer como shortcodes sin procesar ([old_plugin_shortcode]) en el contenido de las páginas, o en algunos casos mantener tablas en la base de datos que ya no sirven pero ocupan espacio.

La limpieza de base de datos requiere acceso a phpMyAdmin o al CLI de MySQL. Las tablas creadas por el plugin antiguo suelen tener el prefijo del plugin en el nombre (wp_formsdata_, wp_gravity_forms_, etc.) y pueden eliminarse una vez verificado que el plugin sustituto ha migrado o que los datos ya no son necesarios.

Para los shortcodes que aparecen en el contenido de páginas y entradas, un buscar y reemplazar en la base de datos permite eliminarlos o sustituirlos por los del nuevo plugin. Herramientas como Better Search Replace permiten hacer esto desde el panel de WordPress sin acceso directo a la base de datos.

5. Mapa de dependencias: el inventario que acelera las decisiones futuras

Documenta qué plugins tienes, para qué sirven, si tienen alternativas conocidas y cuál es el estado de mantenimiento del desarrollador. Este documento sirve para dos cosas concretas: saber rápidamente cuáles son prescindibles (puedes eliminarlos sin buscar alternativa) y tener criterio para decidir cuándo un plugin que deja de mantenerse requiere sustitución urgente versus puede esperar.

La regla práctica: si un plugin crítico (formularios, comercio, usuarios) lleva más de 18 meses sin actualización y no hay respuesta del desarrollador en los foros de soporte, planifica la sustitución aunque no haya una vulnerabilidad conocida todavía. Las vulnerabilidades en plugins abandonados se descubren con frecuencia por investigadores que las publican públicamente, dando a los atacantes un vector documentado que el desarrollador ya no puede parchear.

El servicio de mantenimiento WordPress de NetGoos incluye la revisión mensual del estado de todos los plugins instalados con alerta automática cuando alguno tiene una vulnerabilidad conocida o cuando aparece en las bases de datos de riesgo. El mapa de dependencias se actualiza como parte del servicio.

6. Herramientas para monitorizar el estado de plugins en producción

No basta con hacer una revisión puntual: el estado de seguridad de los plugins cambia cuando se descubre una nueva vulnerabilidad. Herramientas que monitoricen esto de forma continua:

• Wordfence (Free o Premium): escanea la instalación y alerta cuando un plugin tiene una vulnerabilidad conocida. La versión Free tiene un retraso de 30 días en las actualizaciones de la base de datos de amenazas; la Premium es en tiempo real.
• WPScan CLI: herramienta de línea de comandos que escanea una instalación WordPress contra la base de datos de vulnerabilidades de WPScan. Útil para auditorías puntuales o integración en pipelines CI/CD.
• Patchstack: servicio de monitorización de vulnerabilidades en WordPress con alertas por correo cuando algún plugin o tema instalado tiene una vulnerabilidad nueva. Tiene plan gratuito para un sitio.

Consulta también nuestro artículo sobre cómo proteger el panel de WordPress contra bots para ver cómo las capas de protección del panel complementan la gestión de plugins seguros.

Comparativa: plugins activos vs abandonados por categoría de riesgo

Por dónde empezar mañana

1. Accede al panel de WordPress y ve a Plugins > Plugins instalados. Ordena por "Última actualización" (si ves la columna) o busca los que tienen aviso de no compatibilidad con la versión actual de WordPress.
2. Busca cada plugin en la base de datos de Wordfence (wordfence.com/threat-intel) o en WPScan (wpscan.com/plugins) para verificar si tiene vulnerabilidades conocidas. Empieza por los plugins de formularios, ecommerce y gestión de usuarios.
3. Elimina los plugins que no uses, aunque estén desactivados. Los ficheros en el servidor siguen siendo un riesgo aunque el plugin esté desactivado.
4. Para los plugins con vulnerabilidad conocida, busca la versión parcheada e instálala. Si no hay versión parcheada porque el plugin está abandonado, desactívalo inmediatamente y planifica la sustitución en los próximos días.

Si necesitas una revisión completa del estado de seguridad de tu WordPress, incluyendo el análisis de todos los plugins instalados con sus vulnerabilidades conocidas y un plan de acción priorizado, la auditoría informática lo cubre con un informe de riesgos y un calendario de actuación.

Preguntas frecuentes