Un plugin de seguridad vigila tu WordPress, eso lo tiene claro cualquiera que haya instalado uno. La pregunta rara es otra, que igual te suena como pregunta de toda la vida, me refiero a ¿y quién vigila al vigilante?

Si alguien consigue tocar los archivos de tu plugin de seguridad te quedas sin nada, lo que tienes instalado ya no es un guardia, es un segurata sobornado que sigue con la gorra puesta y te sigue diciendo que todo está en orden, pero trabajando en la sombra para tus enemigos.

Con la versión 3.0.0 del plugin Vigilante esa pregunta ya tiene respuesta, pues el plugin comprueba sus propios archivos, te cuenta qué ha encontrado y qué significa, y te ofrece arreglarlo con un botón.

Es todo igual un poco técnico, pero por lo raro, por lo novedoso, y ¡qué coño! porque me he pegado una currada del catorce y creo que es algo bueno, ni te digo siendo un plugin de seguridad totalmente gratis, pues que te animo a leer esta apasionante aventura…

La idea viene de lejos

Esto no se me ocurrió ayer, la autoprotección está apuntada en la hoja de ruta de Vigilante desde las pruebas de la versión 2.4.0, en mayo de 2026,

El razonamiento de entonces sigue siendo el de ahora, que un plugin de seguridad manipulado es peor que no tener ninguno, porque no solo deja de protegerte, es que además te tranquiliza.

Piénsalo desde el lado del que ataca, Si alguien consigue escribir en tu servidor (una contraseña de FTP que se filtró, un plugin vulnerable, un hosting comprometido) y quiere quedarse a vivir lo primero que le interesa es que nadie se entere.

La forma más cómoda de que nadie se entere es dejar a ciegas al que vigila, tocando dos líneas del plugin de seguridad para que no mire donde no debe o para que no avise.

Si revisas el historial de cualquier plugin de seguridad, desde el más pequeño al más grande verás que suelen ser fuente de posibles vulnerabilidades, que alguien puede aprovechar, y sí, por si lo has pensado, también Vigilante ha tenido vulnerabilidades puntuales (pero como me conoces las arreglé la misma tarde)

Dicho esto, ya te aclaro un concepto importante, y es que la autoprotección no significa que el plugin sea impenetrable, no tiene nada que ver, la autoprotección es una capa de vigilancia adicional, no una vacuna contra cualquier posible intento de ataque.

Vamos al grano, que te cuento ya cómo se autoprotege Vigilante…

Las 3 capas de autoprotección de Vigilante

Para saber si sus archivos son los buenos, Vigilante no se fía de una sola fuente, se apoya en tres, y las compara entre sí.

Es como comprobar un contrato con tres copias, la que guarda el notario, la que va grapada al propio contrato y la foto que le hiciste con el móvil el día que lo firmaste.

• Los checksums de WordPress.org: la huella SHA-256 (una especie de huella dactilar de cada archivo, cambias una coma y cambia la huella entera) que WordPress.org publica para cada archivo de la versión que tienes instalada. Es la referencia que está fuera de tu servidor, y por eso la que más vale.
• El archivo MANIFEST.sha256: va dentro del propio plugin con la huella de cada archivo que se distribuye (63 en esta versión). Sirve para comprobar sin conexión, desde la línea de comandos y en las primeras horas de cada versión, cuando WordPress.org todavía no ha publicado sus checksums.
• Una huella del manifiesto, guardada en tu base de datos: Vigilante la toma la primera vez que ve el manifiesto y solo la renueva cuando el actualizador de WordPress instala una versión nueva o cuando WordPress.org confirma esa versión. Ni siquiera la vuelve a tomar si desactivas y reactivas el plugin.

¿Y para qué tres, si con la de WordPress.org ya valdría? Pues porque cada una tapa el agujero de las otras.

Quien quiera esconder un cambio regenerando el manifiesto se choca con la huella guardada, quien borre la huella se choca con WordPress.org, y el manifiesto cubre las horas en las que WordPress.org aún no tiene nada publicado.

Para engañar a las tres a la vez, un atacante tendría que controlar tu servidor, tu base de datos y WordPress.org, y si alguien controla WordPress.org tenemos todos un problema bastante más gordo que este.

Cuándo se hacen las comprobaciones y por qué se hacen ahí

Una comprobación que se lanza cuando le apetece no sirve de mucho, así que se ejecuta en los momentos en los que de verdad puede pasar algo:

• Al empezar cada exploración de integridad de archivos, manual o programado, antes que cualquier otra cosa. Queda fuera del límite de tiempo del escaneo y no respeta tus exclusiones, porque excluir la carpeta del plugin por error no debería dejarlo a ciegas.
• Justo después de que WordPress actualice Vigilante, en esa misma petición, también si lo actualizas subiendo el zip a mano. Es el momento en el que aparecería un archivo a medio copiar o uno cambiado por el camino.
• Cuando la versión cambia por la puerta de atrás (una subida por FTP, el gestor de archivos del hosting, un despliegue o una versión anterior), en la siguiente pantalla de administración que abra un administrador o en la tarea de mantenimiento diaria.
• Una vez al día como mínimo, si nada de lo anterior ha comprobado nada en las últimas 24 horas. Aunque tengas apagado el módulo de integridad de archivos o las exploraciones programadas, porque una comprobación que depende de un ajuste que se puede apagar no es protección, es un adorno.

Además también vigila sus propias tareas programadas, que es otra forma muy discreta de dejar sin vigilancia un WordPress. Te lo cuento luego.

¿Qué detecta la autoprotección de Vigilante?

Aquí está lo gordo de esto, de lo que me siento más orgulloso, y lo que más me apetecía contarte, porque me ha llevado meses de darle vueltas y cientos de horas de pruebas.

Cada posible caso lleva su nivel gravedad, qué significa (el propio plugin te lo explica con estas mismas palabras en pantalla) y qué te ofrece para arreglarlo. No hay ningún hallazgo que te deje con el susto y sin saber qué hacer.

Si algo modifica sus archivos

• Un archivo de código modificado (crítico): un PHP, un JavaScript o un archivo de datos que el plugin carga ya no coincide con el que publica WordPress.org. Algo con permiso de escritura en tu servidor lo ha cambiado, sea un atacante, un script o una edición a mano. Te ofrece repararlo.
• Una hoja de estilos o una imagen modificadas (aviso): casi siempre es un plugin de optimización o de caché, o tu propio hosting, que la reescribe al minificar o combinar archivos. Por eso es aviso y no alarma. Te dice que excluyas la carpeta wp-content/plugins/vigilante del optimizador y que después repares.
• Un archivo borrado (crítico): un módulo que falta deja de protegerte sin mostrar ningún error, que es justo lo peligroso. Te ofrece reponerlo reparando.
• Un archivo que no se puede leer (crítico): si no lo puede leer no lo puede comprobar, y los archivos que distribuye WordPress.org siempre se pueden leer. Reparar lo devuelve con permisos normales, y si falla te dice que se lo pidas a tu hosting.

Y lo que no te va a marcar importa tanto como lo anterior. Si tu servidor cambia los saltos de línea de un archivo de texto (cosas de servidores Windows y de algunas herramientas de sincronización), eso no es una manipulación y no sale. Un aviso que salta sin motivo acaba ignorado, y un aviso ignorado es peor que no tenerlo.

Si aparecen cosas que no son del plugin

• Un ejecutable añadido (crítico): un PHP, o cualquier archivo que el servidor web pueda ejecutar se llame como se llame (un foto.php.jpg también cuenta, y un .htaccess o un .user.ini también), que está en la carpeta del plugin y no es del plugin. Esconder archivos dentro de un plugin de seguridad es una forma habitual de dejar una puerta trasera. Ojo al consejo que da el propio plugin, que es de los que se agradecen: si quieres saber cómo llegó ahí, pide al hosting la fecha de creación del fichero antes de reparar, porque reparar lo borra y con él la pista.
• Un archivo extra que no es código (aviso): muchas veces es un error_log que escribe tu servidor, o restos de una copia de seguridad o de una sincronización. Si es un registro de errores, te sugiere abrirlo y, si los errores mencionan a Vigilant, contarlo en el foro de soporte.
• Un enlace simbólico (crítico): un archivo del plugin que en realidad es un acceso directo a otro sitio, o que apunta fuera de la carpeta. WordPress.org nunca distribuye enlaces, así que alguien lo ha puesto ahí.
• Una carpeta que no se puede revisar (crítico): no puede listar una de sus carpetas, o encuentra muchísimos más archivos de los que distribuye. Un servidor web puede ejecutar un archivo escondido en una carpeta que no se puede listar si alguien sabe su nombre, así que no se da por buena.

Si algo cambia la lista de referencia, el manifiesto

• Manifiesto sustituido, borrado o dañado sin actualizar (crítico): cambiar esa lista es justo lo que haría alguien para esconder cambios en el plugin. Aquí es donde la huella guardada en tu base de datos se gana el sueldo.
• Manifiesto que falta o no es válido: sigue comprobando contra WordPress.org, pero ha perdido una de sus tres referencias. Reparar lo restaura.
• Distinto de la copia de WordPress.org: los archivos cuadran con el manifiesto que trae el propio plugin, pero no con lo que WordPress.org distribuye para esa versión. En una copia de desarrollo es lo esperable, pero en una web en producción significa que el plugin entero, manifiesto incluido, ha salido de otro sitio. Es crítico si afecta a archivos que se pueden ejecutar y aviso en el resto.

Si cambia la versión por la puerta de atrás

• Una versión anterior instalada (aviso, con correo): alguien ha sustituido Vigilant por una versión más vieja, y las versiones viejas pueden tener fallos ya corregidos y públicos. Si no lo has hecho tú a propósito, reparar instala la versión que distribuye WordPress.org en ese momento.
• Una versión nueva que todavía no se puede confirmar (aviso, con correo): la versión ha cambiado sin pasar por el actualizador de WordPress y WordPress.org aún no ha publicado sus checksums. Si la has subido tú a mano con una copia de WordPress.org no tienes que hacer nada, porque se confirma sola en cuanto se publican (normalmente en un día). Si no has sido tú, o la copia no venía de WordPress.org, repara.

Si alguien/algo borra las tareas programadas

Vigilant funciona con cinco tareas programadas propias (el mantenimiento diario, las comprobaciones de cada hora, el análisis semanal de Security Check, la comprobación de plugins cerrados en WordPress.org y el escaneo programado de integridad). Si alguien las borra, el plugin sigue instalado, sigue activo y no hace nada, que es otra forma de dejarlo a oscuras sin tocar un solo archivo.

• Una tarea repuesta (queda en el registro): una de ellas había desaparecido y Vigilant la ha vuelto a programar. Un plugin de limpieza del cron (las tareas programadas de WordPress), restaurar una copia de la base de datos o una migración pueden provocarlo. Si no vuelve a pasar, no hay nada que hacer.
• Tareas que desaparecen una y otra vez (crítico, con correo): la misma tarea borrada de nuevo en menos de 30 días. Mientras no están no hay escaneos programados, ni comprobación diaria, ni avisos. Te sugiere buscar el plugin de limpieza que lo hace y excluir las tareas que empiezan por vigilante_ (un plugin como WP Crontrol te las enseña), y si no encuentras la causa, tratarlo como una posible intrusión y revisar los plugins instalados hace poco y las cuentas de administrador.

Las tareas que hayas apagado tú (el análisis semanal, por ejemplo) se respetan, faltaría más. Y en una red multisitio este vigilante de tareas cubre el sitio principal.

Si algo intenta apagar el plugin o que silenciarlo

Esta es la parte que más me gusta, porque es donde un atacante listo iría primero.

• Apagada por código (crítico, con correo una vez al día): no hay ninguna casilla para apagar la autoprotección (luego te cuento por qué). Lo único que la apaga es un filtro en el código, y cuando alguien lo usa Vigilant te dice en todas las pantallas qué archivos lo enganchan, con nombre y ruta. Si no lo has pedido tú, trátalo como una intrusión, porque un plugin o un fragmento de código que apaga la comprobación de un plugin de seguridad está haciendo lo primero que necesita un atacante.
• Alguien le ha quitado los enganches (crítico): código que desengancha las comprobaciones que corren tras cada actualización y en cada pantalla de administración, para que el plugin siga enseñando su último resultado como si fuera de hoy. WordPress no avisa cuando alguien quita una función de un gancho, así que aquí no se puede nombrar el archivo culpable, pero en el registro queda la lista de plugins cargados en esa petición, que es la lista corta de sospechosos. Te propone desactivarlos uno a uno hasta que deje de pasar.
• Sin comprobar desde hace más de tres días (aviso): lo que ves ya no es un resultado actual. Pasa en webs que no abre nadie y sin cron funcionando, y pasa también cuando algo ha parado la comprobación sin que se note. La pantalla nunca te enseña un verde viejo como si fuera de hoy.
• No ha podido comprobar nada: sin manifiesto y sin conexión con WordPress.org no tiene contra qué comparar. Te manda a «Herramientas > Salud del sitio» para ver si tu servidor llega a WordPress.org, y a pedírselo al hosting si no llega.

Más información que registra aunque no sea crítica

• Verificado: sus archivos cuadran con las tres referencias. Es lo normal y lo que tienes que ver casi siempre.
• Verificado con dos de tres referencias: cuadran con el manifiesto y con la huella, pero WordPress.org aún no ha publicado sus checksums, cosa normal durante unas horas tras cada versión. Si dura más de dos días, revisa que tu servidor llegue a WordPress.org.
• Comprobado justo después de actualizar: WordPress lo actualizó y se revisó en esa misma petición.
• Integridad restaurada: lo que se había reportado vuelve a coincidir con lo que distribuye WordPress.org, así que queda cerrado.
• Referencia guardada: ha guardado la huella de su manifiesto en tu base de datos, que es lo que permite detectar después un manifiesto cambiado.
• Todavía sin comprobar: recién instalado. Lanza un escaneo y listo.

¿Y yo en qué lo noto?

Si todo va bien, en casi nada, y eso es lo mejor de todo, no es un problema, todo lo contrario. Lo que notas es que el día que pase algo te enteras tú, no el que ha entrado.

Hasta ahora si alguien tocaba los archivos de tu plugin de seguridad, el plugin seguía diciendo que todo iba bien. Con Vigilante, desde la 3.0.0, eso sale en rojo y no hay que ir a buscarlo.

Esto es lo que ves, y dónde:

• Una caja propia, la primera de los resultados de la exploración de integridad de archivos: con un color por estado y una fila plegable por cada caso, con los archivos afectados, qué significa y qué hacer, la primera abierta y el resto cerradas. Si todo va bien, se queda en una línea discreta con la fecha de la última comprobación.
• Un aviso que no se puede descartar: si es crítico, en todas las pantallas del escritorio de WordPress (entradas, páginas, lo que sea), y si es un aviso, solo en las de Vigilante. En los dos casos solo lo ven los administradores, que tu editora no tiene por qué llevarse el susto.
• Un contador rojo o naranja en el menú de Vigilante y en el de la herramienta de exploración de la integridad de archivos, como el de las actualizaciones pendientes.
• Una ficha en el escritorio de Vigilante con el estado y un enlace directo a la caja correspondiente.
• Las dos notas de Vigilante bajan a E (la de configuración y la de la comprobación de seguridad) con el motivo escrito. Todo lo demás que te enseña el plugin lo calcula ese mismo código, y si ese código está tocado el plugin no puede fingir que el resto de sus resultados son de fiar. Además la comprobación de autoprotección pasa a ser la de más peso de la categoría interna de la comprobación de seguridad.
• Una entrada en en la auditoría de seguridad que, al abrir su detalle, te dice qué ha pasado con los archivos, qué significa y qué hacer, sin perder los datos de siempre.
• Un correo propio con las alertas: luego te cuento sus reglas, que tienen su intención.

Y también hay cosas que ya no ves, como por ejemplo que en los hallazgos de los archivos de Vigilante no hay botón de ignorar, ni para el administrador ni para el superadministrador de una red, porque eso no se silencia, se arregla.

Tampoco salen mezclados con los archivos sospechosos del escaneo normal, y el «todo correcto» de la exploración no aparece mientras la autoprotección esté en rojo o en ámbar.

El correo de aviso

La autoprotección tiene su propio aviso por correo, y no hay ningún ajuste que lo apague. No va dentro del correo de los resultados de la exploración de integridad de archivos ni dentro de las alertas de la auditoría de seguridad.

Esto es así porque el resto de alertas se pueden desactivar en los ajustes, y si así fuera apagar «avísame de los archivos cambiados» estaría apagando también la alarma del propio plugin, y eso no tenía ningún sentido.

• Siempre manda correo con un hallazgo crítico, lo detecte donde lo detecte (un escaneo, la comprobación tras actualizar, un cambio de versión, el vigilante de tareas, la comprobación apagada por código o los enganches quitados).
• Avisos de versiones: una versión anterior instalada y un cambio de versión que no se puede confirmar.
• El resto de avisos se quedan en pantalla. Mandar un correo en cada exploración porque un optimizador reescribe una hoja de estilos es la forma más rápida de que nadie lea los correos.
• Una vez por cada conjunto de hallazgos: si pasa lo mismo, no te escribe otra vez, y si cambia lo que encuentra, sí.
• En una red multisitio sale una sola vez, desde el sitio principal, y llega también al correo de administración de la red.
• Sin recordatorios: Esto lo decidí a propósito, porque si no haces caso al primer correo no vas a hacer caso al quinto, y mientras el problema siga ahí la pantalla te lo sigue diciendo en cada visita.

Auto-reparaciones a un clic

Dar información sin solución es media herramienta, así que cuando Vigilante encuentra sus archivos han cambiado te ofrece un botón de reparación.

Primero te pregunta, en una pantalla que dice exactamente qué versión va a descargar y qué va a cambiar, y después hace lo mismo que hace el actualizador de WordPress con cualquier plugin, que es descargar el paquete de WordPress.org y sustituir la carpeta.

• Solo cambian los archivos: los ajustes, las tablas de la base de datos y el registro se quedan como estaban, porque no se desinstala nada ni se desactiva el plugin.
• Lo que no sea de Vigilante también se elimina: así es como desaparece un archivo inyectado.
• Instala la versión que distribuye WordPress.org en ese momento, nunca la que dicen los archivos del disco y nunca una anterior a la que tu web ya había verificado. ¿Que por qué no se fía de la versión que pone el plugin? Pues porque quien puede cambiar los archivos puede escribir también esa versión, y un reparador que se fiara de ella acabaría siendo una bajada a una versión con fallos públicos.
• La dirección del paquete la construye el propio plugin con un servidor fijo y una versión que tiene que cumplir un formato estricto. Nada de lo que llega en la petición se usa para eso.
• Comprueba otra vez al terminar, contra WordPress.org y contra el manifiesto, y te enseña el resultado.

En tres casos no te ofrece el botón y te da los pasos a mano, distintos en cada uno.

Cuando la carpeta del plugin tiene otro nombre (el paquete siempre se instala como vigilante y dejarías una copia limpia al lado de la que funciona), cuando tu instalación tiene prohibido modificar archivos con DISALLOW_FILE_MODS, y cuando eres administrador de un subsitio en una red, donde eso le toca al superadmin.

Y hay algo que no te promete, y es que si quien cambió los archivos cambió también el código que los repara, ese botón es tan de fiar como el resto de la copia. La comprobación que no depende de tu servidor sigue siendo la que se hace desde fuera, y te explico cómo más abajo.

No hay interruptor, para «esos» casos

A ver, entiendo el argumento contrario, y tiene su parte de razón. Hay webs que no pueden conectarse con WordPress.org por política de su empresa, hay copias de desarrollo en las que no te apetece ver avisos, y a nadie le gusta un plugin que no le deja apagar sus cosas.

Ahora bien, piensa quién sería el usuario más fiel de una casilla que dijera «no compruebes tus propios archivos». Pues el que acaba de tocarlos.

Una autoprotección que se apaga con una casilla es una alarma de casa con el botón de apagado en la puerta de fuera. Esa casilla existió mientras desarrollaba esta versión, y la quité antes de publicarla.

Para el caso que te comentaba, el de la web que de verdad no puede hablar con WordPress.org, queda un filtro en el código, documentado en el SECURITY.md del plugin:

add_filter( 'vigilante_self_integrity_enabled', '__return_false' );

Y con él puesto Vigilante lo avisa como crítico en todas las pantallas, nombra los archivos que enganchan el filtro y lo apunta en el registro. Apagarlo se puede, apagarlo a escondidas no.

Lo mismo con el código que quita los ganchos y con la comprobación que deja de ejecutarse, que ya te conté más arriba. Nada de esto impide que un código que corre dentro de WordPress anule al plugin.

Fernando Tellado -Ayuda WordPress