Respuesta corta: un plugin es vulnerable cuando la versión que tienes instalada tiene un fallo de seguridad publicado (normalmente con un código CVE). Para saberlo, saca la lista de plugins con su versión y compárala con una base de datos de vulnerabilidades de WordPress. Si alguno está afectado, actualiza a la versión corregida; si no hay corrección, desactívalo, bórralo y busca un sustituto.
La mayoría de webs WordPress hackeadas que vemos no caen por una contraseña, sino por plugins vulnerables: un plugin sin actualizar con un fallo conocido. Esta guía forma parte de nuestra guía sobre qué hacer con un WordPress hackeado.
Qué significa que un plugin sea vulnerable
Cada plugin es código de un tercero que se ejecuta en tu servidor. Cuando alguien encuentra un fallo de seguridad, lo comunica al autor, el autor publica una versión corregida y el fallo se hace público con un identificador (CVE) y una puntuación de gravedad (CVSS, de 0 a 10). Desde ese momento, cualquiera sabe qué versiones están afectadas y cómo aprovecharlo, y los ataques automáticos empiezan a buscar webs con esa versión.
Los tipos de fallo más habituales en plugins:
- Subida de ficheros sin control: permite subir un PHP y ejecutarlo.
- Escalada de privilegios: un usuario cualquiera (o un visitante) se convierte en administrador. Lo verás como un administrador que no has creado.
- Inyección SQL: lectura o modificación de la base de datos.
- XSS: inyección de JavaScript que se ejecuta en el navegador de quien visita o administra la web.
- CSRF: engañar a un administrador conectado para que haga algo sin saberlo.
Lo más importante de un aviso es si hace falta estar identificado para aprovecharlo. Un fallo que puede explotar cualquier visitante anónimo es mucho más urgente que uno que exige ser administrador.
Un ejemplo real: Contact Form 7 anterior a la 5.3.2
Contact Form 7 es uno de los plugins más instalados de WordPress. Sus versiones anteriores a la 5.3.2 tenían el fallo CVE-2020-35489, con puntuación CVSS 10, la máxima: el plugin no limpiaba bien el nombre de los ficheros subidos por los formularios, y en algunos servidores eso permitía subir un fichero ejecutable. Se corrigió en la versión 5.3.2.
La lección no es que Contact Form 7 sea un mal plugin, sino que hasta los plugins más usados y mejor mantenidos tienen fallos. Lo que marca la diferencia es cuánto tardas en actualizar.
Cómo detectar plugins vulnerables en tu WordPress
1. Saca el inventario
wp core version
wp plugin list --fields=name,status,version,update_version
wp theme list --fields=name,status,version,update_versionApunta también los plugins de pago: si la licencia está caducada, WordPress no te avisa de sus actualizaciones y pueden llevar años sin actualizar sin que nadie lo vea.
2. Compara con una base de datos de vulnerabilidades
Las bases de datos públicas más usadas para WordPress son WPVulnerability, WPScan, Wordfence Intelligence y Patchstack. Todas te dicen, para cada plugin, qué vulnerabilidades tiene, qué versiones afectan y en cuál se corrigió. WPVulnerability tiene una API gratuita sin registro:
curl -s https://www.wpvulnerability.net/plugin/contact-form-7/ | jq .
curl -s https://www.wpvulnerability.net/theme/twentytwentyone/ | jq .
curl -s https://www.wpvulnerability.net/core/6.6.1/ | jq .En la respuesta verás cada vulnerabilidad con su rango de versiones afectadas, su CVE si lo tiene y su gravedad. Compara ese rango con tu versión. Si prefieres una herramienta, WPScan revisa la web entera, aunque necesita un token gratuito de su servicio.
3. Mira también lo que no se actualiza
Un plugin sin vulnerabilidades publicadas no es necesariamente seguro: si está abandonado o retirado de WordPress.org, nadie va a corregir el próximo fallo.
Qué hacer si tienes un plugin vulnerable
- Confirma que tu versión está afectada y mira si existe versión corregida y si el fallo exige estar identificado.
- Haz una copia de seguridad de ficheros y base de datos.
- Actualiza a la versión corregida o posterior y comprueba que la web y sus formularios siguen funcionando.
- Si no hay corrección, desactiva y borra el plugin, y busca un sustituto mantenido. Si no puedes quitarlo ya, pide a tu proveedor de cortafuegos de aplicación (WAF) una regla que bloquee ese fallo concreto mientras lo sustituyes.
- Si el fallo era explotable sin identificarse y llevaba tiempo público, da por hecho que alguien lo ha podido usar: revisa administradores, ficheros PHP recientes y contenido nuevo.
- Borra los plugins y temas que no uses. Desactivados, sus ficheros siguen en el servidor y algunos fallos se explotan llamándolos directamente.
wp db export ../antes-de-actualizar.sql
wp plugin update contact-form-7
wp plugin get contact-form-7 --field=version
wp plugin deactivate plugin-sin-parche && wp plugin delete plugin-sin-parche
wp user list --role=administrator --fields=ID,user_login,user_registered
find wp-content/uploads -name "*.php"Si encuentras indicios de intrusión, sigue la guía de limpieza completa. Actualizar cierra la puerta, pero no echa a quien ya entró.
Errores habituales
- Pensar que un plugin desactivado no es un riesgo. Sus ficheros siguen accesibles. Si no lo usas, bórralo.
- Fiarte de que WordPress no avisa de actualizaciones. Con plugins de pago sin licencia, o descargados fuera de WordPress.org, no avisa.
- Olvidarte del tema y del núcleo. También tienen vulnerabilidades, y el tema suele ser el que menos se actualiza.
- Actualizar sin copia. Una actualización puede romper algo; con la copia lo arreglas en minutos.
- Ignorar los fallos de gravedad media. Combinados con otro problema (un usuario con contraseña débil, por ejemplo) pueden dar acceso completo.
Cómo evitar que vuelva
- Revisa las vulnerabilidades al menos una vez por semana, o vigílalas.
- Activa las actualizaciones automáticas en los plugins que lo permitan y no sean críticos para el negocio:
wp plugin auto-updates enable nombre-del-plugin. En los críticos (tienda, pagos, formularios), mejor actualizar a mano con copia y comprobación, pero rápido. - Mantén pocos plugins y todos con autor activo: cuantos menos tengas, menos plugins vulnerables tendrás que vigilar. La guía oficial de seguridad de WordPress (Hardening WordPress) recomienda lo mismo: plugins al día y fuera los que no uses.
- Renueva las licencias de los plugins de pago o sustitúyelos.
Para agencias: saber qué web tiene qué plugin vulnerable
En una cartera de webs, el problema no es actualizar, es saber qué hay que actualizar y dónde. Con el plugin de Jeffrey instalado, cada web envía su inventario de núcleo, plugins y temas (con versión y si están activos) cada 12 horas y cada vez que se activa, desactiva o actualiza algo.
Una vez al día, Jeffrey cruza ese inventario con la base de datos de WPVulnerability y abre un aviso por cada componente afectado:
- Crítico, con aviso inmediato, si el plugin está activo y la vulnerabilidad tiene una puntuación CVSS de 7 o más.
- Aviso si la puntuación es menor o el plugin está desactivado (sigue siendo un riesgo, pero menos urgente).
En el panel ves cada vulnerabilidad clasificada como crítica (9 o más), alta (7 o más), media o baja, y la versión en la que se corrigió. Cuando actualizas, el aviso se cierra solo. Una web con Contact Form 7 5.3.1 activo, por ejemplo, es exactamente el tipo de caso que Jeffrey marca como crítico.
Jeffrey no analiza los ficheros del servidor en busca de malware: te dice qué puertas están abiertas para que las cierres antes de que alguien las use.
Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.
Preguntas frecuentes
Si el plugin está desactivado, ¿estoy a salvo?
No del todo. El código sigue en el servidor y algunos fallos se pueden aprovechar llamando directamente a sus ficheros. El riesgo es menor que con el plugin activo, pero la solución es borrarlo si no lo usas.
¿Qué es el CVSS y a partir de qué número me tengo que preocupar?
Es una puntuación de 0 a 10 que resume la gravedad de un fallo. A partir de 7 se considera alta y a partir de 9, crítica. Pero mira también si hace falta estar identificado: un 6 que puede explotar cualquiera puede ser más urgente que un 8 que exige ser administrador.
¿Activo las actualizaciones automáticas para todo?
Es mejor que no actualizar, pero tiene un coste: alguna vez una actualización romperá algo sin que estés delante. Lo razonable es automático en plugins sencillos y manual, pero rápido y con copia, en los críticos para el negocio.
No hay actualización para el plugin vulnerable. ¿Qué hago?
Si el autor no publica corrección, desactívalo y bórralo, y busca un sustituto. Mientras tanto, una regla de cortafuegos que bloquee ese fallo concreto reduce el riesgo, pero no es una solución definitiva.