Plugins WordPress vulnerables: cómo saber si te afectan

Has leído que un plugin que tienes instalado tiene un fallo de seguridad, o te ha saltado un aviso en el escritorio de WordPress, y ahora no sabes si tu web está en peligro real o si puedes dejarlo para la semana que viene. Esa es la pregunta que resuelve esta guía: cómo saber qué plugins tienes de verdad, cómo comprobar si alguno tiene un fallo publicado, cómo distinguir el que hay que parchear hoy del que puede esperar, y qué hacer en los casos incómodos en los que sencillamente no puedes actualizar.

No hace falta que seas técnico. La mayor parte del trabajo son diez minutos de inventario y una rutina mensual de media hora. Lo que no vamos a hacer es asustarte con cifras: te doy los criterios para que decidas tú.

Por qué casi todas las webs de WordPress se hackean por un plugin, no por WordPress

La respuesta no es que WordPress sea inseguro. Es una cuestión de estructura, y entenderla te ahorra mucho ruido:

El núcleo se actualiza solo. Las versiones menores de WordPress se instalan automáticamente, así que cuando aparece un fallo en el núcleo la mayoría de las webs ya están parcheadas antes de que la noticia circule.
Los plugins no. Salvo que lo hayas activado a mano, sus actualizaciones esperan a que alguien entre al panel y pulse el botón. En una web de empresa, eso pueden ser meses.
Cualquiera puede publicar un plugin. El repositorio revisa el código con criterios básicos, pero no hay auditoría de seguridad obligatoria en cada versión, y muchísimos plugins de pago ni pasan por ahí.
Un plugin corre con todos los permisos. No hay caja de arena: puede leer y escribir archivos, tocar la base de datos y crear administradores. Un fallo pequeño da el control de toda la web.
Los ataques son automáticos y masivos. Nadie ha elegido tu web: un programa busca quién tiene esa versión, y el rastreo empieza a las pocas horas del aviso. Por eso importa tanto lo que tardes en parchear.

La consecuencia práctica: la seguridad de tu WordPress se decide sobre todo en la lista de plugins, no en el núcleo.

Qué es exactamente una vulnerabilidad de plugin, y qué no lo es

Una vulnerabilidad es un fallo en el código que permite a alguien hacer algo que no debería poder hacer: subir un archivo sin ser administrador, leer datos de otros usuarios, ejecutar comandos en el servidor o darse permisos que no le corresponden. Se descubre, se comunica al autor, el autor publica una versión corregida y entonces se hace público el aviso.

Lo que no es una vulnerabilidad, aunque te lo vendan como tal:

Que un plugin esté desactualizado. Es un indicio, no un fallo: hay plugins con dos años sin tocar que no tienen ningún problema conocido.
Que el escáner de tu hosting «detecte» un plugin. Muchos avisos genéricos son detección de versión, no de explotación.
Que un plugin tenga una función potente. Un gestor de archivos no es un fallo: es una herramienta peligrosa usada correctamente. Otra cosa es que convenga tenerla, y ahí está el caso más claro en por qué WP File Manager es el plugin que más webs ha tumbado.
Un correo diciendo que tu web tiene 47 problemas críticos. Suele ser publicidad de alguien vendiendo una auditoría.

Vulnerabilidad, exploit y web comprometida: tres cosas distintas

Confundirlas es lo que provoca pánico innecesario o, al revés, tranquilidad injustificada:

Vulnerabilidad: existe un fallo en esa versión del plugin. Tu web es susceptible, pero no le ha pasado nada.
Exploit: existe además código público que aprovecha ese fallo, y hay campañas automáticas usándolo. Aquí el riesgo sube mucho, porque tu web está siendo probada, quieras o no.
Comprometida: alguien ya entró y dejó algo dentro. Esto ya no se arregla actualizando: actualizar cierra la puerta, pero no echa a quien está en el salón.

Retén esa última frase. Actualizar un plugin vulnerable no limpia una web que ya ha sido comprometida. Es el error más repetido: se actualiza, se respira tranquilo y a las dos semanas vuelve todo.

Los tipos de fallo que de verdad afectan a una pyme

De toda la taxonomía técnica, en la práctica te van a afectar cuatro familias. Las explico por lo que permiten hacer, que es lo que te interesa:

Subida de archivos sin restricción

El fallo permite subir un archivo PHP al servidor sin ser nadie. Es el peor de todos porque acaba en control total: el atacante sube una puerta trasera a wp-content/uploads y a partir de ahí hace lo que quiera. Si un aviso menciona arbitrary file upload o remote code execution, eso se parchea hoy. Cómo se detecta un archivo así entre tus subidas lo detallamos en plugins que suben archivos: dónde se esconden las puertas traseras.

Escalada de privilegios

Permite que un usuario con pocos permisos (o incluso alguien sin registrar) se convierta en administrador, o crear un administrador nuevo directamente. Es la vía por la que aparecen esas cuentas raras en tu lista de usuarios. Igual de urgente que la anterior.

Inyección SQL

Permite leer o modificar la base de datos: usuarios, contraseñas cifradas, pedidos, datos de clientes. Si manejas datos personales, además del problema técnico tienes un problema de cumplimiento, porque puede constituir una brecha notificable.

XSS (cross-site scripting)

Permite inyectar código JavaScript en tus páginas. Suena menor y a veces lo es, pero depende del tipo: un XSS «almacenado» que se ejecuta cuando un administrador entra al panel puede terminar creando un usuario nuevo con tus permisos. La distinción importa: un XSS que requiere que la víctima haga clic en un enlace preparado es bastante menos grave que uno que se dispara solo.

Hay un matiz que conviene retener: muchos fallos solo se explotan si el atacante ya tiene una cuenta, aunque sea de suscriptor. Si tu web no permite registro, ese fallo baja mucho de prioridad. Saber leer eso es lo que separa una lista de 40 avisos de una lista de 3 cosas que hacer hoy.

Cómo hacer el inventario de tus plugins en diez minutos

No puedes proteger lo que no sabes que tienes. Y lo más habitual es que tengas más plugins de los que crees.

La vía rápida, desde el panel: Plugins > Plugins instalados. Copia la lista completa con la versión de cada uno a una hoja de cálculo, con cuatro columnas: nombre, versión, activo o no, y de dónde salió (repositorio oficial, comprado, incluido en el tema, hecho a medida). Esa cuarta columna es la que más te va a servir después.

Si tienes acceso por SSH y WP-CLI, es cuestión de un comando:

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

Y para ver de un vistazo lo que tiene actualización pendiente:

wp plugin list --update=available

Si ni siquiera tienes acceso al panel, se puede deducir bastante desde fuera: muchos plugins dejan su versión en un archivo público, y tudominio.es/wp-content/plugins/nombre-del-plugin/readme.txt suele mostrar la línea Stable tag. Es lo que hacen los rastreadores para saber a quién atacar. El procedimiento completo, en cómo saber qué plugins tiene instalados tu WordPress.

Plugins activos, desactivados y los que vienen dentro del tema

Tres avisos que cambian el inventario por completo:

Un plugin desactivado es igual de peligroso que uno activo. Sus archivos siguen en el servidor y, en muchos fallos, se pueden invocar directamente por URL sin que WordPress los haya cargado. Si no lo usas, no lo desactives: bórralo.
Los plugins que vienen dentro del tema no aparecen igual. Muchos temas comerciales incluyen constructores y sliders con licencia del autor del tema. Solo se actualizan cuando el autor del tema publica una versión nueva, y a veces tarda meses. Es el bloqueo más frecuente del mercado español y tiene su propio artículo: WPBakery viene con mi tema y no puedo actualizarlo.
La carpeta wp-content/mu-plugins ejecuta lo que haya dentro sin aparecer en la lista y sin poder desactivarse desde el panel. Ábrela y mira qué hay. Si tú no la creaste, es motivo de revisión inmediata.

Dónde comprobar si un plugin tuyo tiene vulnerabilidades conocidas

Existen bases de datos públicas y gratuitas donde se catalogan los fallos de plugins de WordPress: WPScan, Patchstack y el registro de inteligencia de vulnerabilidades de Wordfence son las tres de referencia. Buscas el nombre del plugin, ves los fallos publicados y, en cada uno, en qué versión se corrigió.

La forma de usarlas sin perder la tarde:

Ordena tu inventario poniendo primero los plugins que no se actualizan desde hace más tiempo y los que tienen más privilegios.
Busca cada uno y quédate solo con los avisos cuya versión corregida sea superior a la tuya. Todo lo anterior ya no te afecta.
Para cada aviso que sí te afecte, apunta dos datos: qué permite hacer y si hace falta estar autenticado.

También puedes mirar la ficha del plugin en es.wordpress.org/plugins/. Dos señales ahí valen mucho: la fecha de última actualización y el aviso de que el plugin ha sido cerrado. Si un plugin lleva mucho tiempo sin tocarse o ha desaparecido del repositorio, el problema ya no es una versión concreta: es que nadie va a parchearlo nunca más.

Cómo leer un aviso de seguridad y decidir si te corre prisa

Un aviso trae más información de la que parece. Estas son las cuatro preguntas que debes contestar con él delante, en este orden:

¿Qué versión lo corrige y cuál tengo yo? Si tu versión es igual o superior, has terminado. Este paso descarta la mayoría de las alarmas.
¿Hace falta estar autenticado, y con qué rol? «Sin autenticación» es lo más grave. «Requiere rol de colaborador» solo te afecta si tienes usuarios con ese rol y no confías al cien por cien en todos ellos.
¿Qué permite conseguir? Ejecutar código o crear administradores es máxima prioridad. Leer una configuración o inyectar un script en una página concreta es mucho menos.
¿Hay explotación activa? Si el aviso menciona que se está explotando en la práctica, sube al primer puesto sea cual sea la puntuación teórica.

Verás también una puntuación CVSS del 0 al 10. Úsala como orientación, no como sentencia: una puntuación alta en un fallo que exige condiciones que tu web no cumple es menos urgente que una media en algo que un robot está probando en tu dominio ahora mismo. La lectura detallada, campo por campo, está en cómo leer un aviso de seguridad de un plugin.

Qué hacer cuando no puedes actualizar

Este es el escenario real de muchísimas pymes, y casi nadie lo trata con honestidad. Hay tres bloqueos típicos:

El plugin viene dentro del tema y actualizarlo por tu cuenta rompe la licencia o el tema lo sobrescribe.
La licencia ha caducado y sin ella no llegan las actualizaciones. Es exactamente lo que pasa con una licencia de WP Rocket caducada: el plugin sigue funcionando, y por eso nadie se entera de que ya no recibe parches.
Un desarrollo a medida depende de la versión antigua y al actualizar deja de funcionar algo del negocio.

Mientras resuelves el bloqueo de fondo, esto es lo que reduce la exposición de verdad:

Desactiva la función concreta que tiene el fallo, si el plugin permite apagar ese módulo sin tocar el resto. Muchos grandes lo permiten.
Cierra el registro de usuarios si el fallo requiere autenticación y tú no necesitas que nadie se registre: Ajustes > Generales > Cualquiera puede registrarse.
Bloquea la ruta afectada en el servidor o en tu WAF, si el aviso identifica un archivo concreto, y reduce los roles de quien no necesita tenerlos.
Pon vigilancia mientras tanto. Si estás expuesto y no puedes cerrarlo, tienes que enterarte el día que lo usen contra ti, no tres semanas después.
Ponle fecha a la solución. «Ya lo miraremos» se convierte en dos años. Comprar la licencia, migrar de plugin o cambiar de tema tiene un coste; seguir expuesto también.

Y una decisión que hay que tomar sin sentimentalismos: si el plugin está abandonado, la solución no es esperar. Un plugin sin mantenimiento no va a recibir el parche. Toca sustituirlo, y cuanto antes se decide, más barato sale.

Cómo priorizar: qué parcheas hoy y qué puede esperar

Una regla de tres niveles que funciona en el mundo real:

Hoy, aunque sea sábado. Fallos sin autenticación que permiten subir archivos, ejecutar código o crear administradores. Y cualquier fallo con explotación activa confirmada, en el plugin que sea.
Esta semana. Fallos que requieren un rol bajo que tú sí tienes en la web, inyecciones SQL y XSS almacenados en el panel de administración.
En la revisión del mes. Todo lo demás: fallos que exigen ser administrador (quien ya es administrador tiene el control de todos modos), o que dependen de configuraciones que tu web no usa.

Aplica encima un multiplicador según qué haga tu web: una tienda que cobra, una web con área de clientes o cualquier sitio con datos personales sube un nivel en todo. El método completo, con la tabla de decisión, está en cómo priorizar los parches en una pyme.

Rutina mensual de actualizaciones para una empresa sin equipo técnico

Media hora al mes, siempre el mismo día, siempre en el mismo orden. Nunca un viernes por la tarde:

Copia completa y comprobada, archivos y base de datos, descargada fuera del hosting, y anota las versiones de partida por si hay que volver.
Actualiza primero el núcleo, luego los plugins y por último el tema.
De uno en uno los plugins críticos (tienda, pagos, formularios, constructor), comprobando después de cada uno. Los demás pueden ir por tandas.
Revisa las páginas que importan: portada, ficha de producto, proceso de compra completo, formulario de contacto y panel de administración.
Borra lo que no uses y anota los plugins que su autor lleva demasiado tiempo sin actualizar.

El procedimiento con entorno de pruebas y vuelta atrás está en cómo actualizar los plugins de WordPress sin romper la web, que es lo que hace que esta rutina se cumpla sin miedo. Y si prefieres delegarlo, mira antes qué es razonable exigir en cómo auditar la web que te ha entregado una agencia.

Señales de que un plugin vulnerable ya se ha explotado en tu web

Actualizar te dice que estabas expuesto. Estas señales te dicen si además ya han entrado:

Usuarios administradores que no reconoces, o un cambio en el correo de administración que tú no hiciste.
Archivos PHP en wp-content/uploads. Ahí nunca debería haber ninguno.
Archivos modificados con fechas que no cuadran con ningún trabajo tuyo. Compruébalo así:
```
find . -type f -name "*.php" -mtime -20 -ls
```
Entradas o páginas nuevas que no has creado, a menudo publicadas de madrugada.
Redirecciones que solo ocurren en móvil o al llegar desde Google, y no cuando entras tú directamente.
Tareas programadas que no reconoces: wp cron event list.
Picos de consumo de CPU o de correo saliente en las estadísticas del hosting.
Una carpeta mu-plugins que apareció sola.

Dos comprobaciones más que valen mucho y son gratis, si tienes WP-CLI:

wp core verify-checksums
wp plugin verify-checksums --all

Comparan tus archivos con los oficiales del repositorio y te cantan cualquier modificación. No cubren plugins de pago ni temas, pero para todo lo que venga del repositorio oficial es la verificación más rápida y fiable que hay.

Qué hacer las primeras horas si sospechas que te han entrado

Si alguna señal ha dado positivo, cambia el chip: ya no es mantenimiento, es un incidente. En resumen muy breve, y en este orden: haz una copia completa del estado actual y guárdala aparte antes de tocar nada, descarga los registros de acceso antes de que roten, cambia todas las contraseñas desde un ordenador limpio, y solo entonces empieza a limpiar. No restaures una copia anterior sin saber desde cuándo estabas comprometido, porque lo más probable es que esa copia ya lleve dentro la puerta trasera.

Y actualiza el plugin de todas formas, pero sabiendo que eso cierra la entrada y no expulsa al que ya está dentro.

Guía por familias: qué revisar en los plugins más instalados en España

Tienda, constructores y formularios

WooCommerce. El núcleo suele ir bien mantenido; el riesgo real está en las extensiones de pago, envío y facturación, que se compran una vez y se olvidan. Después de cualquier actualización, revisa administradores, claves de API y webhooks, que es donde se manipula un proceso de compra sin que se note. Tienes el repaso completo en cómo comprobar si tu WooCommerce es vulnerable.

Elementor. Igual: el constructor se actualiza, pero los complementos de terceros que le añaden widgets son los que quedan atrás, sobre todo los que llegaron con una plantilla y nadie recuerda haber instalado. Cómo listarlos y cuáles ya no se mantienen, en cómo saber si tu versión de Elementor es vulnerable.

WPBakery y sliders incluidos en el tema. El caso clásico del plugin que no se actualiza solo porque va dentro del tema comprado. Aplica lo dicho arriba, y en el caso de los sliders veteranos revisa también qué versión llevas por dentro: cómo comprobar la versión de Revolution Slider.

Formularios. Reciben datos de desconocidos por definición: son la superficie más expuesta que tienes. Mira además si el plugin guarda los mensajes en la base de datos, porque eso son datos personales y entra en tus obligaciones.

Advanced Custom Fields y similares. Su peculiaridad no es tanto el fallo puntual como la dependencia: media web deja de funcionar si algo va mal. Eso obliga a probar antes de actualizar, y ahí es donde la gente lo aplaza indefinidamente. Lo tratamos en el riesgo de depender de un plugin como ACF.

Caché, copias de seguridad y migración

Plugins de caché. Parecen inofensivos y no lo son: tocan archivos en disco, generan reglas de servidor y sirven contenido saltándose parte de WordPress. El más extendido en hostings españoles tiene su propio repaso en cómo comprobar tu versión de LiteSpeed Cache.

Copias de seguridad y migración. Estos plugins generan archivos comprimidos con toda tu web y toda tu base de datos dentro. Si ese archivo queda accesible desde el navegador, alguien se lleva tus contraseñas cifradas y tus datos de clientes sin explotar nada. Comprueba dónde deja los archivos tu plugin y que esa carpeta no sea pública. Qué debe llevar dentro una copia útil está en qué debe incluir una copia de seguridad.

Gestores de archivos. Directamente, no los tengas instalados de forma permanente.

SEO, correo, multiidioma y plugins con permisos amplios

Los plugins de SEO editan metadatos de todas tus páginas; los de correo guardan credenciales SMTP en la base de datos; los de multiidioma tocan URLs y contenidos en masa. Ninguno es peligroso por naturaleza, pero todos tienen permisos amplios, así que ordénalos arriba en tu inventario. En los de correo, mira si guardan la contraseña SMTP en claro: si es así, cualquier fallo que permita leer opciones de la base de datos entrega también tu buzón.

Los temas transversales: plugins abandonados, plugins nulled y el mito del plugin de seguridad

Plugins abandonados. El criterio no es una fecha exacta, es este: si el autor no responde, no hay versiones nuevas y el plugin ha desaparecido del repositorio, ese plugin no va a recibir el parche cuando aparezca el fallo. No es urgente hoy, pero sí es un plan a tres meses.

Plugins nulled. Un plugin de pago descargado gratis de una web de piratería viene, con muchísima frecuencia, con código añadido: un administrador oculto, un enlace insertado en tu pie de página o una carga remota que se activa semanas después. Y aquí no hay actualización que te salve, porque el problema no es una versión: es que instalaste voluntariamente el código del atacante. Cómo comprobarlo sin ser programador está en cómo saber si un plugin nulled tiene una puerta trasera.

El plugin de seguridad. Ayuda, y en algunas cosas mucho: limitar intentos de acceso, avisarte de cambios en archivos, filtrar peticiones evidentes. Pero no parchea el fallo de otro plugin y no sustituye a tener el inventario al día. La comparativa sin marketing, con lo que hace cada uno y lo que no, en cuál es el mejor plugin de seguridad para WordPress. Y como complemento, la puerta que más ataques recibe sigue siendo el acceso al panel: cómo proteger wp-login.php de los ataques de fuerza bruta.

Preguntas frecuentes

¿Activo las actualizaciones automáticas de los plugins?

Para plugins pequeños, de autores serios y que no afectan al diseño ni a la venta, sí: el riesgo de romper algo es menor que el de quedarte sin parchear. Para el constructor, la tienda y la pasarela de pago, no: esos se actualizan mirando.

Tengo 35 plugins. ¿Son muchos?

El número por sí solo no dice gran cosa. Lo que importa es cuántos están mantenidos, cuántos usas de verdad y cuántos tienen permisos amplios. Dicho eso, en casi todos los inventarios que revisamos sobran entre cinco y diez que nadie usa desde hace años.

Actualicé el plugin en cuanto salió el aviso. ¿Estoy a salvo?

Estás a salvo de que te entren por ahí a partir de ahora. Si el aviso llevaba días publicado, comprueba además las señales de explotación de más arriba antes de darlo por cerrado.

¿Y si actualizar rompe la web?

Por eso el orden es copia primero, entorno de pruebas si puedes, y uno en uno. Una actualización que rompe el diseño se revierte en minutos; una web comprometida no.

¿Necesito pagar a alguien para esto?

Para el inventario y la rutina mensual, no: es trabajo tuyo de media hora al mes y lo puedes hacer perfectamente. Delegar tiene sentido cuando la web genera ingresos, cuando hay varias webs, o cuando ya te ha pasado algo y no quieres volver a pasar por ahí.

Si quieres empezar por lo más rápido, mira primero qué está enseñando tu web al mundo: versiones expuestas, archivos que no deberían ser públicos y señales de que alguien ya ha estado dentro. Puedes analizar tu web gratis con PathScan sin registrarte y sin instalar nada; el análisis se hace desde fuera, igual que lo haría un atacante, y te da un punto de partida honesto para el inventario que acabas de leer.

Seguir leyendo en esta sección

Ver todo en Seguridad de plugins WordPress → · Mapa completo del sitio