Vigilante – Suite de seguridad 100% gratis: Cortafuegos, 2FA, login, cabeceras, escáner…

Registro de cambios

2.9.8

• Mejorado: Los ajustes iniciales ya no fuerzan el uso de HTTPS en ningún sitio. Las opciones «Forzar SSL en la administración» (que escribe FORCE_SSL_ADMIN en el archivo wp-config.php), «Redirigir de HTTP a HTTPS» y «Corregir contenido mixto» arrancan inactivos, sumándose a HSTS y a la reescritura de la dirección del sitio, que ya estaban desactivadas. «Corregir contenido mixto» no puede causar ningún problema, ya que solo reescribe las direcciones del propio sitio y únicamente en un sitio que ya se sirva a través de HTTPS, pero una opción cuya propia descripción indica que reescribe http a https no tiene cabida en los ajustes por defecto de un plugin que, deliberadamente, no decide si un sitio utiliza HTTPS. Basta con un clic para cualquiera que acabe de migrar y quiera que se reescriba su contenido antiguo. «Forzar SSL en la administración» se activaba sin comprobar en absoluto si el sitio respondía a través de HTTPS, por lo que al activar el plugin en un sitio que se sirva a través de HTTP se redirigía al administrador a una dirección que podía no existir, y en una red cualquier subsitio podía hacerlo para todos. Que un sitio utilice HTTPS es decisión del propietario, y ahora esto coincide con lo que ya hacían HSTS y la reescritura de la dirección del sitio.
• Mejorado: «Actualizar solicitudes inseguras» es ahora una opción independiente, desactivada por defecto. Antes formaba parte de la opción «Corregir contenido mixto», que viene activada por defecto, por lo que todos los sitios que se servían a través de HTTPS indicaban a los navegadores que actualizaran todas las solicitudes http://, incluidas aquellas que apuntaban a servidores de terceros: cualquier contenido alojado en un dominio sin HTTPS dejaba de cargarse en lugar de cargarse de forma insegura, y no había forma de mantener el resto de la gestión del contenido mixto sin desactivar esta opción. «Corregir contenido mixto» ahora hace solo lo que su nombre indica: reescribe las direcciones del propio sitio. Los sitios que se actualicen seguirán enviando la directiva si tenían activada la opción «Corregir contenido mixto», por lo que nada cambia para ellos hasta que decidan lo contrario, y también conservan la propia opción «Corregir contenido mixto»: el nuevo valor por defecto solo se aplica a las nuevas instalaciones.
• Mejorado: Los requisitos de contraseña que se aplican a las nuevas instalaciones son los dos que impiden el uso de contraseñas realmente fáciles de adivinar, las contraseñas comunes y conocidas, y la inclusión del nombre de usuario en la contraseña. Los cuatro requisitos de clase de caracteres (mayúsculas, minúsculas, números y símbolos) se mantienen disponibles para quien los desee. La recomendación actual es que lo que hace que una contraseña sea débil es que sea fácil de adivinar, no la falta de un símbolo, y las reglas de composición empujan a los usuarios hacia sustituciones predecibles. Los sitios existentes mantienen las reglas que ya tengan.
• Mejorado: Ahora las nuevas instalaciones activan los dos eventos que indican que alguien ha obtenido privilegios: la aparición de un nuevo administrador y el ascenso de permisos a algún perfil, ya que estos son indicios característicos de una apropiación de cuenta y son lo suficientemente poco frecuentes como para no convertirse en ruido. Las otras dos alertas de administrador siguen siendo opcionales.
• Mejorado: Los límites de sesión están activados en las nuevas instalaciones, con la opción de tres sesiones concurrentes y la de cerrar la más antigua, que ya eran los valores recomendados.
• Mejorado: Se ha desactivado por defecto la caducidad de contraseñas. Ya no se recomienda la rotación forzada, ya que es, con diferencia, la principal causa de las consultas de soporte, con usuarios que se quedan sin acceso en medio de una tarea. La característica sigue ahí para quienes tengan que cumplir con una política que lo exija, y la puntuación de configuración sigue recomendándola.
• Mejorado: El preajuste «Estándar» deja la opción de XML-RPC como en las nuevas instalaciones, bloqueando únicamente los métodos pingback. Antes desactivaba XML-RPC completamente, y para eso está el de «Máxima seguridad».
• Mejorado: El preajuste «Máxima seguridad» ahora activa las alertas de auditoría, tanto las inmediatas para eventos críticos como las de umbral, ya que una configuración con ese nombre que nunca te avisa de que ha ocurrido algo es un producto a medias. El modo «Bajo ataque» se basa en «Máxima seguridad», por lo que las mantiene activadas mientras esté activado y restaura tus ajustes al activarse. El tiempo de espera compartido evita que un ataque prolongado se convierta en una avalancha de correos electrónicos.
• Mejorado: Al restablecer los ajustes por defecto ya no se borra lo que hayas introducido. Las listas de direcciones IP y de agentes de usuario, la dirección de acceso personalizada, la configuración de identificación en dos pasos, las exclusiones del análisis de integridad y los destinatarios adicionales de alertas se conservan tanto al pulsar los botones de restablecimiento como al seleccionar el preajuste «Estándar». Los ajustes de seguridad siguen volviendo a sus valores por defecto. Nadie pulsa un botón llamado «Restablecer valores por defecto» esperando que desaparezca la lista blanca de su cortafuegos.
• Corrección (Multisitio): Al cambiar el prefijo de la base de datos, los subsitios ya no se quedan sin perfiles. La opción de perfiles se almacena una vez por sitio y solo se cambia el nombre de la que pertenece al sitio principal, por lo que todos los subsitios acababan con un menú desplegable de perfiles vacío y errores graves en los plugins que dan por hecho que existe un perfil. Ahora se revisan todos los sitios de la red y se repara cualquier subsitio cuya opción de perfiles contenga un nombre inesperado procedente de una migración anterior. Informado por Albert Calzada.
• Corrección (Multisitio): ya no es posible cambiar el prefijo de la base de datos desde un subsitio. La herramienta leía el prefijo del sitio desde el que se invocaba, por lo que, desde un subsitio, solo habría renombrado las tablas de ese sitio al reescribir el prefijo compartido por toda la red. La herramienta ya está disponible en el sitio principal para los administradores de red, y se explica con detalle en otra sección.
• Corrección (Multisitio): Los ajustes que modifican los archivos wp-config.php y .htaccess se gestionan únicamente desde el sitio principal. Estos dos archivos son compartidos por toda la red, mientras que los ajustes se almacenan por sitio. Por lo tanto, cada vez que se guardaban desde cualquier sitio, se reescribían según las opciones propias de ese sitio: el último en guardarse prevalecía, deshaciendo silenciosamente el resto, y cada pantalla seguía mostrando su propio valor almacenado en lugar de lo que realmente indicaba el archivo. Activar o desactivar el plugin en un subsitio provocaba lo mismo sin que nadie tocara ningún ajuste. Ahora, los subsitios ven esas secciones como de solo lectura, y se rechazan las modificaciones en cualquier otro lugar.
• Corrección (Multisitio): Ya no se ofrecen las copias de seguridad de la base de datos y la configuración a los subsitios. Tanto la base de datos como el archivo wp-config.php pertenecen a toda la red, por lo que una copia de seguridad realizada desde un subsitio incluiría todos los demás sitios, así como todos los usuarios de la red, incluidas las credenciales y los salts de autorización.
• Corrección: Al cambiar el prefijo de la base de datos ya no se renombran los ajustes que no tienen nada que ver con dicho prefijo. Solo hay un nombre de opción que se genera a partir del prefijo de la tabla, el que contiene los perfiles. Todo lo demás que empiece con las mismas letras es un nombre literal que pertenece a WordPress o a un plugin. Se renombraban todos, por lo que se perdía la selección de la página de la política de privacidad y los plugins que guardan su configuración en una opción cuyo nombre empiece por «wp_», entre ellos WP Rocket, no encontraban nada donde la almacenan. Lo mismo ocurría con los datos por usuario, por lo que también se renombraban el estado del alumno y los ajustes de traducción.
• Corrección: Al cambiar el prefijo de la base de datos ya no te saca de la sesión ni te redirige a la pantalla de instalación de WordPress. El archivo wp-config.php es un archivo PHP, por lo que la caché de opcode seguía sirviendo el prefijo anterior durante un par de segundos después de que se reescribiera, y cualquier solicitud que llegara en ese intervalo iniciaba WordPress con tablas que ya no existían: interpretaba que el sitio no estaba instalado y ofrecía el instalador, y la falta de la tabla de usuarios provocaba que la cookie de sesión fallara, a lo que WordPress responde borrándola. Ahora, el archivo se elimina de la caché de opcode nada más escribirse.
• Corrección: La caché de objetos se vacía tras un cambio en el prefijo de la base de datos. Las opciones se sirven desde ella, y las entradas renombradas se modificaban sin que WordPress se diera cuenta, por lo que un sitio con una caché de objetos persistente seguía utilizando los nombres antiguos.
• Corrección: El preajuste «Estándar» ahora aplica todos los valores por defecto, que es lo que dice que hace. Solo especificaba apenas una docena de campos, por lo que, al aplicarlo después del preajuste «Máximo», este último conservaba las reglas de contraseña de «Máximo», sus cuatro alertas de administrador, su límite de una sesión y su caducidad de contraseña de treinta días: el preajuste que promete valores por defecto sensatos no aplicaba casi ninguno de ellos. Ahora se basa en los propios valores por defecto, por lo que ya no puede desvirtuarse, y deja intactos los datos introducidos por el propietario del sitio: las listas de direcciones IP y de agentes de usuario, la dirección de acceso personalizada, la configuración de la identificación en dos pasos, las exclusiones de exploración y los destinatarios de los avisos adicionales. La opción «Restablecer valores por defecto» sigue estando disponible para empezar de cero.
• Corrección: Al aplicar un preajuste ya no se alteran las listas de perfiles. Los preajustes se superponían mediante una fusión que combinaba las listas posición a posición en lugar de sustituirlas, por lo que al aplicar «Estándar» sobre «Máximo», los dos perfiles cuyas contraseñas caducaban pasaban a ser cinco en «Máximo», sobrescribiéndose los dos primeros, y una lista vacía en un preajuste no vaciaba nada en absoluto.
• Corrección: El modo «Bajo ataque» ya no altera las listas de roles que hereda del preajuste «Máximo», por la misma razón que lo hacían los preajustes.
• Corrección: Restaurar los ajustes por defecto ya no desactiva XML-RPC por completo. Una nueva instalación solo bloquea los métodos de pingback, pero el botón «Restablecer» y la acción «Restablecer valores por defecto» dejaban el ajuste sin configurar, y «sin configurar» significa bloqueado por completo, por lo que los valores por defecto que se obtenían al pulsar el botón no eran los mismos que los de la instalación.
• Corrección: La comprobación de seguridad ya no indica que los sitios están en una lista negra cuando no es así. Las listas negras responden con un código reservado para indicar que rechazan la consulta, normalmente porque el servidor realiza la consulta a través de un sistema de resolución DNS público, y cualquier respuesta se interpretaba como una inclusión en la lista, por lo que se indicaba a los sitios que solicitaran una exclusión de una lista que no existía. Tampoco se consultan ya las direcciones privadas ni las reservadas.

2.9.7

• Mejorado: XML-RPC se traslada a la pestaña de refuerzo de WP, junto a los ajustes de pingback y trackback, con los que está relacionado, y se convierte en una opción única con tres opciones en lugar de dos casillas de verificación separadas en la de seguridad en el acceso, que podían marcarse al mismo tiempo y contradecirse entre sí. La búsqueda de ajustes ya apuntaba a la pestaña de refuerzo de WP para XML-RPC mientras que el ajuste en sí estaba en la de acceso, por lo que buscarlo llevaba a la pestaña incorrecta. Una nueva instalación ahora bloquea los métodos de pingback, que es la parte que se utiliza indebidamente para la propagación, y deja el resto accesible para que la aplicación de WordPress, Jetpack o un gestor remoto funcionen sin tener que tocar nada. Desactivar XML-RPC por completo sigue siendo la opción recomendada y está a un clic de distancia. Los ataques de fuerza bruta a través de XML-RPC siguen estando cubiertos, porque esos accesos pasan por el mismo bloqueo que cualquier otro. Los sitios que se actualizan mantienen exactamente lo que tenían, y la comprobación de seguridad resuelve el ajuste de la misma manera que lo hace el código que lo aplica.
• Mejorado: La búsqueda de ajustes ahora cubre todos los ajustes y sus palabras clave se pueden traducir. Era una lista escrita a mano que indexaba 68 de las 131 filas, por lo que buscar XML-RPC, contraseñas de aplicación, límites de sesión, caducidad de contraseñas o los ajustes de cabeceras no devolvía nada; y sus términos de búsqueda estaban codificados de forma fija, por lo que solo el inglés y el español encontraban algo por sinónimo. Ahora cada configuración regional puede proporcionar sus propios términos.
• Mejorado: La pestaña «Cabeceras de seguridad» ahora muestra Content Security Policy, HTTPS y HSTS seguidas, ya que las tres están relacionadas, y HSTS explica lo que realmente hace en lugar de repetir el texto de HTTPS. Su advertencia es la que realmente importa en el caso de HSTS: los navegadores la recuerdan durante todo el «max age», incluso si se desactiva más tarde, por lo que un sitio que pierda su certificado seguirá siendo inaccesible hasta que caduque. HSTS solo se puede activar en un sitio cuya dirección ya comience por https, ya que activarlo en cualquier otro sitio deja el sitio no disponible para todos los navegadores que lo respeten.

2.9.6

• Mejorado: La pestaña de cabeceras de seguridad ahora tiene una sección HTTPS con los tres ajustes que se ejecutaban sin forma de verlos o cambiarlos: redirigir HTTP a HTTPS, corregir contenido mixto y reescribir la dirección del sitio a https al activar. El último ahora está desactivado por defecto. Solía estar activado, por lo que al activar el plugin se reescribían la dirección de WordPress y la dirección del sitio a https sin preguntar y sin comprobar que el sitio respondía a través de HTTPS, lo que en un sitio publicado a través de HTTP lo dejaba apuntando a una dirección que podría no responder. La desactivación nunca lo deshacía. Ahora solo se ejecuta cuando está activado y la solicitud que activa el plugin es en sí misma a través de HTTPS. Los sitios cuyas direcciones ya fueron reescritas por una versión anterior las mantienen.
• Mejorado: Una casilla de verificación «Desactivar XML-RPC Pingback» en la pestaña de seguridad en el acceso, para sitios que necesitan el resto de XML-RPC para la aplicación móvil o Jetpack. El ajuste existía y funcionaba, pero no tenía ningún control en la interfaz.
• Mejorado: La redirección de HTTP a HTTPS ahora solo actúa en sitios cuya dirección ya es https://. En un sitio que aún se publica a través de HTTP enviaba cada solicitud a una dirección que podría no responder. Los sitios en HTTPS siguen redirigiendo exactamente igual que antes.
• Mejorado: El plugin ahora muestra el mismo nombre en la lista de plugins que en WordPress.org. Solo cambia el nombre mostrado, los ajustes, los datos y las actualizaciones no se ven afectados.
• Corrección: Las subidas de imágenes desde el editor vuelven a funcionar en WordPress 7.1 cuando la política de seguridad de contenido está activada. WordPress 7.1 procesa las imágenes en el navegador antes de subirlas y carga su motor WebAssembly desde una URL blob:, que está gobernada por la directiva connect-src. blob: faltaba allí, por lo que esa carga se bloqueaba. WordPress nunca lo notaba, porque su propia prueba de compatibilidad solo comprueba si los workers blob: están permitidos, lo que esta política ya permitía, por lo que seguía adelante de todos modos y la subida fallaba con un error que culpaba al formato del archivo. Se ha añadido blob: a connect-src en las políticas por defecto y máxima, y las advertencias de compatibilidad ahora comprueban también esa directiva. Informado por Antonio Cambronero.
• Corrección: Al guardar la pestaña de cabeceras de seguridad ya no se desactiva la redirección HTTPS y la corrección de contenido mixto, y al guardar la seguridad en el acceso ya no se desactiva el bloqueo de pingback de XML-RPC. Los ajustes sin un campo en su propio formulario se trataban como casillas de verificación sin marcar en cada guardado, por lo que al pulsar en guardar se desactivaban silenciosamente.
• Corrección: La integridad de archivos ya no informa de que los archivos del núcleo faltan permanentemente en sitios que no están en inglés. El manifiesto de sumas de comprobación localizado publicado por WordPress.org enumera los archivos de idioma de Akismet y de los temas por defecto, que no forman parte del núcleo y no viajan en el paquete de idioma del núcleo, por lo que eliminar un plugin o tema no utilizado, exactamente lo que recomienda la comprobación de seguridad, dejaba hallazgos que nunca se vaciaban.
• Corrección: La comprobación de seguridad ya no falla en su propia prueba REST /wp/v2/users/me en un sitio con ajustes de fábrica. Bloquear la enumeración de autores, que está activada por defecto, anula el registro de esa ruta, y una ruta que no existe responde con 404 en lugar del 401 que exigía la prueba. Un sitio correctamente protegido obtenía 97 de 100 puntos, y la única forma de recuperar los puntos era desactivar una protección real. La prueba hermana en /wp/v2/users ya aceptaba ese 404.
• Corrección: La prueba de contenido mixto ya no cuenta los enlaces normales a direcciones http://. Examinaba cada href de la página, por lo que un enlace saliente simple, o un enlace canónico o de feed, se informaba como contenido inseguro. Ahora solo se cuentan los recursos que la página realmente carga.
• Corrección: Los valores de las cabeceras se limpian de saltos de línea y comillas dobles antes de escribirse en .htaccess. Un salto de línea en un valor finalizaba la directiva y convertía el resto en configuración del servidor por sí mismo.
• Corrección: Al desinstalar el plugin ahora se eliminan las copias de seguridad que guardaba de wp-config.php y .htaccess. Esas copias se toman en la base de datos antes de que el plugin escriba en cualquiera de los dos archivos, y no estaban en la lista de desinstalación, por lo que una copia de wp-config.php, con las credenciales de la base de datos y los salts de identificación incluidos, permanecía en la tabla de opciones después de borrar el plugin. Los registros de copias de seguridad individuales y la caché del estado del plugin también se vacían.
• Corrección: Se han eliminado tres ajustes que ningún código leía nunca: dos que quedaban de versiones anteriores y uno detrás de una característica de cortafuegos que el readme describía pero que nunca se implementó en ninguna versión.

2.9.5

• Mejorado: El cron diario de caducidad de contraseñas ya no ejecuta una consulta a la base de datos por cada usuario. Al solicitar a WordPress únicamente los ID de usuario, la caché de usermeta queda vacía, por lo que cada comprobación de recordatorio volvía a la base de datos; ahora, todo el conjunto se prepara por adelantado. Los sitios con muchos usuarios en los perfiles afectados lo notarán durante la ejecución diaria de mantenimiento.
• Mejorado: La reescritura de contenido mixto ya no abre un búfer de salida en las solicitudes de administración, AJAX y REST. Solo reescribe documentos HTML completos, por lo que esas respuestas estaban consumiendo un búfer y una llamada de retorno que, de todos modos, las descartaba. En una web de WooCommerce, solo los fragmentos del carrito generaban docenas de ellas por visitante.
• Corrección: El limitador de frecuencia del cortafuegos ahora mide un intervalo real de 60 segundos. El contador de solicitudes renovaba su propio plazo de caducidad con cada acceso, por lo que el intervalo nunca se cerraba mientras seguía llegando tráfico y el límite dejó de significar «solicitudes por minuto»: pasó a ser «solicitudes desde el último minuto completo de inactividad». Los visitantes y editores autorizados quedaban bloqueados con un error 429 muy por debajo del límite configurado, y el problema se agravaba cuanto más tráfico tenía el sitio, ya que el recuento se realiza por IP y nunca se reiniciaba. Con el valor por defecto de 120 por minuto, un tráfico sostenido de 66 por minuto se bloqueaba a sí mismo tras 110 segundos. El problema afectaba con mayor intensidad en los casos en que varias personas compartían una misma dirección, como en una oficina o un CGNAT móvil, y sobre todo en sitios web detrás de una CDN sin ninguna cabecera de proxy declarada, donde todo el sitio se contabilizaba como un único visitante. Los contadores almacenados por versiones anteriores se descartan al actualizar.
• Corrección: La reescritura de contenido mixto ya no cierra un búfer de salida que no haya abierto. Al cerrarse solo comprobaba si había algún búfer abierto; por lo tanto, cuando otro plugin había abierto uno después de él y aún no lo había cerrado, se vaciaba ese búfer y el de Vigilante quedaba sin vaciar.
• Corrección: Los botones para activar y desactivar los módulos en la página de ajustes ahora tienen nombres accesibles. Un lector de pantalla los anunciaba como casillas de selección sin etiqueta, ya que el nombre del módulo se encontraba en un elemento fuera de la etiqueta del botón, lo que hacía que la lista de módulos (el control principal del plugin) resultara inutilizable para las personas con discapacidad visual.

2.9.4

• Corregido: Con una URL de acceso personalizada activa, bloquear el acceso al wp-admin oculto ya no muestra la plantilla 404 del tema desde dentro del hook «init». Cada solicitud bloqueada estaba pagando una representación completa de la página antes de que WordPress hubiera terminado de arrancar, con un coste equivalente a servir una página real, y llenaba debug.log con avisos de «llamada incorrecta» de componentes que esperan que «wp_loaded» se haya ejecutado primero (WooCommerce registraba uno por cada visita al carrito). La regresión llegó en la 2.9.3, cuando las cuatro rutas de bloqueo se unificaron en una única ayuda de 404. El wp-login.php oculto y el acceso directo /login todavía devuelven el 404 con la plantilla del tema, porque se ejecutan lo suficientemente tarde en la solicitud como para que sea seguro.
• Corregido: Ocultar wp-admin ya no devuelve 404 en las URL de la parte pública que simplemente contienen «wp-admin». La comprobación buscaba ese texto en cualquier parte de la solicitud, incluida la cadena de consulta, por lo que una entrada publicada en /wp-admin-tips/, un enlace como /?redirect_to=/wp-admin/ e incluso la propia pantalla de acceso oculta cuando su valor redirect_to no estaba codificado como URL se convertían todas en 404. Ahora solo se coincide con la ruta real de administración, y las exenciones de admin-ajax.php y admin-post.php también se coinciden en la ruta, por lo que una solicitud como /wp-admin/edit.php?x=admin-ajax.php ya no se cuela en el bloqueo. Los intentos de escáner en subdirectorios inexistentes como /blog/wp-admin/ se dejan al 404 propio de WordPress, por lo que ya no aparecen en el registro de actividad.

2.9.3

• Mejorado: Las listas blancas de direcciones IP y User-Agent del cortafuegos ahora también incluyen las protecciones a nivel de .htaccess (bloqueo de bots sospechosos, cadenas de consulta peligrosas, límites de métodos HTTP). Antes solo excluían el cortafuegos de PHP, por lo que un rastreador legítimo seguía recibiendo un error 403 directamente de Apache incluso después de haber sido incluido en la lista blanca. Las reglas se reescriben con condiciones de excepción cada vez que cambian las listas, respetando el ajuste de detección de la IP del visitante cuando el sitio declara una cabecera de proxy.
• Corrección: Ahora la función «Bloquear bots sospechosos» ya no devuelve un error 403 a los visitantes legítimos cuyo User-Agent contiene simplemente una palabra genérica breve. El token «rma» coincidía con el término «Performance», por lo que se bloqueaba la recuperación de páginas de WP Rocket («… for Performance Monitoring …») y Rocket Insights no podía añadir página s. Se han eliminado de la lista los términos rma, custo, disco, library, loader, extract, miner, scan y titan (los escáneres reales, como masscan, linkscan o sqlmap, siguen estando cubiertos por sus nombres completos), y el bloqueo del archivo .htaccess se actualiza automáticamente al actualizar el plugin.
• Corrección: El escáner de integridad de archivos ya no marca como sospechosos los archivos legítimos de plugins premium que leen un archivo local junto a la función unserialize(), como la importación/exportación de ajustes de SEOPress PRO o la caché de google/auth incluida con la pasarela de pago Redsys. Ahora, file_get_contents() solo se considera una señal de deserialización remota cuando hay un esquema de URL remota cerca de la llamada. Los paquetes descargados con wp_remote_get() o curl y posteriormente deserializados siguen detectándose.
• Corrección: La aprobación de un archivo de configuración crítico modificado (wp-config.php o .htaccess) ya no falla con un error genérico de AJAX a causa de cortafuegos de los alojamientos. Las reglas de los cortafuegos de aplicaciones web, como la OWASP CRS 930130, rechazan cualquier solicitud cuyo cuerpo contenga la cadena literal «wp-config.php», por lo que la solicitud de aprobación envía ahora una clave opaca que el servidor asocia con el archivo.
• Corrección: Los plugins premium que reutilizan un slug de carpeta abandonado en WordPress.org, como WPML (sitepress-multilingual-cms, que se cerró en wp.org cuando el plugin pasó a ser comercial), ya no se señalan como «cerrados» con una alerta crítica y un correo electrónico. Los slugs reutilizados conocidos y los plugins que declaran una URI de actualización externa se tratan como premium, al igual que cualquier otro plugin que nunca haya estado disponible en WordPress.org.
• Corrección: Cuando se utiliza una URL de inicio de sesión personalizada, al acceder a /login ya no se produce una redirección que revele la dirección oculta de acceso (WordPress convierte ese atajo en una redirección a la pantalla de inicio de sesión, ya reescrita con el slug secreto). Una solicitud POST anónima a /wp-admin provocaba una filtración de la misma forma a través de la redirección de identificación. Ahora, ambas devuelven el mismo error 404 que cualquier otro punto de entrada oculto.
• Corrección: La página 404 que se muestra al ocultar wp-login.php y la URL de inicio de sesión personalizada ahora utiliza la plantilla 404 del tema también en los temas de bloques. Los temas de bloques no tienen un archivo 404.php, por lo que esos sitios mostraban la página sencilla alternativa en lugar de la de su propio tema.
• Corrección: La función de corregir contenido mixto ahora también abarca los recursos externos en http://. La función de reescritura solo puede corregir las URL del mismo dominio, por lo que las imágenes, fuentes o scripts externos seguían provocando advertencias de contenido mixto. Ahora, la parte visible también envía la directiva Content-Security-Policy de solicitud de seguridad insegura, lo que hace que los navegadores carguen todas las peticiones adicionales con http:// a través de HTTPS, además de que la comprobación de seguridad reconoce dicha directiva en lugar de mostrar advertencias sobre referencias que el navegador ya actualiza.

2.9.2

• Mejorado: El aviso de detección de proxy/CDN ahora es descartable, y ya no se muestra en entornos de desarrollo local.

2.9.1

• Corrección: El escáner de integridad de archivos ya no genera falsas alertas de «código sospechoso» o «archivo inyectado» en temas y plugins legítimos (por ejemplo, el tema Astra). Ahora requiere que haya una llamada real a unserialize() junto a una solicitud remota antes de advertir sobre deserialización remota, en lugar de activarse cada vez que ambas simplemente aparezcan en algún lugar del mismo archivo, y compara los nombres de las funciones como tokens completos, por lo que los nombres seguros, como maybe_unserialize() y wpcom_vip_file_get_contents(), ya no se confunden con sus peligrosos homónimos.
• Corrección: Ya no se muestran falsas alertas de «archivo modificado» cuando un servidor o una herramienta de despliegue reescribe los finales de línea de un archivo (CRLF) o añade una marca de orden de bytes UTF-8 sin modificar el código. Ahora esos archivos se vuelven a comprobar con una copia normalizada antes de alertar, y los archivos ya publicados en WordPress.org se reconocen independientemente de las diferencias en los separadores de ruta.

2.9.0

• Nuevo: Vigilante ahora verifica cualquier plugin o tema comparándolo con los archivos oficiales de WordPress.org en el momento en que finaliza la actualización, en lugar de esperar a la siguiente comprobación programada. Si una actualización ha sido alterada, la discrepancia se detecta y se registra de inmediato.
• Mejorado: Las hojas de estilo (.css) quedan excluidas por defecto de la comprobación de integridad. Los temas y los plugins de optimización las reescriben constantemente, lo que solía provocar frecuentes alertas falsas de «archivo modificado» Los usuarios en modo estricto pueden volver a activar .css en los ajustes de exploración.
• Mejorado: El escáner detecta una técnica de ofuscación adicional utilizada por los plugins manipulados o «nulled», que consiste en descargar un payload remoto y deserializarlo.
• Corrección: La comprobación de integridad de archivos ya no muestra falsos positivos de archivos modificados o adicionales justo después de actualizar un plugin o un tema. Cuando WordPress.org publica varios checksums válidos para un archivo (algo habitual en versiones con etiquetas modificadas), ahora el archivo se compara con cada uno de ellos, y justo después de una actualización, Vigilante obtiene los checksums más recientes en lugar de reutilizar una copia almacenada en caché mientras WordPress.org aún estaba publicando la nueva versión. La verificación ahora también utiliza SHA-256 además de MD5.

Para entradas anteriores del registro de cambios revisa el archivo changelog.txt.