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

Registro de cambios

3.0.7

Las tareas programadas se ejecutan de nuevo cuando una tarea cron llama a wp-cron.php mediante su dirección. Al guardar en «Refuerzo de WP», ya no se daña el archivo wp-config.php que contiene una definición que ocupa varias líneas, y ya no se puede acceder al código PHP de las subidas de archivos mediante las tres formas que se saltaban la regla.

• Mejorado: La fila de la comprobación de seguridad relativa a wp-cron.php es meramente informativa y ya no suma puntos. Una solicitud a ese archivo solo ejecuta las tareas programadas que ya han caducado, por lo que es normal que wp-cron.php sea accesible. Cuando el servidor la rechaza, la fila indica que una tarea cron que llame a su dirección obtiene la misma respuesta. Un informe guardado antes de la actualización muestra esa fila sin puntos hasta el siguiente análisis. Con esta mejora, el total de la comprobación de seguridad es un punto menor.
• Corrección: «Proteger wp-cron.php» denegaba todas las solicitudes dirigidas a wp-cron.php, incluidas las tareas cron de un servidor que accedía a su dirección mediante wget, curl o el cron de un panel de alojamiento, y las tareas programadas dejaban de ejecutarse. La opción ha sido retirada y Vigilante retira su regla del archivo .htaccess cuando reescribe sus reglas tras la actualización. Si el archivo no se puede reescribir, la fila de «Comprobación de seguridad» relativa a wp-cron.php indica que el servidor lo rechaza. Las tareas cron que ejecutan wp-cron.php con PHP nunca se vieron afectadas y, en esos sitios, se puede volver a acceder a wp-cron.php, lo que solo permite a cualquiera ejecutar las tareas que ya están programadas.
• Corrección: La función «Bloquear bots sospechosos» bloqueaba una tarea programada que llamaba a wp-cron.php mediante wget (en el archivo .htaccess) o mediante curl, por lo que, en un servidor configurado de esa manera, las tareas programadas no se ejecutaban. Ahora, esa lista permite el paso de las solicitudes dirigidas a wp-cron.php. El resto de reglas del cortafuegos siguen aplicándose a dichas solicitudes.
• Corrección: Con el módulo «Cortafuegos» desactivado, el bloque de Vigilante del archivo .htaccess mantenía vigentes las reglas del cortafuegos: bots peligrosos, cadenas de consulta sospechosas, métodos HTTP, wp-config.php, archivos sensibles, listado de directorios y código PHP en las carpetas «uploads», «wp-includes», «plugins» y «themes». Ahora solo aplica las reglas de «Identidad del servidor» de la pestaña «Cabeceras de seguridad» mientras estas estén activadas, y desaparece cuando ambas están desactivadas. En los sitios en los que el módulo está desactivado, el bloque se reescribe al actualizar.
• Corrección: Al importar ajustes con el módulo «Cortafuegos» desactivado, se eliminaba ese bloque de .htaccess incluso cuando las opciones «Firma del servidor» o «Quitar cabeceras de huellas digitales» lo requerían, y al desactivar y volver a activar Vigilante, tampoco se incluía en ese mismo caso. Ahora, la actualización tras una actualización también elimina un bloque que nadie solicita, al igual que ocurre al guardar.
• Corrección: En las instalaciones de WordPress en una subcarpeta o en una red mediante subdirectorios, una Content Security Policy restrictiva también afectaba al panel de administración, ya que la excepción correspondiente solo se aplicaba a /wp-admin en la raíz del dominio. Ahora se aplica a /wp-admin como carpeta en cualquier parte de la dirección, y ya no afecta a las direcciones de raíz que simplemente empiezan por /wp-admin, como /wp-admin-tips/.
• Corrección: En PHP 8, con la característica «Bajo ataque» activada, un visitante podía provocar un error fatal en la página de desafío enviando su campo de redirección en forma de lista, y lo mismo ocurría con redirect_to cuando se iniciaba un inicio de sesión con identificación en dos pasos Ahora ambos son de solo lectura como texto.
• Corrección: Cuando el bloque de WordPress del archivo .htaccess había perdido la línea END, el aviso y la entrada del registro indicaban que un bloque de Vigilante no funcionaba correctamente. Ahora mencionan el bloque de WordPress.
• Corrección: Al guardar la pestaña «Refuerzo WP» con un define() de wp-config.php escrito en varias líneas, como WP_DEBUG, solo se comentaba la primera línea y se dejaba el archivo con un error de sintaxis que provocaba la caída del sitio. Ahora se comentan todas las líneas. Se deja tal cual cualquier define() que comparta línea con otro código, y Vigilante nunca escribe en wp-config.php a menos que el resultado sea código PHP válido.
• Corrección: Al guardar en «Refuerzo de WP» se comentaban las constantes del propietario que gestiona Vigilante, como DISALLOW_FILE_MODS, DISABLE_WP_CRON, FORCE_SSL_ADMIN o WP_DEBUG_LOG, incluso cuando su ajuste estaba desactivado, por lo que dejaban de aplicarse sin que hubiera nada en su lugar. Ahora solo se comentan las constantes que define el bloque de Vigilante. En los casos en los que esto ya había ocurrido, vuelven a aparecer la próxima vez que se guarde esa pestaña.
• Corrección: Vigilante escribía en wp-config.php hasta cuatro veces seguidas para aplicar esos ajustes, por lo que, si se producía un error a mitad del proceso, el archivo quedaba modificado. Ahora prepara todo el cambio, escribe el archivo una sola vez con un bloqueo y lo vuelve a leer; si la operación de escritura se interrumpe, restaura el contenido anterior.
• Corrección: La regla que bloquea PHP en las subidas podía eludirse de tres formas: una ruta tras el nombre del archivo (file.php/loquesea) ejecutaba el archivo; otra variante de mayúsculas y minúsculas (file.PHP) mostraba su código fuente o lo ejecutaba, dependiendo del servidor; y un archivo .htaccess con sus propias reglas de rewrite en una carpeta de subidas (que escriben los plugins de imágenes) desactivaba la regla por debajo de él. En Apache 2.4, ahora funciona correctamente en los tres casos, y también cubre las extensiones .php7, .php8 y .phps. El aviso de integridad de archivos sobre ese archivo .htaccess indica ahora que solo desactiva la regla fuera de Apache 2.4.
• Corrección: Cada vez que Vigilante generaba sus reglas .htaccess, eliminaba los bloques denominados # BEGIN SECURITY HEADERS, # BEGIN 8G FIREWALL y # BEGIN ADDITIONAL PROTECTIONS, al considerarlos restos de una versión anterior. Ninguna versión de Vigilante los generaba: suelen ser reglas copiadas de una guía o creadas por otro plugin, y ahora se mantienen.
• Corrección: Al activar o desactivar la opción «Bajo ataqie», en «Integridad de archivos» se mostraba un cambio en el archivo .htaccess, y no se comprobaba si faltaba un marcador en dicho bloque antes de que Vigilante escribiera ese archivo.

3.0.6

Ahora Vigilante te avisa cuando no puede escribir en wp-config.php o en .htaccess. Hasta ahora, al guardar se indicaba que los ajustes se habían guardado, aunque las constantes o las reglas del servidor nunca llegaran al archivo.

• Mejorado: La sección «wp-config.php» de la pestaña de refuerzo de WordPress indica cuándo ese archivo no tiene permisos de escritura o se encuentra en una carpeta situada un nivel por encima de WordPress, donde Vigilante no tiene permisos para escribirlo, mientras esa situación se mantenga. Aparece en color ámbar cuando todos los ajustes solicitados ya están activos, y en rojo, indicando las constantes que faltan o sobran, cuando no es así. El aviso se actualiza tras cada guardado, sin necesidad de recargar la página.
• Mejorado: La sección de protección del servidor de la pestaña «Cortafuegos» y la pestaña «Cabeceras de seguridad» indican cuándo el archivo .htaccess no tiene permisos de escritura en un servidor que utilice el archivo.
• Mejorado: Aunque wp-config.php no se puede modificar y, por ello, algunos de los ajustes de refuerzo de WordPress no estén activos, el escritorio recomienda revisarlo e indica las constantes que no se aplican.
• Mejorado: El aviso sobre los usuarios pendientes de aprobación ya no muestra a todos y cada uno de ellos en cada pantalla de administración solo para contarlos.
• Mejorado: Un sitio web que mantenga a propósito los archivos wp-config.php o .htaccess como de solo lectura también mostrará estos avisos, en esas secciones y tras guardar esas pestañas. Allí también resultan válidos: ningún cambio realizado en esas pestañas se aplica al archivo hasta que se pueda escribir en él.
• Corrección: cuando no se podía escribir en el archivo wp-config.php, al guardar la pestaña de refuerzo de WordPress, o al cambiar los ajustes de un módulo, se indicaba que estos se habían guardado, pero las constantes nunca llegaban al archivo y no se mostraba ningún aviso al respecto. Al activar el plugin con el archivo sin permisos de escritura, la situación seguía igual. Ahora, al guardar, aparece un segundo aviso junto al habitual, que permanece en pantalla e indica las constantes que no se han aplicado. Al guardar esa pestaña sin que quede nada por escribir, sigue indicando que el archivo no tiene permisos de escritura. Y cuando al cambiar los ajustes de un módulo queda algo sin escribir, la página ya no se recarga, por lo que se puede leer el aviso.
• Corrección: ocurría lo mismo con el archivo .htaccess. Al guardar la pestaña de cortafuegos o de cabeceras de seguridad, o al activar o desactivar uno de esos dos módulos, si el archivo .htaccess no tiene permisos de escritura, ahora aparece un mensaje indicando que las reglas del servidor no se han actualizado. También aparece ese mensaje, junto con el motivo, cuando Vigilante deja el archivo tal y como está por otra causa, como por ejemplo que uno de sus bloques haya perdido un marcador.
• Corrección: La descripción del preajuste «Máximo» indicaba que su Content Security Policy estaba configurada en modo de solo informar. El preajuste la aplica, y ahora la descripción lo indica así.
• Corrección: El botón «Probar cabeceras» no mostraba ningún mensaje cuando la solicitud fallaba por completo. Ahora muestra un error.

3.0.5

El escritorio muestra solo una calificación, la de «Comprobación de seguridad» en una escala más estricta. Solo tiene en cuenta una configuración mientras su módulo está activo y omite lo que no ha podido medir, por lo que algunas puntuaciones bajan. El aviso sobre las tareas programadas ya no indica que se hayan modificado archivos.

• Mejorado: El escritorio muestra una sola calificación. La «Comprobación de seguridad», que evalúa el sitio, mantiene su letra y ahora aparece primera. Lo que antes era la puntuación de configuración ahora es la «Configuración de Vigilante»: una barra con un porcentaje y sin letra, junto a las recomendaciones y los módulos que tiene en cuenta. Dos letras una al lado de la otra se interpretaban como dos calificaciones del mismo sitio que no coincidían.
• Mejorado: La comprobación de seguridad y cada una de sus categorías utilizan ahora una escala de letras más estricta: la A corresponde a una puntuación perfecta, la B empieza en 85, la C en 70, la D en 50 y la E corresponde a cualquier puntuación inferior. Hasta ahora, la B iba de 70 a 99, por lo que un sitio con muchas comprobaciones fallidas se quedaba a solo una letra de la puntuación perfecta. Las puntuaciones numéricas no cambian con este cambio, pero muchos sitios obtendrán una letra más baja.
• Mejorado: La comprobación de seguridad deja fuera de la puntuación las comprobaciones que no se han podido ejecutar e indica cuántas no se han evaluado. Hasta ahora, estas comprobaciones se contabilizaban como un cero, por lo que una solicitud a tu propio sitio que agotaba el tiempo de espera reducía la puntuación como si la comprobación hubiera fallado, y el resultado variaba de un análisis a otro. Una comprobación que es meramente informativa, como una cabecera desactivada a propósito, ya no impide que la puntuación alcance los 100 puntos.
• Mejorado: El porcentaje de la configuración de Vigilante se calcula sobre el mismo total en cada sitio, y un módulo que se desactiva pierde sus puntos y los puntos de sus ajustes. Hasta ahora, esos ajustes también se restaban del total, por lo que un sitio con la mayoría de los módulos desactivados mantenía una cifra media, y al desactivar la auditoría de seguridad sin ninguna alerta configurada, esta cifra aumentaba. Los sitios con módulos desactivados mostrarán un porcentaje más bajo.
• Mejorado: La fila del tema activo de la comprobación de seguridad es meramente informativa y ya no da 5 puntos. El hecho de que el tema tenga una actualización pendiente ya se tiene en cuenta en otra comprobación. Esto puede hacer que la puntuación varíe en uno o dos puntos.
• Mejorado: La comprobación de seguridad indica cuándo llega al navegador una cabecera de seguridad procedente de un bloque de Vigilante en el archivo .htaccess de una carpeta situada por encima del sitio, que es lo que ocurre con un WordPress instalado en una subcarpeta de otro. Hasta ahora, solo lo indicaba la comprobación de Content-Security-Policy.
• Mejorado: Cuando Vigilante detecta que ha desaparecido una de sus tareas programadas y la vuelve a programar, la segunda vez en 30 días ahora se considera una advertencia, sin envío de correo electrónico ni repercusión en las puntuaciones, y desaparece por sí sola tras una semana sin que falte ninguna tarea. Solo se convierte en crítica, con un correo electrónico a la semana como máximo, a partir de la tercera vez en una semana o la cuarta en 30 días. Hasta ahora, la segunda vez ya era crítica: ambas puntuaciones bajaban a E y el aviso permanecía durante 30 días independientemente de lo que se hiciera. El propio WordPress descarta una tarea programada cuando no puede guardar su próxima ejecución, por lo que dos en un mes no significa que algo las esté eliminando.
• Mejorado: La tarea horaria de Vigilante ya no se supervisa. No hace nada y, al ser cada hora, era la que se perdía con más frecuencia.
• Mejorado: Vigilante ya no espera a que un administrador abra el escritorio para volver a programar una tarea que ha desaparecido: también comprueba las tareas programadas del propio WordPress, que se ejecutan dos veces al día. Hasta ahora, cuando se eliminaba la tarea de mantenimiento diario, esta seguía sin aparecer y nada supervisaba las demás hasta que un administrador se ocupaba de ello.
• Mejorado: Los pasos que se indican en el aviso sobre las tareas programadas explican primero que Vigilante ha vuelto a programar las tareas, a continuación indican qué hay que comprobar y, por último, señalan una posible causa en caso de que el problema se repita.
• Corrección: La comprobación de seguridad superaba las verificaciones de un ajuste que se había guardado mientras el módulo que lo aplica estaba desactivado, por lo que la protección no estaba en funcionamiento: la URL de acceso personalizada, el límite de intentos de acceso, la identificación en dos pasos, XML-RPC, RSD, Windows Live Writer y las etiquetas de enlaces cortos, así como las comprobaciones que leían «Auditoría de seguridad» e «Integridad de archivos». Con el módulo «Cabeceras de seguridad» desactivado las comprobaciones de Content-Security-Policy y HSTS indicaban que algo estaba eliminando la cabecera y daban la mitad de los puntos. Ahora fallan e indican el módulo que está desactivado. Los sitios con módulos desactivados obtendrán una puntuación más baja, y el análisis semanal (en el que el envío de correos electrónicos está activado) informará de las comprobaciones que empiezan a fallar.
• Corrección: El botón «Probar cabeceras» calificaba los ajustes de su pestaña sin solicitar nada al sitio, por lo que podía mostrar una «B» aunque ninguna cabecera llegara al navegador. Ahora mide lo que llega, con las comprobaciones y la escala de la comprobación de seguridad. Además, la comprobación de seguridad indica cuándo una cabecera está activada en Vigilante pero no llega, junto con la causa probable, y no le da ningún punto.
• Corrección: Tres textos de la comprobación de seguridad que podían malinterpretarse. La comprobación de /wp-admin/ indicaba que se redirigía a los visitantes a la página de acceso independientemente del tipo de redirección. Las dos comprobaciones de usuarios a través de la API REST tenían nombres casi idénticos: una corresponde a la lista de usuarios, mientras que la otra solo indica al visitante quiénes son. WordPress responde a esta última con un código 401 en cualquier sitio, por lo que ahora es meramente informativa y ya no otorga 2 puntos. Además, un único usuario se contabilizaba como 1 registro de usuario.
• Corrección: La comprobación de seguridad consideraba que un administrador estaba protegido por la identificación en dos pasos cuando dicho perfil no estaba entre los obligatorios o la cuenta estaba entre los usuarios excluidos.
• Corrección: La comprobación de seguridad daba por buenas las comprobaciones relativas a los archivos expuestos (.env, .git/config, debug.log, copias de wp-config.php, scripts de desarrollo y wp-cron.php) cuando la solicitud que enviaba al sitio no obtenía respuesta. Ahora se muestran como no medidas.
• Corrección: La comprobación de permisos de archivos de la comprobación de seguridad lee el archivo wp-config.php cuando está en una carpeta por encima de WordPress, y te lo dice cuando no la encuentra, en vez de darlo por válido.
• Corrección: En el escritorio, al cambiar un módulo se guardaba el cambio dos veces y mostraba momentáneamente una puntuación diferente a la que aparece en la página una vez recargada.
• Corrección: En la comprobación de seguridad la barra de cada categoría mantiene su color después de la exploración hasta que se recargue la página.
• Corrección: Cuando el aviso crítico se refería a las tareas programadas, el correo electrónico, la caja de «Integridad de los archivos», el aviso de administración, la recomendación del escritorio y la nota sobre las puntuaciones indicaban que los archivos de Vigilante habían sido modificados, aunque todos los archivos estaban intactos. Ahora indican que las tareas programadas siguen siendo eliminadas, cuentan las tareas en lugar de los archivos y ya no solicitan una reparación ni una nueva exploración, que no aclaraba nada.
• Corrección: Cuando se eliminaban los ganchos de la autoprotección de Vigilante, el correo electrónico, la caja de «Integridad de archivos», el aviso de administración, la recomendación del escritorio y la nota sobre las puntuaciones indicaban que los archivos de Vigilante habían sido modificados; y, al desactivarse la autoprotección mediante código, lo mismo ocurría con el correo electrónico y la nota sobre las puntuaciones. Ahora indican lo que se ha detectado. Con la autoprotección desactivada por código, el escritorio también pedía que se activara, algo que ningún ajuste permite: ahora indica que algo en el sitio la ha desactivado y dónde buscar.
• Corrección: Cuando WordPress actualizaba Vigilante en segundo plano y el mantenimiento diario de Vigilante vencía en esa misma ejecución, Vigilante interpretaba la actualización como un cambio de versión realizado fuera del programa de actualizaciones, lo registraba como tal y podía enviar un correo electrónico de aviso. Ahora espera a la comprobación que se realiza al final de cada actualización, al igual que el resto de comprobaciones, mientras WordPress ejecuta sus actualizaciones en segundo plano en otro proceso. Las actualizaciones se gestionan según la versión que se va a sustituir, por lo que este cambio entrará en vigor a partir de la actualización siguiente a esta.
• Corrección: La herramienta de integridad de archivos señalaba como sospechosa una llamada a la antigua función de PHP que crea una función a partir de una cadena, cuando dicha llamada solo aparecía dentro de un comentario, donde los plugins la dejan junto al código que la sustituyó. Ya no se busca esa llamada en los comentarios, y se informa de las llamadas activas como antes.

3.0.4

Corrige el aviso de contraseña caducada, que no aparecía cuando la contraseña caducaba durante una sesión abierta. Ahora lleva al usuario a la parte superior del perfil, donde se está el aviso. También arregla un bucle de redirección para los clientes en WooCommerce, y limita el acceso de una cuenta con contraseña caducada a su propio formulario de perfil.

• Mejorado: Cuando una contraseña ha caducado se redirige al usuario a la parte superior de su perfil, donde aparece un aviso explicando el motivo, en lugar de llevarlo directamente al campo de la contraseña, con el aviso oculto justo encima. El aviso incluye ahora un enlace al campo.
• Corrección: Faltaba el aviso de que una contraseña había caducado cuando vencía mientras el usuario seguía conectado. Se redirigía al usuario a su perfil sin ninguna explicación, y el aviso solo aparecía tras volver a iniciar sesión.
• Corrección: El último día antes de que caducara una contraseña no se mostraba el aviso, por lo que el cambio obligatorio se producía sin previo aviso el día anterior.
• Corrección: En una tienda con WooCommerce, una cuenta sin acceso al área de administración (por ejemplo, la de un cliente) cuyo perfil está en la lista de «Perfiles afectados» quedaba atrapada en un bucle de redirección cuando caducaba su contraseña. WooCommerce le redirigía desde el perfil a «Mi cuenta» y Vigilante le devolvía, por lo que no podía ni utilizar la tienda ni cambiar la contraseña. Ahora, a esa cuenta se le permite acceder a la pantalla de su perfil en el área de administración mientras el cambio está pendiente, y solo a esa pantalla. La contraseña se cambia allí, no en «Mi cuenta», y, una vez guardada, WooCommerce devuelve la cuenta a «Mi cuenta» como de costumbre.
• Corrección: Cuando había un cambio de contraseña pendiente se permitía el acceso a todas las solicitudes dirigidas a la pantalla de perfil, y desde esa pantalla se puede acceder a otros elementos: una página de plugins, un importador, una acción pasada en la dirección o el perfil de otro usuario en el caso de una cuenta con permiso para editar usuarios. Una cuenta con una contraseña caducada podía seguir utilizando esas funciones. Ahora solo se permite el acceso a su propio formulario de perfil, ya sea para visualizarlo o para guardarlo. En una red, las pantallas de perfil del administrador de la red y del escritorio del usuario conducen al perfil del sitio, donde se encuentra el aviso.
• Corrección: En un sitio cuya dirección de WordPress y dirección del sitio estén en servidores diferentes (por ejemplo, un sitio «headless») o cuya dirección contenga letras acentuadas o no latinas tal y como están escritas, un usuario con una contraseña caducada quedaba atrapado en un bucle de redirección. La redirección al perfil se trataba como una redirección al escritorio, lo que enviaba al usuario de nuevo al perfil. Ahora se accede correctamente al perfil.

3.0.3

Integridad de archivos ahora compara los temas con su paquete de WordPress.org, busca en todo el código que no tiene copia oficial y examina los plugins must-use, los drop-ins, wp-admin, wp-includes y el resto de wp-content. Los correos electrónicos del análisis se envían una vez por cada hallazgo nuevo.

• Mejorado: Integridad de archivos compara los temas de WordPress.org con el paquete que WordPress.org publica para la versión instalada. WordPress.org no tiene sumas de comprobación para los temas, así que hasta ahora ningún archivo de tema se comparaba con nada. El paquete se descarga una vez por versión.
• Mejorado: la integridad de archivos busca código oculto en todos los archivos PHP de un plugin o tema sin copia oficial, no solo en los primeros 50, y lee archivos de hasta 8 MB. Un archivo de más de 512.000 bytes no se abría, así que pasaba como limpio. Uno de más de 8 MB se lista como no analizado.
• Mejorado: la integridad de archivos examina los archivos añadidos a wp-admin y wp-includes, los plugins imprescindibles y los drop-ins, los archivos PHP sueltos en wp-content, y las carpetas con PHP entre los plugins o los temas que WordPress no lista como tal.
• Mejorado: la integridad de archivos busca código oculto en los archivos PHP de las demás carpetas de wp-content (languages, upgrade y similares). Un archivo de traducción que contenga algo distinto de texto se reporta, porque WordPress carga los archivos de traducción en cada solicitud.
• Mejorado: una instalación nueva ya no empieza con wp-content/cache entre las rutas excluidas, así que esa carpeta también se analiza. Un sitio que ya la tenga ahí la conserva.
• Mejorado: la integridad de archivos informa de un .htaccess, .user.ini o php.ini fuera de uploads que hace que el servidor ejecute código o cargue un archivo.
• Mejorado: la integridad de archivos encuentra, en código sin copia oficial, datos de la solicitud ejecutados como código o como comando, una función elegida por la solicitud y un archivo incluido desde otro servidor. No se informa del mismo texto en un comentario.
• Mejora: un archivo en el que la búsqueda de código oculto no puede terminar se lista como no analizado en lugar de pasar como limpio.
• Mejorado: la itegridad de archivos ahora compara wp-includes/version.php, y compara los sitios que no están en inglés con las sumas de comprobación en inglés mientras WordPress.org no tiene ninguna para su idioma, en lugar de dejar el núcleo sin comprobar.
• Mejorado: la integridad de archivos informa de los archivos borrados de un plugin o un tema, e informa de una solicitud fallida a WordPress.org como un error en lugar de tratar el plugin como uno sin copia oficial.
• Mejorado: la integridad de archivos informa de más tipos de archivo en la carpeta de subidas (.pht, .php8, nombres como shell.php.suspected, .user.ini, php.ini, scripts de shell y CGI), un .user.ini o php.ini en la raíz del sitio que carga un archivo en cada solicitud, además de copias de seguridad dejadas en la raíz del sitio.
• Mejora: la pestaña Integridad de archivos indica qué suele ser cada tipo de hallazgo y qué hacer al respecto, nombra los plugins y temas que no se han podido comparar, y dice cuándo un análisis fue parcial en lugar de decir que todos los archivos pasaron.
• Mejora: cuando un análisis agota el tiempo, Integridad de archivos y el correo electrónico del análisis nombran los plugins, los temas y las áreas a las que no llegó, e Integridad de archivos lista las carpetas que excluir para que un análisis manual llegue al resto. Un análisis se ejecuta durante 60 segundos como máximo y empieza desde el principio cada vez, así que en un sitio muy grande la misma parte se queda sin comprobar en cada análisis.
• Mejorado: la integridad de archivos y la comprobación de seguridad indican cuándo las rutas excluidas contienen la carpeta entera de un plugin o de un tema, o la carpeta de subidas. Ninguna exploración mira dentro de ellas, y la comprobación de seguridad ya no cuenta un análisis así como limpio.
• Mejorado: La integridad de archivos y la comprobación de seguridad indican cuándo ningún análisis programado ha terminado durante más tiempo del que permite la programación. Una epxloración que el servidor detiene a medias no guarda ningún resultado, y tampoco uno que WordPress nunca inicia, así que el último que sí terminó seguía mostrándose como el actual.
• Mejora: el correo electrónico del análisis se envía cuando un análisis encuentra algo nuevo, no después de cada análisis, y su asunto nombra wp-config.php o .htaccess cuando eso es todo lo que ha cambiado.
• Mejora: los eventos de dos factores se pueden filtrar en la auditoría de seguridad, y PHP 8.5 está en la tabla de fin de vida útil de la comprobación de seguridad.
• Corrección: un .htaccess en uploads que solo deniega el acceso ya no se reporta, y tampoco la regla que prohíbe PHP ni una línea comentada. Options +ExecCGI y los manejadores CGI o SSI, que se listaban como reglas personalizadas, ahora son sospechosos.
• Corrección: el archivo index.php de dos líneas que incluye WordPress ya no se reporta como PHP en uploads ni como archivo adicional.
• Corrección: los temas incluidos y Akismet ya no aparecen como archivos del núcleo modificados o faltantes cuando se actualizan o se eliminan.
• Corrección: una cadena hexadecimal de unos 12.000 caracteres o más no era encontrada por la búsqueda de código oculto. Cuanto más largo era el contenido, menos se encontraba.
• Corrección: un nombre de función dividido en trozos no se encontraba cuando una cadena larga de cadenas unidas venía antes en el archivo.
• Corrección: un archivo creado a propósito podía mantener ocupada la búsqueda de código oculto el tiempo suficiente para acortar el análisis.
• Corrección: el análisis de la carpeta de subidas se detenía después de 10.000 archivos sin avisar.
• Corrección: una carpeta que el análisis no podía leer detenía el análisis de uploads, de un plugin o de un tema sin decirlo, y no se comprobaba nada después. Ahora el análisis continúa e informa de la carpeta.
• Corrección: la exploración manual solo guardaba la segunda mitad del análisis en el historial de puntuaciones de la comprobación de seguridad.
• Corrección: la comprobación de seguridad daba por válido un análisis de integridad de archivos que no lo había comprobado todo, siempre que no hubiera encontrado nada en lo que sí comprobó.
• Corrección: la etiqueta Limitar métodos HTTP, y el comentario escrito en .htaccess, describían una regla que no es la que se aplica.
• Corrección: el ajuste de alertas de la auditoría de seguridad decía que un administrador nuevo se registra como crítico. Se registra como advertencia, y tiene su propio correo electrónico en «Usuarios».
• Corrección: el readme describía copias de seguridad automáticas de .htaccess y wp-config.php que ya no existen.
• Corrección: se han eliminado 11 cadenas y un método que nada usaba.

3.0.2

Corrige las direcciones con acentos o letras no latinas en la redirección HTTPS, la comprobación del modo bajo ataque y una dirección de acceso personalizada; evita que el alias www lleve al escritorio, guarda las rutas de integridad de archivos tal y como se han escrito, y evita que la CSP por defecto altere los estilos de los sitios servidos a través de HTTP.

• Corrección: La redirección de HTTP a HTTPS conserva los caracteres codificados en porcentaje de la dirección. Una visita a /categor%C3%ADa/ se redirigió a /categora/, lo que provocaba un error 404, una ruta en cirílico se redirigía a //, y todos los parámetros perdían sus caracteres codificados.
• Corrección: La misma redirección toma el host declarado por el sitio, no de la cabecera «Host». Al visitar el alias «www» del sitio, o el servidor mediante su dirección IP, se enviaba una redirección permanente al escritorio en lugar de a la misma página. Un sitio que servía otros nombres de host propios a través de allowed_redirect_hosts ahora obtiene el host declarado para todos ellos, mientras que el área de administración de un sitio cuyo WordPress se aloja en un host propio permanece en ese host.
• Corrección: Una dirección de acceso oculta escrita en un alfabeto no latino no encontraba nada, así que la página de acceso permanecía oculta y su propia dirección devolvía un error 404. Ahora se compara en mayúsculas y minúsculas, en formato hexadecimal y como UTF-8 sin codificar. Una dirección que solo coincidía tras eliminar sus caracteres codificados, como /my-log%41in/ para /my-login/, ya no abre la página de acceso.
• Corrección: Tras resolver el reto en el modo «Bajo ataque», el visitante accede a la página que ha solicitado, con los acentos y los parámetros intactos.
• Corrección: El registro de actividad conserva la dirección de una solicitud bloqueada tal y como se envió, en lugar de borrar los caracteres codificados.
• Corrección: Ahora funciona la opción de ignorar en «Integridad de archivos» un archivo cuyo nombre contenga caracteres codificados (por ejemplo, un %20 literal) o espacios repetidos. La ruta se guardaba sin esos caracteres, por lo que nunca coincidía con el archivo y la advertencia volvía a aparecer; además, la entrada guardada podía coincidir con otro archivo cuyo nombre estuviera alterado.
• Corrección: Una ruta excluida en «Integridad de archivos» cuyo nombre contenga caracteres codificados (por ejemplo, un %20 literal) o espacios repetidos ahora se guarda tal y como se ha escrito, incluso al exportar e importar los ajustes. Antes se guardaba tras eliminar dichos caracteres, por lo que nunca coincidía. Además, cuando los caracteres codificados formaban parte del final del nombre, se guardaba como la carpeta superior, lo que impedía que se analizara todo el contenido de dicha carpeta. Ahora se omite cualquier línea que contenga etiquetas HTML. Las entradas ya guardadas no se modifican, por lo que aquellas que se guardaron recortadas deben volver a escribirse.
• Corrección: El área de administración y sus URLs abiertas se reconocen a partir de la ruta tal y como se envía. Ya no se interpreta /wp-admin/admin-ajax.php%20 como admin-ajax.php, ni /wp-%41admin/page como una página del área de administración.
• Corrección: En un sitio cuya dirección es http://, la directiva Content-Security-Policy por defecto ya no incluye upgrade-insecure-requests. Con Apache y el módulo de cabeceras activos, esa directiva hacía que los navegadores solicitaran todas las hojas de estilo, scripts e imágenes a través de HTTPS, a lo que el sitio no respondía, por lo que el sitio perdía sus estilos. Ahora la directiva solo se aplica cuando la dirección del sitio es https://, por lo que un sitio servido a través de HTTPS mediante un proxy o una CDN que termine el TLS debería tener su dirección configurada como https://. Las reglas se reescriben al actualizar, por lo que un sitio que ya se viera afectado se recupera al actualizar, y la pestaña «Cabeceras de seguridad» lo indica junto a la política.
• Corrección: El escritorio lee el ajuste de XML-RPC en su ubicación actual. La puntuación de configuración nunca daba los tres puntos por bloquear XML-RPC, y la recomendación de desactivarlo siempre aparecía, ya que ambas se basaban en una casilla de selección que dejó de guardarse a partir de la versión 2.9.7. Un sitio que bloquee XML-RPC, tal y como lo hacen los ajustes predeterminados, verá cómo su puntuación aumenta en dos o tres puntos sin cambiar nada, y la recomendación, cuando sea aplicable, ahora redirige a refuerzo de WP.
• Corrección: La tarjeta «Comprobación de seguridad» del escritorio indicaba que se habían realizado 13 comprobaciones internas, cuando en realidad son 16, y ya no muestra ninguna cifra.

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