PluginProbe
Vigilant – 100% Free Security Suite: Firewall, 2FA, Login, Headers, Scanner… / 2.11.12
Vigilant – 100% Free Security Suite: Firewall, 2FA, Login, Headers, Scanner… v2.11.12
3.0.0 2.11.12 2.11.11 2.11.10 2.11.9 2.11.7 2.11.8 2.11.6 2.11.5 2.11.4 2.11.3 2.11.1 2.11.2 2.11.0 2.10.5 2.10.4 2.10.3 2.10.2 2.10.1 2.10.0 2.9.9 2.9.8 2.9.6 2.9.7 2.9.5 All 88 releases
← All changes | includes/class-settings.php +937 -91 2.9.72.11.12 View file →
@@ -93,16 +93,17 @@
93 93 // Proxy / CDN: forwarded header to trust for the visitor IP.
94 94 // Empty = trust only REMOTE_ADDR (the real connection, unspoofable).
95 95 'trusted_proxy_header' => '',
96 96
97 + // Proxy / CDN: IPs or CIDR ranges the forwarded header is accepted
98 + // from. Empty = accept it only from your own network, and, for
99 + // CF-Connecting-IP, Cloudflare's own ranges. Since 2.11.9, so a
100 + // header cannot be forged by a visitor reaching the origin directly.
101 + 'trusted_proxies' => array(),
102 +
97 103 // User-Agent management
98 104 'ua_whitelist' => array(),
99 105 'ua_blacklist' => array(),
100 - 'country_blocking' => array(
101 - 'enabled' => false,
102 - 'mode' => 'blacklist',
103 - 'countries' => array(),
104 - ),
105 106
106 107 // File protection (htaccess-based)
107 108 'disable_directory_browsing' => true,
108 109 'protect_wp_config' => true,
@@ -116,12 +117,8 @@
116 117 'block_php_in_themes' => false,
117 118 'limit_http_methods' => true,
118 119 // All methods needed for WordPress core, Gutenberg, REST API, and page builders
119 120 'allowed_http_methods' => array( 'GET', 'POST', 'HEAD', 'OPTIONS', 'PUT', 'PATCH', 'DELETE' ),
120 - 'protected_file_extensions' => array(
121 - 'htaccess', 'htpasswd', 'ini', 'log', 'sql',
122 - 'bak', 'old', 'tmp', 'swp', 'save', 'backup'
123 - ),
124 121 ),
125 122
126 123 // Security Headers settings (includes HTTPS enforcer)
127 124 'security_headers' => array(
@@ -192,10 +189,33 @@
192 189 // an address that does not answer. It is an opt-in decision per
193 190 // site, made from the Security Headers tab. Sites whose URLs a
194 191 // previous version already rewrote keep them; nothing reverts them.
195 192 'force_https' => false,
196 - 'redirect_http_to_https' => true,
197 - 'fix_mixed_content' => true,
193 + // Off by default for the same reason as force_https above: the
194 + // plugin does not decide that a site is on HTTPS. It only
195 + // redirects when the site's own home URL already says https, so
196 + // shipping it on was harmless in practice, but it is still a
197 + // decision that belongs to the site owner, not to us. Sites that
198 + // already have it on keep it.
199 + 'redirect_http_to_https' => false,
200 + // Rewrites http:// URLs of this same site to https://, and only
201 + // on a site already served over HTTPS, so it cannot reach a third
202 + // party and cannot make a resource fail. It still ships off: a
203 + // setting whose own description says it rewrites http to https
204 + // does not belong in the factory configuration of a plugin that
205 + // deliberately does not decide whether a site is on HTTPS. Every
206 + // https-related setting here is the owner's call, and this one is
207 + // one click away for anyone who has just migrated and wants their
208 + // old content rewritten.
209 + 'fix_mixed_content' => false,
210 + // The Content-Security-Policy directive that tells the browser to
211 + // upgrade every http:// request, including the ones pointing at
212 + // other people's servers. If any of those has no HTTPS the
213 + // resource simply stops loading, so this is the one piece of
214 + // mixed content handling that can break a page, and it is off by
215 + // default like everything else here that forces HTTPS. It used to
216 + // ride along with fix_mixed_content with no way to separate them.
217 + 'upgrade_insecure_requests' => false,
198 218
199 219 // Server Protection (moved from firewall in v2.0.0)
200 220 'hide_server_signature' => true,
201 221 'remove_fingerprinting_headers' => true,
@@ -279,20 +299,24 @@
279 299 'force_strong_passwords' => true,
280 300 'min_password_length' => 12,
281 301
282 302 // Granular password policy. Applies only while
283 - // force_strong_passwords is on. Defaults reproduce the previous
284 - // all-requirements behaviour so existing sites keep the same
285 - // rules until the admin relaxes them. block_username is the only
286 - // new opt-in rule (off by default to avoid rejecting passwords
287 - // that were valid before). affected_roles empty = all roles.
303 + // force_strong_passwords is on. The defaults follow current
304 + // guidance (NIST SP 800-63B): what makes a password weak is being
305 + // guessable, not lacking a symbol, and composition rules push
306 + // people towards predictable substitutions and towards writing
307 + // the password down. So out of the box only the two rules that
308 + // block genuinely guessable passwords are on, and the four
309 + // character-class requirements ship off for anyone to turn on.
310 + // Existing sites keep whatever they have stored.
311 + // affected_roles empty = all roles.
288 312 'password_policy' => array(
289 - 'require_uppercase' => true,
290 - 'require_lowercase' => true,
291 - 'require_number' => true,
292 - 'require_special' => true,
313 + 'require_uppercase' => false,
314 + 'require_lowercase' => false,
315 + 'require_number' => false,
316 + 'require_special' => false,
293 317 'block_common' => true,
294 - 'block_username' => false,
318 + 'block_username' => true,
295 319 'affected_roles' => array(),
296 320 ),
297 321
298 322 'prevent_display_name_login_match' => true,
@@ -297,12 +321,16 @@
297 321
298 322 'prevent_display_name_login_match' => true,
299 323
300 324 // Admin monitoring
325 + // The two alerts that report someone gaining power ship on: a
326 + // new administrator and a role being raised are the signature of
327 + // an account takeover, and they are rare enough not to be noise.
328 + // The other two are ordinary admin housekeeping and stay opt-in.
301 329 'admin_monitoring' => array(
302 - 'alert_new_admin' => false,
330 + 'alert_new_admin' => true,
303 331 'alert_admin_email_change' => false,
304 - 'alert_permission_elevation' => false,
332 + 'alert_permission_elevation' => true,
305 333 'alert_admin_password_change' => false,
306 334 ),
307 335
308 336 // Force password reset (no options, uses native WordPress flow)
@@ -322,17 +350,23 @@
322 350 ),
323 351
324 352 // Session limits
325 353 'session_limits' => array(
326 - 'enabled' => false,
354 + 'enabled' => true,
327 355 'max_sessions' => 3,
328 356 'behavior' => 'close_oldest',
329 357 'exclude_admins' => false,
330 358 ),
331 359
332 - // Password expiration
360 + // Password expiration ships OFF. Forced rotation is no longer
361 + // recommended (NIST SP 800-63B advises against it) and it is by
362 + // far the biggest source of support here: people locked out mid
363 + // task, cron reminders that never arrive, roles nobody meant to
364 + // include. The feature stays for anyone who has to comply with a
365 + // policy that still demands it, and the Configuration Score keeps
366 + // pointing at it, which is what that score is for.
333 367 'password_expiration' => array(
334 - 'enabled' => true,
368 + 'enabled' => false,
335 369 'expire_days' => 90,
336 370 'warning_days' => 14,
337 371 'affected_roles' => array( 'administrator', 'editor' ),
338 372 'excluded_users' => array(),
@@ -355,9 +389,15 @@
355 389
356 390 // wp-config security
357 391 'disallow_file_edit' => true,
358 392 'disallow_file_mods' => false,
359 - 'force_ssl_admin' => true,
393 + // Off by default. This one writes FORCE_SSL_ADMIN into
394 + // wp-config.php, and it used to do so on activation with no
395 + // check that the site answers over HTTPS at all, which locks the
396 + // owner out of their own admin. Forcing HTTPS is an opt-in
397 + // decision per site, consistent with force_https and with HSTS,
398 + // both of which already ship off.
399 + 'force_ssl_admin' => false,
360 400 'wp_debug' => true,
361 401 // Off by default — only safe when host has a real server-side cron job;
362 402 // pairs with firewall.protect_wp_cron to block both internal triggering
363 403 // (this constant) and external HTTP abuse (the .htaccess rule).
@@ -411,19 +451,8 @@
411 451 // Strict-mode users can remove it (CSS injection is still a
412 452 // vector, defended primarily by CSP in the headers module).
413 453 '.css',
414 454 ),
415 - 'suspicious_patterns' => array(
416 - 'eval(',
417 - 'base64_decode(',
418 - 'gzinflate(',
419 - 'str_rot13(',
420 - 'exec(',
421 - 'shell_exec(',
422 - 'system(',
423 - 'passthru(',
424 - 'assert(',
425 - ),
426 455 ),
427 456
428 457 // Activity Log settings
429 458 'activity_log' => array(
@@ -445,10 +474,8 @@
445 474 ),
446 475
447 476 // Backup settings
448 477 'backup' => array(
449 - 'auto_backup' => true,
450 - 'backup_before_update' => true,
451 478 'keep_backups' => 5,
452 479 ),
453 480
454 481 // Notification settings (centralized recipients for all admin emails)
@@ -461,12 +488,8 @@
461 488 // Advanced settings
462 489 'advanced' => array(
463 490 'remove_readme' => true,
464 491 'remove_license' => true,
465 - 'block_author_archives' => false,
466 - 'disable_embeds' => false,
467 - 'uninstall_cleanup' => true,
468 - 'debug_mode' => false,
469 492 ),
470 493
471 494 // Security Analyzer (v2.1.0) — on-demand + weekly Security Check
472 495 'security_analyzer' => array(
@@ -644,8 +667,755 @@
644 667 wp_cache_delete( self::OPTION_NAME, 'options' );
645 668 }
646 669
647 670 /**
671 + * Whether this context is allowed to write the files a network shares
672 + *
673 + * wp-config.php and the root .htaccess are single files for the whole
674 + * network, while Vigilant's settings are per site. Without a gate, every
675 + * save, activation and deactivation from any site rewrites those files from
676 + * that site's own options, so the last one to save wins and silently undoes
677 + * the rest. Measured on a real network: the main site enables "disable file
678 + * editing", a subsite admin presses Save on their own screen without
679 + * touching it, and the constant disappears from wp-config.php while the main
680 + * site's screen keeps showing the box ticked.
681 + *
682 + * So on a network only the main site decides, and only a network
683 + * administrator. WP-CLI on the main site counts too: there is no user to ask
684 + * there, but the site is the right one, and a network admin running
685 + * `wp plugin activate --network` expects the files to be written.
686 + *
687 + * On a single site this is always true and nothing changes.
688 + *
689 + * @since 2.9.8
690 + *
691 + * @return bool
692 + */
693 + /**
694 + * Whether this site is the one that owns the files a network shares.
695 + *
696 + * Pure site identity, with no capability in it, and that is the point. A
697 + * refresh that Vigilant performs by itself, such as rewriting its own
698 + * .htaccess block after an update, decides nothing: the content comes from
699 + * this site's own options whoever happens to be visiting. What must not
700 + * happen is a *different* site writing the shared file, and that is exactly
701 + * what this answers.
702 + *
703 + * can_write_shared_files() below adds the capability on top, and is the
704 + * right question for anything a person initiates from a settings screen.
705 + *
706 + * @since 2.10.1
707 + * @return bool
708 + */
709 + public static function owns_shared_files() {
710 + // One wp-config.php and one root .htaccess per installation, even with
711 + // several networks in it: is_main_site() alone is true on the main site
712 + // of every network. Since 2.11.8, found by the audit of the network.
713 + return ! is_multisite() || ( is_main_site() && is_main_network() );
714 + }
715 +
716 + public static function can_write_shared_files() {
717 + if ( ! is_multisite() ) {
718 + return true;
719 + }
720 +
721 + // See owns_shared_files(): the main site of a secondary network, and
722 + // its network administrator, do not own the installation's files.
723 + if ( ! is_main_site() || ! is_main_network() ) {
724 + return false;
725 + }
726 +
727 + // WP-CLI with nobody logged in: there is no user to ask, and the site is
728 + // the right one, so a network admin running `wp plugin activate --network`
729 + // gets the files written. With a user set (wp --user=...) the capability
730 + // is checked like anywhere else, so the gate cannot be side-stepped by
731 + // running as a subsite administrator.
732 + if ( defined( 'WP_CLI' ) && WP_CLI && ! get_current_user_id() ) {
733 + return true;
734 + }
735 +
736 + return current_user_can( 'manage_network_options' );
737 + }
738 +
739 + /**
740 + * The one message shown wherever a shared-file setting is out of reach
741 + *
742 + * Deliberately a single string reused by every section, instead of one per
743 + * section: it says the same thing everywhere and there is no reason to make
744 + * translators write it four times.
745 + *
746 + * @since 2.9.8
747 + *
748 + * @return string
749 + */
750 + public static function get_shared_files_notice() {
751 + return __( 'These settings are written to wp-config.php and .htaccess, files the whole network shares. So that one site cannot overwrite another, they are managed from the main site of the network by a network administrator.', 'vigilante' );
752 + }
753 +
754 + /**
755 + * Apply the tweaks a brand new installation gets on top of the raw defaults
756 + *
757 + * A few keys are deliberately missing from get_default_options() because
758 + * declaring them would break something else. XML-RPC is the one case today:
759 + * declaring wp_hardening.xmlrpc_mode would make the defaults merge fill it in
760 + * always and hide the fallback that reads the old pair of settings on sites
761 + * that have not re-saved the tab. With nothing stored the resolver answers
762 + * 'full', which blocks XML-RPC completely, and that is not what we want a new
763 + * site to get.
764 + *
765 + * Everything that seeds a clean configuration has to run this: the activation
766 + * hook, the per-section reset and the global reset to defaults. Otherwise the
767 + * defaults you get by pressing a button are not the defaults you get by
768 + * installing the plugin, which is exactly what happened until 2.9.8.
769 + *
770 + * @since 2.9.8
771 + *
772 + * @param array $options Options array to adjust.
773 + * @return array
774 + */
775 + public static function apply_install_tweaks( $options ) {
776 + if ( ! isset( $options['wp_hardening'] ) || ! is_array( $options['wp_hardening'] ) ) {
777 + $options['wp_hardening'] = array();
778 + }
779 +
780 + $options['wp_hardening']['xmlrpc_mode'] = 'pingback';
781 +
782 + return $options;
783 + }
784 +
785 + /**
786 + * Keys that hold what the site owner typed in, never wiped by a restore
787 + *
788 + * Putting the security posture back to its defaults is one thing; deleting
789 + * an IP whitelist, the secret login address, the two factor setup or the
790 + * addresses that receive the alerts is another, and nobody presses a button
791 + * called "restore defaults" expecting that. Both the Standard preset and the
792 + * two reset buttons leave these alone.
793 + *
794 + * @since 2.9.8
795 + *
796 + * @return array<string,string[]>
797 + */
798 + public static function get_user_data_keys() {
799 + return array(
800 + 'firewall' => array( 'ip_whitelist', 'ip_blacklist', 'ua_whitelist', 'ua_blacklist', 'trusted_proxy_header', 'trusted_proxies' ),
801 + 'login_security' => array( 'ip_whitelist', 'custom_login_url', 'two_factor' ),
802 + 'user_security' => array( 'insecure_usernames' ),
803 + 'file_integrity' => array( 'excluded_paths', 'excluded_extensions' ),
804 + 'email' => array( 'additional_recipients' ),
805 + );
806 + }
807 +
808 + /**
809 + * Settings whose only effect is written to a file the network shares
810 + *
811 + * true for a whole section, or the list of keys inside it. Used to keep a
812 + * subsite from resetting settings it does not control: the file is written
813 + * from the main site, so resetting the local copy would only make the two
814 + * disagree.
815 + *
816 + * Note this is not every setting that reaches .htaccess. Blocking bad bots
817 + * or empty user agents also runs in PHP, per site, so those stay editable on
818 + * a subsite: the PHP half protects that site and the .htaccess half is
819 + * refused, leaving the main site's rules standing. On the main site they
820 + * are locked too, see get_main_site_file_settings().
821 + *
822 + * The PHP blocks for plugins and themes have no field on the settings
823 + * screen, but an imported file carries them, and readme.html and
824 + * license.txt are removed from the root the whole network shares.
825 + *
826 + * @since 2.9.8
827 + *
828 + * @return array<string,true|string[]>
829 + */
830 + public static function get_shared_file_settings() {
831 + return array(
832 + 'security_headers' => true,
833 + 'wp_hardening' => array( 'disallow_file_edit', 'disallow_file_mods', 'force_ssl_admin', 'force_ssl_login', 'wp_debug', 'disable_wp_cron' ),
834 + 'firewall' => array( 'disable_directory_browsing', 'protect_wp_config', 'protect_wp_includes', 'protect_uploads_php', 'protect_sensitive_files', 'protect_wp_cron', 'limit_http_methods', 'block_php_in_plugins', 'block_php_in_themes' ),
835 + 'advanced' => array( 'remove_readme', 'remove_license' ),
836 + );
837 + }
838 +
839 + /**
840 + * Settings the shared files are built from that also act on the site storing them
841 + *
842 + * get_shared_file_settings() lists what does nothing but end up in a shared
843 + * file. These do both: blocking bad bots and bad query strings, the visitor
844 + * IP detection and the two whitelists run in PHP for the site that stores
845 + * them, and on the main site of a network they are also what the .htaccess
846 + * rules of every site are generated from; the three writing module switches
847 + * (firewall, security_headers, wp_hardening) decide whether the .htaccess
848 + * blocks and the wp-config.php constants exist at all.
849 + *
850 + * Since 2.11.8 it also locks what decides whether the shared files are
851 + * WATCHED, not built: the File Integrity module and its scan_critical_config
852 + * switch. On the main site the critical-file scan is the network's canary
853 + * for a change to wp-config.php or the root .htaccess, which only a network
854 + * administrator can approve, so a main-site administrator without network
855 + * rights must not be able to silence it by turning either one off. Closing
856 + * the ignore list and the clear-results button in 2.11.8 left these two as
857 + * the remaining routes; found by the audit of the admin surface.
858 + *
859 + * On a subsite all of them only act on that site, so they stay editable
860 + * there (get_locked_file_settings() adds this set only when owns_shared_files()).
861 + *
862 + * Until 2.11.6 an administrator of the main site without network rights
863 + * could change any of them, and the file-only ones too: the write to the
864 + * file was refused at that moment, but the value stayed stored, and the
865 + * refresh after the next update, or the next save by a network
866 + * administrator, published it to the whole network.
867 + *
868 + * @since 2.11.6
869 + * @since 2.11.8 The file_integrity module and scan_critical_config.
870 + *
871 + * @return array<string,string[]>
872 + */
873 + /**
874 + * The two factor policy that governs this installation
875 + *
876 + * On a network the answer must not depend on which site the login happens to
877 + * arrive at, because the cookie WordPress issues does not: COOKIEHASH comes
878 + * from the network siteurl (wp-includes/default-constants.php) and
879 + * COOKIE_DOMAIN covers every host of the network
880 + * (wp-includes/ms-default-constants.php). Until 2.11.10 the settings, the
881 + * enforced roles and the TOTP table were all read per site, so somebody
882 + * holding the password of an administrator protected by 2FA on the main site
883 + * posted the login to a subsite where that account has no role, was never
884 + * asked for a code, and came out with a session valid across the network.
885 + * Measured on the Multisite install on 12 sep 2026 (user_requires_2fa true on
886 + * the main site, false on demo2 for the same account) and found by the
887 + * file-by-file review of 2.11.10.
888 + *
889 + * So the policy of the main site governs the whole network. On a single site
890 + * this is the site's own configuration and nothing changes.
891 + *
892 + * @since 2.11.10
893 + *
894 + * @return array The two_factor section that applies.
895 + */
896 + public static function two_factor_policy() {
897 + $options = is_multisite()
898 + ? get_blog_option( get_main_site_id(), self::OPTION_NAME, array() )
899 + : get_option( self::OPTION_NAME, array() );
900 +
901 + if ( ! is_array( $options ) ) {
902 + return array();
903 + }
904 +
905 + $login = isset( $options['login_security'] ) && is_array( $options['login_security'] )
906 + ? $options['login_security']
907 + : array();
908 +
909 + return ( isset( $login['two_factor'] ) && is_array( $login['two_factor'] ) ) ? $login['two_factor'] : array();
910 + }
911 +
912 + /**
913 + * Whether two factor is required for this account, anywhere in the network
914 + *
915 + * Union, and deliberately so. Reading the policy only from the main site,
916 + * which is what this release did at first, would have switched two factor off
917 + * for every network that has it configured per subsite, which until now was
918 + * the only way it could be configured at all: a silent downgrade of the very
919 + * protection being fixed. Found by the cross review of 2.11.10. So the
920 + * question is asked of every site the account belongs to, plus the main site,
921 + * each with its own enforced roles and exclusions, and one yes is enough.
922 + *
923 + * That also closes the bypass: the settings, the roles and the enrolment used
924 + * to be read from whichever site the login arrived at, while the cookie
925 + * WordPress issues is valid across the whole network (COOKIEHASH comes from
926 + * the network siteurl and COOKIE_DOMAIN covers every host of it), so an
927 + * account protected on one site could log in through another and come out
928 + * with a session valid everywhere.
929 + *
930 + * @since 2.11.10
931 + *
932 + * @param WP_User $user User being authenticated.
933 + * @return bool
934 + */
935 + public static function two_factor_required_for( $user ) {
936 + return array() !== self::two_factor_demands_for( $user );
937 + }
938 +
939 + /**
940 + * Which second factor methods this account is asked for, across the network
941 + *
942 + * Empty when nothing asks. On a network there can be more than one, because
943 + * each site keeps its own settings and the requirement is the union of them.
944 + *
945 + * @since 2.11.10
946 + *
947 + * @param WP_User $user User being authenticated.
948 + * @return string[] Methods asked for, without repeats.
949 + */
950 + public static function two_factor_methods_for( $user ) {
951 + $methods = array();
952 +
953 + foreach ( self::two_factor_demands_for( $user ) as $settings ) {
954 + $method = isset( $settings['method'] ) ? (string) $settings['method'] : 'email';
955 +
956 + // A method this version does not know is read as the default rather
957 + // than left to fall through. Registering nothing at all is how the
958 + // second factor of a whole network went quiet in silence: a saved
959 + // value of '' (which validate_section() lets through on an import,
960 + // since only the tab has an allowlist) matched neither class, so no
961 + // filter was registered anywhere while every screen still said two
962 + // factor was on. Found by the third cross review of 2.11.10.
963 + $methods[] = in_array( $method, array( 'email', 'totp' ), true ) ? $method : 'email';
964 + }
965 +
966 + return array_values( array_unique( $methods ) );
967 + }
968 +
969 + /**
970 + * Which of the two second factor classes handles this login
971 + *
972 + * The method cannot be read from one site's settings, and reading it from the
973 + * main site was the hole the third cross review of 2.11.10 found: with the
974 + * main site on totp and a subsite asking for a code by email, the class that
975 + * registered was TOTP, the account had no enrolment, and the "not set up yet"
976 + * branch let the login through. In 2.11.9 that same login was asked for its
977 + * emailed code. So the question is asked per account, not per site.
978 + *
979 + * The order is what keeps it closed at both ends:
980 + *
981 + * 1. An enrolment already made wins while some site asking for a second
982 + * factor asks for an authenticator app. It is the strongest factor the
983 + * account has and it is ready to use, wherever in the network it was set
984 + * up.
985 + * 2. Otherwise, if any site asking for a second factor asks for email, email
986 + * handles it. Email needs no enrolment, so it can never fall into the
987 + * branch that lets a login through for lack of one.
988 + * 3. Only when every site asking wants an authenticator app does TOTP handle
989 + * it, which is the case the grace period was written for.
990 + *
991 + * The condition on the first step came in 2.11.11. Without it an enrolment
992 + * left from a time when the site asked for an app outranked the method the
993 + * site asks for now: a single site set to email asked those accounts for an
994 + * authenticator code, which 2.11.9 never did and which locks out whoever
995 + * removed the app after the switch. Dropping that enrolment opens nothing,
996 + * because the account then goes to email, which needs no enrolment.
997 + *
998 + * @since 2.11.10
999 + * @since 2.11.11 An enrolment only wins while an authenticator app is asked for.
1000 + *
1001 + * @param WP_User $user User being authenticated.
1002 + * @param bool $enrolled Whether the account has a TOTP enrolment anywhere.
1003 + * @return string 'email', 'totp', or '' when nothing asks.
1004 + */
1005 + public static function two_factor_handler_for( $user, $enrolled ) {
1006 + $methods = self::two_factor_methods_for( $user );
1007 +
1008 + if ( ! $methods ) {
1009 + return '';
1010 + }
1011 +
1012 + if ( $enrolled && in_array( 'totp', $methods, true ) ) {
1013 + return 'totp';
1014 + }
1015 +
1016 + return in_array( 'email', $methods, true ) ? 'email' : 'totp';
1017 + }
1018 +
1019 + /**
1020 + * The two factor settings of every site that asks this account for one
1021 + *
1022 + * @since 2.11.10
1023 + *
1024 + * @param WP_User $user User being authenticated.
1025 + * @return array[] The two_factor section of each site that asks.
1026 + */
1027 + private static function two_factor_demands_for( $user ) {
1028 + if ( empty( $user->ID ) ) {
1029 + return array();
1030 + }
1031 +
1032 + if ( ! is_multisite() ) {
1033 + $roles = ( isset( $user->roles ) && is_array( $user->roles ) ) ? $user->roles : array();
1034 + $policy = self::two_factor_policy();
1035 +
1036 + return self::two_factor_site_requires( $policy, $user, $roles ) ? array( $policy ) : array();
1037 + }
1038 +
1039 + $demands = array();
1040 + $blog_ids = array( (int) get_main_site_id() );
1041 +
1042 + /*
1043 + * A super administrator is a member of almost no site (measured on the
1044 + * Multisite install: of three sites, the network owner belongs to one),
1045 + * yet can log in through any of them and the cookie is valid everywhere.
1046 + * Asking only the sites they belong to left the account with the most
1047 + * power in the network outside the policy, which is the bypass upside
1048 + * down. So for them every site of the network is consulted. There are
1049 + * few super administrators. It does not only run at login, though, which
1050 + * this note claimed until 2.11.11: the dashboard hooks of the TOTP class
1051 + * ask it on every admin screen of every site of a network, at least once
1052 + * per hook.
1053 + */
1054 + if ( is_super_admin( $user->ID ) ) {
1055 + $blog_ids = array_merge( $blog_ids, get_sites( array( 'fields' => 'ids', 'number' => 200 ) ) );
1056 + }
1057 +
1058 + foreach ( get_blogs_of_user( $user->ID ) as $blog ) {
1059 + if ( ! empty( $blog->userblog_id ) ) {
1060 + $blog_ids[] = (int) $blog->userblog_id;
1061 + }
1062 + }
1063 +
1064 + foreach ( array_unique( $blog_ids ) as $blog_id ) {
1065 + $options = get_blog_option( $blog_id, self::OPTION_NAME, array() );
1066 +
1067 + if ( ! is_array( $options ) || empty( $options['login_security']['two_factor'] ) ) {
1068 + continue;
1069 + }
1070 +
1071 + /*
1072 + * A site whose Login Security module is off asks for nothing, and
1073 + * reading only the sub-setting made it ask anyway: a subsite that had
1074 + * switched the whole module off, leaving an orphan two_factor.enabled
1075 + * behind, imposed a second factor on every account of the network,
1076 + * with no screen anywhere explaining why. It is the two-level toggle
1077 + * trap of this plugin read upside down. Found by the third cross
1078 + * review of 2.11.10.
1079 + */
1080 + if ( empty( $options['modules']['login_security'] ) ) {
1081 + continue;
1082 + }
1083 +
1084 + $elsewhere = new WP_User( $user->ID );
1085 + $elsewhere->for_site( $blog_id );
1086 +
1087 + // A super administrator can hold no role row anywhere, and is judged
1088 + // as an administrator so the strictest policy of the network reaches
1089 + // the account with the most power in it.
1090 + $roles = ( isset( $elsewhere->roles ) && is_array( $elsewhere->roles ) && $elsewhere->roles )
1091 + ? $elsewhere->roles
1092 + : ( is_super_admin( $user->ID ) ? array( 'administrator' ) : array() );
1093 +
1094 + if ( self::two_factor_site_requires( $options['login_security']['two_factor'], $user, $roles ) ) {
1095 + $demands[] = $options['login_security']['two_factor'];
1096 + }
1097 + }
1098 +
1099 + return $demands;
1100 + }
1101 +
1102 + /**
1103 + * Whether one site's two factor settings cover this account
1104 + *
1105 + * @since 2.11.10
1106 + *
1107 + * @param array $settings The two_factor section of one site.
1108 + * @param WP_User $user User being authenticated.
1109 + * @param string[] $roles Roles the account holds on that site.
1110 + * @return bool
1111 + */
1112 + private static function two_factor_site_requires( $settings, $user, $roles ) {
1113 + if ( ! is_array( $settings ) || empty( $settings['enabled'] ) ) {
1114 + return false;
1115 + }
1116 +
1117 + $excluded = isset( $settings['excluded_users'] ) ? array_map( 'absint', (array) $settings['excluded_users'] ) : array();
1118 +
1119 + if ( in_array( (int) $user->ID, $excluded, true ) ) {
1120 + return false;
1121 + }
1122 +
1123 + $enforced = isset( $settings['enforced_roles'] ) ? (array) $settings['enforced_roles'] : array( 'administrator', 'editor' );
1124 +
1125 + return (bool) array_intersect( (array) $roles, $enforced );
1126 + }
1127 +
1128 + /**
1129 + * Settings that only a network administrator may change on the main site
1130 + *
1131 + * @return array<string,string[]>
1132 + */
1133 + public static function get_main_site_file_settings() {
1134 + return array(
1135 + 'modules' => array( 'firewall', 'security_headers', 'wp_hardening', 'file_integrity' ),
1136 + // trusted_proxies goes with trusted_proxy_header, and leaving it out
1137 + // was a hole: the header decides which address the firewall of the
1138 + // whole installation acts on, and this list decides which peers may
1139 + // set that header. An administrator of the main site without network
1140 + // rights who could edit only this half turned every visitor into a
1141 + // trusted proxy. Found by the file-by-file review of 2.11.10.
1142 + 'firewall' => array( 'block_bad_bots', 'block_bad_query_strings', 'trusted_proxy_header', 'trusted_proxies', 'ip_whitelist', 'ua_whitelist' ),
1143 + 'file_integrity' => array( 'scan_critical_config' ),
1144 + );
1145 + }
1146 +
1147 + /**
1148 + * Shared file settings the current user may not change on this site
1149 + *
1150 + * Empty when the user can write the shared files. Otherwise the file-only
1151 + * settings on every site, plus, on the main site, the ones it also builds
1152 + * the shared files from.
1153 + *
1154 + * @since 2.11.6
1155 + *
1156 + * @return array<string,true|string[]>
1157 + */
1158 + public static function get_locked_file_settings() {
1159 + if ( self::can_write_shared_files() ) {
1160 + return array();
1161 + }
1162 +
1163 + $locked = self::get_shared_file_settings();
1164 +
1165 + if ( self::owns_shared_files() ) {
1166 + foreach ( self::get_main_site_file_settings() as $section => $keys ) {
1167 + if ( ! isset( $locked[ $section ] ) ) {
1168 + $locked[ $section ] = $keys;
1169 + } elseif ( is_array( $locked[ $section ] ) ) {
1170 + $locked[ $section ] = array_values( array_unique( array_merge( $locked[ $section ], $keys ) ) );
1171 + }
1172 + }
1173 + }
1174 +
1175 + return $locked;
1176 + }
1177 +
1178 + /**
1179 + * Put back the stored value of every shared file setting the user may not change
1180 + *
1181 + * For every writer of the whole configuration: saving a tab, importing a
1182 + * file, applying a preset, restoring the defaults. Hiding a field on the
1183 + * screen decides nothing, because the request can carry the key anyway. A
1184 + * key that was not stored is dropped, so its default keeps applying.
1185 + *
1186 + * @since 2.11.6
1187 + *
1188 + * @param array $options Configuration about to be stored.
1189 + * @param array $stored Configuration stored now, as read from the option.
1190 + * @return array
1191 + */
1192 + public static function keep_locked_file_settings( $options, $stored ) {
1193 + $options = is_array( $options ) ? $options : array();
1194 + $stored = is_array( $stored ) ? $stored : array();
1195 + $locked = self::get_locked_file_settings();
1196 +
1197 + if ( ! $locked ) {
1198 + return $options;
1199 + }
1200 +
1201 + /*
1202 + * A key that was never stored takes its default, which is what it was
1203 + * worth before. Until 2.11.8 it was dropped instead, and the sanitize
1204 + * callback of the option filled it in again, but validate_options()
1205 + * fills a missing module switch with false, not with its default.
1206 + */
1207 + $instance = new self();
1208 + $defaults = $instance->get_default_options();
1209 +
1210 + foreach ( $locked as $section => $keys ) {
1211 + if ( true === $keys ) {
1212 + if ( array_key_exists( $section, $stored ) ) {
1213 + $options[ $section ] = $stored[ $section ];
1214 + } elseif ( isset( $defaults[ $section ] ) ) {
1215 + $options[ $section ] = $defaults[ $section ];
1216 + } else {
1217 + unset( $options[ $section ] );
1218 + }
1219 + continue;
1220 + }
1221 +
1222 + $stored_section = ( isset( $stored[ $section ] ) && is_array( $stored[ $section ] ) ) ? $stored[ $section ] : array();
1223 + $default_section = ( isset( $defaults[ $section ] ) && is_array( $defaults[ $section ] ) ) ? $defaults[ $section ] : array();
1224 +
1225 + foreach ( $keys as $key ) {
1226 + if ( array_key_exists( $key, $stored_section ) ) {
1227 + $value = $stored_section[ $key ];
1228 + } elseif ( array_key_exists( $key, $default_section ) ) {
1229 + $value = $default_section[ $key ];
1230 + } else {
1231 + if ( isset( $options[ $section ] ) && is_array( $options[ $section ] ) ) {
1232 + unset( $options[ $section ][ $key ] );
1233 + }
1234 + continue;
1235 + }
1236 +
1237 + if ( ! isset( $options[ $section ] ) || ! is_array( $options[ $section ] ) ) {
1238 + $options[ $section ] = array();
1239 + }
1240 + $options[ $section ][ $key ] = $value;
1241 + }
1242 + }
1243 +
1244 + return $options;
1245 + }
1246 +
1247 + /**
1248 + * Take a lock kept as a row of the options table, or report that another request holds it
1249 + *
1250 + * add_option() cannot be a lock: it runs INSERT ... ON DUPLICATE KEY UPDATE
1251 + * (wp-includes/option.php:1142 in WP 7.1), so two requests that both find
1252 + * the option missing both "create" it and both believe they hold it. INSERT
1253 + * IGNORE creates the row for exactly one of them, which is what core does in
1254 + * WP_Upgrader::create_lock() (wp-admin/includes/class-wp-upgrader.php:1065).
1255 + * A lock older than the timeout counts as abandoned, by a fatal error between
1256 + * taking and releasing it, and only one request takes it over.
1257 + *
1258 + * @since 2.11.8
1259 + *
1260 + * @param string $name Option name of the lock, in the current site's table.
1261 + * @param int $timeout Seconds after which a held lock counts as abandoned.
1262 + * @return bool True if this request now holds the lock.
1263 + */
1264 + public static function acquire_option_lock( $name, $timeout ) {
1265 + global $wpdb;
1266 +
1267 + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- an atomic lock needs INSERT IGNORE, which the options API does not offer; same query as WP_Upgrader::create_lock().
1268 + if ( $wpdb->query( $wpdb->prepare( "INSERT IGNORE INTO {$wpdb->options} ( option_name, option_value, autoload ) VALUES ( %s, %s, 'no' )", $name, (string) time() ) ) ) {
1269 + wp_cache_delete( $name, 'options' );
1270 + return true;
1271 + }
1272 +
1273 + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- the lock row as stored right now, not a cached copy.
1274 + $held = $wpdb->get_var( $wpdb->prepare( "SELECT option_value FROM {$wpdb->options} WHERE option_name = %s", $name ) );
1275 +
1276 + if ( null === $held || ( time() - (int) $held ) < $timeout ) {
1277 + return false;
1278 + }
1279 +
1280 + // Abandoned: the delete only matches the value that was read, and only one
1281 + // request wins the insert that follows.
1282 + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- removes an abandoned lock row.
1283 + $wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->options} WHERE option_name = %s AND option_value = %s", $name, $held ) );
1284 +
1285 + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- same atomic insert as above.
1286 + return (bool) $wpdb->query( $wpdb->prepare( "INSERT IGNORE INTO {$wpdb->options} ( option_name, option_value, autoload ) VALUES ( %s, %s, 'no' )", $name, (string) time() ) );
1287 + }
1288 +
1289 + /**
1290 + * Release a lock taken with acquire_option_lock()
1291 + *
1292 + * @since 2.11.8
1293 + *
1294 + * @param string $name Option name of the lock.
1295 + */
1296 + public static function release_option_lock( $name ) {
1297 + global $wpdb;
1298 +
1299 + // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching -- removes the row acquire_option_lock() inserted.
1300 + $wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->options} WHERE option_name = %s", $name ) );
1301 + wp_cache_delete( $name, 'options' );
1302 + }
1303 +
1304 + /**
1305 + * Put a configuration back to the defaults without deleting what the owner typed
1306 + *
1307 + * @since 2.9.8
1308 + *
1309 + * @param array $current Configuration being replaced.
1310 + * @return array
1311 + */
1312 + public static function get_defaults_preserving_user_data( $current ) {
1313 + $instance = new self();
1314 + $defaults = self::apply_install_tweaks( $instance->get_default_options() );
1315 +
1316 + foreach ( self::get_user_data_keys() as $section => $keys ) {
1317 + foreach ( $keys as $key ) {
1318 + if ( isset( $current[ $section ] ) && array_key_exists( $key, (array) $current[ $section ] ) ) {
1319 + $defaults[ $section ][ $key ] = $current[ $section ][ $key ];
1320 + }
1321 + }
1322 + }
1323 +
1324 + return $defaults;
1325 + }
1326 +
1327 + /**
1328 + * The values the Standard preset applies
1329 + *
1330 + * Standard is the configuration a new installation gets, with every module
1331 + * on. It is built from the defaults rather than written out by hand, because
1332 + * a hand-written copy drifts: until 2.9.8 Standard named a dozen fields and
1333 + * left everything else alone, so applying it after Maximum kept Maximum's
1334 + * password rules, its administrator alerts, its session limits and its
1335 + * password expiry, and the preset that says it applies sensible defaults
1336 + * applied almost none of them.
1337 + *
1338 + * The only thing it does not touch is what the site owner typed in: IP and
1339 + * user agent lists, the custom login address, two factor configuration, the
1340 + * integrity scan exclusions and the extra notification recipients. Putting
1341 + * the security posture back to the defaults is one thing, throwing away
1342 + * someone's whitelist is another, and "Reset to Defaults" is right there for
1343 + * that.
1344 + *
1345 + * @since 2.9.8
1346 + *
1347 + * @return array
1348 + */
1349 + private function get_standard_preset_values() {
1350 + $values = self::apply_install_tweaks( $this->get_default_options() );
1351 +
1352 + foreach ( array_keys( $values['modules'] ) as $module ) {
1353 + $values['modules'][ $module ] = true;
1354 + }
1355 +
1356 + foreach ( self::get_user_data_keys() as $section => $keys ) {
1357 + foreach ( $keys as $key ) {
1358 + unset( $values[ $section ][ $key ] );
1359 + }
1360 + }
1361 +
1362 + unset( $values['user_security']['password_expiration']['excluded_users'] );
1363 +
1364 + return $values;
1365 + }
1366 +
1367 + /**
1368 + * Merge a preset over a configuration
1369 + *
1370 + * Not array_replace_recursive(), which is wrong for this in two ways. A list
1371 + * of roles in the preset is merged position by position instead of replacing
1372 + * the stored one, so applying Standard over Maximum turned the two roles
1373 + * Standard expires passwords for into Maximum's five with the first two
1374 + * overwritten. And an empty list in the preset clears nothing at all,
1375 + * because there is no element to replace with.
1376 + *
1377 + * So: associative arrays are merged key by key, and lists and scalars are
1378 + * replaced outright.
1379 + *
1380 + * @since 2.9.8
1381 + *
1382 + * @param array $base Current configuration.
1383 + * @param array $overlay Preset values.
1384 + * @return array
1385 + */
1386 + public static function merge_preset( $base, $overlay ) {
1387 + foreach ( $overlay as $key => $value ) {
1388 + if ( is_array( $value ) && isset( $base[ $key ] ) && is_array( $base[ $key ] ) && ! self::is_list( $value ) ) {
1389 + $base[ $key ] = self::merge_preset( $base[ $key ], $value );
1390 + continue;
1391 + }
1392 +
1393 + $base[ $key ] = $value;
1394 + }
1395 +
1396 + return $base;
1397 + }
1398 +
1399 + /**
1400 + * Whether an array is a plain list (0..n-1 keys)
1401 + *
1402 + * array_is_list() is PHP 8.1 and this plugin supports 7.4.
1403 + *
1404 + * @since 2.9.8
1405 + *
1406 + * @param array $value Array to inspect.
1407 + * @return bool
1408 + */
1409 + private static function is_list( $value ) {
1410 + if ( array() === $value ) {
1411 + return true;
1412 + }
1413 +
1414 + return array_keys( $value ) === range( 0, count( $value ) - 1 );
1415 + }
1416 +
1417 + /**
648 1418 * Get presets with descriptions
649 1419 *
650 1420 * @return array Presets configuration.
651 1421 */
@@ -650,46 +1420,14 @@
650 1420 * @return array Presets configuration.
651 1421 */
652 1422 public function get_presets() {
653 1423 return array(
654 - 'standard' => array(
655 - 'name' => __( 'Standard', 'vigilante' ),
656 - 'description' => __( 'Balanced security suitable for most websites. Enables all modules with sensible defaults.', 'vigilante' ),
657 - 'modules' => array(
658 - 'firewall' => true,
659 - 'security_headers' => true,
660 - 'login_security' => true,
661 - 'rest_api_security'=> true,
662 - 'user_security' => true,
663 - 'wp_hardening' => true,
664 - 'file_integrity' => true,
665 - 'activity_log' => true,
1424 + 'standard' => array_merge(
1425 + array(
1426 + 'name' => __( 'Standard', 'vigilante' ),
1427 + 'description' => __( 'Balanced security suitable for most websites. Enables every module and puts every setting back to the value a new installation gets.', 'vigilante' ),
666 1428 ),
667 - 'firewall' => array(
668 - 'block_bad_query_strings' => true,
669 - 'block_sql_injection' => true,
670 - 'block_xss_attacks' => true,
671 - 'rate_limiting' => array(
672 - 'enabled' => true,
673 - 'requests_per_minute' => 120,
674 - ),
675 - ),
676 - 'login_security' => array(
677 - 'max_attempts' => 5,
678 - 'lockout_duration' => 1800,
679 - ),
680 - 'rest_api_security' => array(
681 - 'mode' => 'selective',
682 - ),
683 - 'user_security' => array(
684 - 'prevent_display_name_login_match' => true,
685 - ),
686 - 'file_integrity' => array(
687 - 'notify_level' => 'suspicious_only',
688 - ),
689 - 'wp_hardening' => array(
690 - 'xmlrpc_mode' => 'full',
691 - ),
1429 + $this->get_standard_preset_values()
692 1430 ),
693 1431
694 1432 'maximum' => array(
695 1433 'name' => __( 'Maximum Security', 'vigilante' ),
@@ -817,8 +1555,23 @@
817 1555 'scan_frequency' => 'daily',
818 1556 'notify_level' => 'all',
819 1557 'instant_alert' => true,
820 1558 ),
1559 + // A configuration called Maximum Security that never tells you
1560 + // anything happened is half a product, so the audit alerts ship
1561 + // on with it. The shared cooldown keeps a sustained attack from
1562 + // turning into a flood. Under Attack mode builds on this preset,
1563 + // so it inherits them for as long as it is on and gives them back
1564 + // when it is switched off.
1565 + 'audit_alerts' => array(
1566 + 'immediate' => array(
1567 + 'enabled' => true,
1568 + 'min_severity' => 'critical',
1569 + ),
1570 + 'threshold' => array(
1571 + 'enabled' => true,
1572 + ),
1573 + ),
821 1574 'activity_log' => array(
822 1575 'log_logins' => true,
823 1576 'log_failed_logins' => true,
824 1577 'log_user_changes' => true,
@@ -895,17 +1648,102 @@
895 1648 }
896 1649 } elseif ( isset( $defaults[ $section ] ) ) {
897 1650 // Validate other sections using generic validator
898 1651 $validated[ $section ] = $this->validate_section( $data, $defaults[ $section ] );
1652 +
1653 + // The few keys that live outside get_default_options() on
1654 + // purpose (see apply_install_tweaks()) survive with their own
1655 + // validation, or an import would silently lose them and the
1656 + // XML-RPC resolver would fall back to blocking everything.
1657 + foreach ( self::undeclared_keys( $section ) as $key => $type ) {
1658 + if ( ! array_key_exists( $key, $data ) ) {
1659 + continue;
1660 + }
1661 + if ( 'bool' === $type ) {
1662 + $validated[ $section ][ $key ] = (bool) $data[ $key ];
1663 + } elseif ( is_array( $type ) && in_array( $data[ $key ], $type, true ) ) {
1664 + $validated[ $section ][ $key ] = $data[ $key ];
1665 + }
1666 + }
899 1667 }
900 1668 }
901 1669
1670 + /*
1671 + * The lock on the settings the shared files are built from is NOT applied
1672 + * here, and that is a decision, not an oversight. The second cross review
1673 + * of 2.11.10 raised that register_setting( 'vigilante_options', ... )
1674 + * declares this as its sanitize callback with no lock in it, so anything
1675 + * reaching options.php with that option group would write the whole
1676 + * option. The chain does not close: the plugin prints no settings_fields()
1677 + * for that group anywhere, so the nonce it would need is not obtainable,
1678 + * and the five places that do save (saving a tab, importing, a preset,
1679 + * restoring the defaults, resetting a section) all apply
1680 + * keep_locked_file_settings() themselves.
1681 + *
1682 + * Putting it here instead would be worse than the door it closes. A
1683 + * register_setting() callback runs on EVERY update_option() of this
1684 + * option, so it would also lock the writes with no user behind them: the
1685 + * expiry of Under Attack restoring what it hardened, WP-CLI and cron.
1686 + * Those are already covered by matriz-red-ajustes-compartidos.sh, which
1687 + * is where such a change would show up as a row that stopped passing.
1688 + */
1689 +
902 1690 return apply_filters( 'vigilante_validate_options', $validated, $input );
903 1691 }
904 1692
905 1693 /**
1694 + * Keys deliberately absent from get_default_options(), with how to validate them
1695 + *
1696 + * Declaring them as defaults would break the fallback they exist for (see
1697 + * apply_install_tweaks()), but the validator still has to know them, or a
1698 + * settings import drops them (found in the 2.11.0 cross review).
1699 + *
1700 + * @since 2.11.0
1701 + *
1702 + * @param string $section Section name.
1703 + * @return array key => 'bool' or list of allowed values.
1704 + */
1705 + private static function undeclared_keys( $section ) {
1706 + $keys = array(
1707 + 'wp_hardening' => array( 'xmlrpc_mode' => array( 'full', 'pingback', 'none' ) ),
1708 + 'login_security' => array(
1709 + 'disable_xmlrpc' => 'bool',
1710 + 'disable_xmlrpc_pingback' => 'bool',
1711 + ),
1712 + );
1713 +
1714 + return isset( $keys[ $section ] ) ? $keys[ $section ] : array();
1715 + }
1716 +
1717 + /**
1718 + * Whether a default value describes a free list rather than a schema
1719 + *
1720 + * An empty array or sequential numeric keys (an IP whitelist, a list of
1721 + * roles) is a list: every entry the user typed is kept. Anything else is a
1722 + * schema: only its keys survive validation.
1723 + *
1724 + * @since 2.11.0
1725 + *
1726 + * @param array $defaults Default value of a setting.
1727 + * @return bool
1728 + */
1729 + private function is_list_default( $defaults ) {
1730 + if ( array() === $defaults ) {
1731 + return true;
1732 + }
1733 +
1734 + return array_keys( $defaults ) === range( 0, count( $defaults ) - 1 );
1735 + }
1736 +
1737 + /**
906 1738 * Validate a section based on defaults
907 1739 *
1740 + * Since 2.11.0 the result only holds keys the defaults know. The loop that
1741 + * used to reincorporate unknown keys "sanitized" meant a settings import
1742 + * could merge any key it liked into vigilante_options (S7 of the 28 Aug
1743 + * 2026 audit). Lists are the exception, handled first: their entries are
1744 + * data, not keys.
1745 + *
908 1746 * @param array $input Input values.
909 1747 * @param array $defaults Default values.
910 1748 * @return array Validated values.
911 1749 */
@@ -911,8 +1749,25 @@
911 1749 */
912 1750 private function validate_section( $input, $defaults ) {
913 1751 $validated = array();
914 1752
1753 + if ( $this->is_list_default( $defaults ) ) {
1754 + if ( ! is_array( $input ) ) {
1755 + return array();
1756 + }
1757 +
1758 + $list = array();
1759 + foreach ( $input as $value ) {
1760 + if ( is_scalar( $value ) ) {
1761 + $list[] = sanitize_text_field( (string) $value );
1762 + } elseif ( is_array( $value ) ) {
1763 + $list[] = map_deep( $value, 'sanitize_text_field' );
1764 + }
1765 + }
1766 +
1767 + return $list;
1768 + }
1769 +
915 1770 foreach ( $defaults as $key => $default_value ) {
916 1771 if ( ! isset( $input[ $key ] ) ) {
917 1772 $validated[ $key ] = $default_value;
918 1773 continue;
@@ -934,18 +1789,9 @@
934 1789 $validated[ $key ] = sanitize_text_field( $value );
935 1790 }
936 1791 }
937 1792
938 - // Include any extra keys from input
939 - foreach ( $input as $key => $value ) {
940 - if ( ! isset( $validated[ $key ] ) ) {
941 - if ( is_array( $value ) ) {
942 - $validated[ $key ] = array_map( 'sanitize_text_field', $value );
943 - } else {
944 - $validated[ $key ] = sanitize_text_field( $value );
945 - }
946 - }
947 - }
1793 + // Keys the defaults do not declare are dropped on purpose (S7).
948 1794
949 1795 return $validated;
950 1796 }
951 1797 }