| @@ -101,9 +101,9 @@ | ||
| 101 | 101 | // Check lockout before authentication |
| 102 | 102 | add_filter( 'authenticate', array( $this, 'check_lockout' ), 30, 3 ); |
| 103 | 103 | |
| 104 | 104 | // Track login attempts |
| 105 | - add_action( 'wp_login_failed', array( $this, 'handle_failed_login' ) ); | |
| 105 | + add_action( 'wp_login_failed', array( $this, 'handle_failed_login' ), 10, 2 ); | |
| 106 | 106 | add_action( 'wp_login', array( $this, 'handle_successful_login' ), 10, 2 ); |
| 107 | 107 | |
| 108 | 108 | // Hide login errors |
| 109 | 109 | if ( ! empty( $this->options['hide_login_errors'] ) ) { |
| @@ -472,14 +472,49 @@ | ||
| 472 | 472 | if ( defined( 'VIGILANTE_CUSTOM_LOGIN' ) && VIGILANTE_CUSTOM_LOGIN ) { |
| 473 | 473 | return; |
| 474 | 474 | } |
| 475 | 475 | |
| 476 | - // Allow POST requests (form submissions) | |
| 476 | + /* | |
| 477 | + * Everything from here down reaches wp-login.php WITHOUT having gone | |
| 478 | + * through the secret address, so nothing rendered from here may carry | |
| 479 | + * it. The filters this class registers rewrite the form action and | |
| 480 | + * every login link to the slug, and wp-login.php prints them on each | |
| 481 | + * page it serves, so any request let through below handed the hidden | |
| 482 | + * address to whoever asked for it. | |
| 483 | + * | |
| 484 | + * Measured on 12 sep 2026 with the slug configured: a plain anonymous | |
| 485 | + * GET of ?action=lostpassword or ?action=retrievepassword returned it | |
| 486 | + * three times, ?password=changed twice and ?checkemail=confirm once. | |
| 487 | + * The exemptions those requests use (the allowed actions and the | |
| 488 | + * informational query strings) have been there since hiding the login | |
| 489 | + * existed, so the address was never actually hidden from anyone who | |
| 490 | + * asked for a password reset page. | |
| 491 | + * | |
| 492 | + * The first attempt at this fix dropped the filters only for POST, and | |
| 493 | + * only helped the POST with no action: the cross review of 2.11.10 | |
| 494 | + * found the four GETs and the POST to ?action=lostpassword, which still | |
| 495 | + * leaked through lostpassword_redirect. The rule is now one rule, not a | |
| 496 | + * list of shapes: came in by the slug, or the address is not emitted. | |
| 497 | + * | |
| 498 | + * A visitor with a session is the single exception, and on purpose: | |
| 499 | + * they already have access, and logging out has to land on the hidden | |
| 500 | + * address or core's redirect to ?loggedout=true would 404. | |
| 501 | + */ | |
| 502 | + if ( ! is_user_logged_in() ) { | |
| 503 | + $this->stop_emitting_custom_login_url(); | |
| 504 | + } | |
| 505 | + | |
| 506 | + /* | |
| 507 | + * A POST is let through so a remote manager such as MainWP or ManageWP | |
| 508 | + * can authenticate, which is what this exemption has always existed for. | |
| 509 | + * Authentication is unaffected by the lines above, because a successful | |
| 510 | + * login redirects to the destination and never renders this form. | |
| 511 | + */ | |
| 477 | 512 | $request_method = isset( $_SERVER['REQUEST_METHOD'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_METHOD'] ) ) : ''; |
| 478 | 513 | if ( 'POST' === $request_method ) { |
| 479 | 514 | return; |
| 480 | 515 | } |
| 481 | - | |
| 516 | + | |
| 482 | 517 | // Allow AJAX requests |
| 483 | 518 | if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) { |
| 484 | 519 | return; |
| 485 | 520 | } |
| @@ -501,8 +536,30 @@ | ||
| 501 | 536 | // phpcs:ignore WordPress.Security.NonceVerification.Recommended |
| 502 | 537 | if ( isset( $_GET['checkemail'] ) || isset( $_GET['password'] ) ) { |
| 503 | 538 | return; |
| 504 | 539 | } |
| 540 | + | |
| 541 | + /* | |
| 542 | + * A visitor in the middle of a second factor verification. Every redirect | |
| 543 | + * of that flow goes to wp_login_url(), and with the address filters | |
| 544 | + * dropped that is the plain wp-login.php, so a wrong code, an expired | |
| 545 | + * nonce or running out of attempts landed on a 404 with no way back: a | |
| 546 | + * login started by POST straight at wp-login.php could be begun but never | |
| 547 | + * finished. Found by the third cross review of 2.11.10, which measured | |
| 548 | + * 2.11.9 returning the visitor to the login form and trunk returning 404. | |
| 549 | + * | |
| 550 | + * The proof asked for is the pending session itself, not the cookie: | |
| 551 | + * a made-up token finds no transient and gets the 404 like anybody else, | |
| 552 | + * and the real one is only issued after the right password. Same key as | |
| 553 | + * the trait (trait-two-factor-session.php:91 and :201). | |
| 554 | + */ | |
| 555 | + if ( isset( $_COOKIE['vigilante_2fa_token'] ) ) { | |
| 556 | + $pending = get_transient( 'vigilante_2fa_pending_' . sanitize_text_field( wp_unslash( $_COOKIE['vigilante_2fa_token'] ) ) ); | |
| 557 | + | |
| 558 | + if ( is_array( $pending ) && ! empty( $pending['user_id'] ) ) { | |
| 559 | + return; | |
| 560 | + } | |
| 561 | + } | |
| 505 | 562 | |
| 506 | 563 | // Check if user already logged in - redirect to admin |
| 507 | 564 | if ( is_user_logged_in() ) { |
| 508 | 565 | wp_safe_redirect( admin_url() ); |
| @@ -664,12 +721,53 @@ | ||
| 664 | 721 | * @param string $register_url The register URL. |
| 665 | 722 | * @return string |
| 666 | 723 | */ |
| 667 | 724 | public function filter_register_url( $register_url ) { |
| 725 | + /* | |
| 726 | + * Not from wp-signup.php. On a single site the core answers that file | |
| 727 | + * with wp_redirect( wp_registration_url() ) and dies (wp-signup.php:39-41), | |
| 728 | + * so this filter put the secret address in the Location header of a plain | |
| 729 | + * anonymous request, outside wp-login.php and therefore out of reach of | |
| 730 | + * block_wp_login_access(), which only runs on login_init. Measured by the | |
| 731 | + * third cross review of 2.11.10; present since hiding the login existed. | |
| 732 | + * | |
| 733 | + * Left unfiltered, that redirect lands on wp-login.php?action=register, | |
| 734 | + * which the blocker answers with the same 404 as any other direct visit, | |
| 735 | + * which is what hiding the login is for. The registration link served on | |
| 736 | + * the login page itself is rendered under the slug, where this filter goes | |
| 737 | + * on doing its job. | |
| 738 | + */ | |
| 739 | + if ( $this->request_is_signup() ) { | |
| 740 | + return $register_url; | |
| 741 | + } | |
| 742 | + | |
| 668 | 743 | return add_query_arg( 'action', 'register', home_url( $this->custom_login_slug . '/' ) ); |
| 669 | 744 | } |
| 670 | 745 | |
| 671 | 746 | /** |
| 747 | + * Whether this request is being served by wp-signup.php or wp-activate.php | |
| 748 | + * | |
| 749 | + * @since 2.11.10 | |
| 750 | + * | |
| 751 | + * @return bool | |
| 752 | + */ | |
| 753 | + private function request_is_signup() { | |
| 754 | + foreach ( array( 'SCRIPT_NAME', 'PHP_SELF', 'SCRIPT_FILENAME' ) as $key ) { | |
| 755 | + if ( empty( $_SERVER[ $key ] ) ) { | |
| 756 | + continue; | |
| 757 | + } | |
| 758 | + | |
| 759 | + $file = basename( sanitize_text_field( wp_unslash( $_SERVER[ $key ] ) ) ); | |
| 760 | + | |
| 761 | + if ( 'wp-signup.php' === $file || 'wp-activate.php' === $file ) { | |
| 762 | + return true; | |
| 763 | + } | |
| 764 | + } | |
| 765 | + | |
| 766 | + return false; | |
| 767 | + } | |
| 768 | + | |
| 769 | + /** | |
| 672 | 770 | * Redirect after a successful lost-password request to the custom login URL |
| 673 | 771 | * |
| 674 | 772 | * Without this filter, core sends the user to wp-login.php?checkemail=confirm, |
| 675 | 773 | * which 404s when the custom login URL is enabled (block_wp_login_access only |
| @@ -862,8 +960,14 @@ | ||
| 862 | 960 | 'warning' |
| 863 | 961 | ); |
| 864 | 962 | } |
| 865 | 963 | |
| 964 | + // This rejection is ours, not a wrong password. wp_authenticate() | |
| 965 | + // still fires wp_login_failed for it, and until 2.11.0 that counted | |
| 966 | + // the blocked attempt as one more failure, which rewrote the row's | |
| 967 | + // status and produced a fresh lockout, with its critical entry and | |
| 968 | + // its email, on every POST made during the lockout (S8). The error | |
| 969 | + // code below is what handle_failed_login() reads to leave it alone. | |
| 866 | 970 | return new WP_Error( |
| 867 | 971 | 'vigilante_lockout', |
| 868 | 972 | sprintf( |
| 869 | 973 | /* translators: %d: Minutes remaining */ |
| @@ -876,15 +980,56 @@ | ||
| 876 | 980 | return $user; |
| 877 | 981 | } |
| 878 | 982 | |
| 879 | 983 | /** |
| 984 | + * Error codes of the refusals Vigilant issues itself | |
| 985 | + * | |
| 986 | + * WordPress treats every WP_Error out of the authenticate chain as a failed | |
| 987 | + * login and fires wp_login_failed for it (wp-includes/pluggable.php, | |
| 988 | + * wp_authenticate()). These seven are not wrong passwords: the credentials | |
| 989 | + * were right and Vigilant stopped the login for a reason of its own, so none | |
| 990 | + * of them counts towards the brute force lockout. | |
| 991 | + * | |
| 992 | + * The rejection identifies itself by the error code it carries. Until | |
| 993 | + * 2.11.12 each one instead added a filter that stayed registered for the | |
| 994 | + * rest of the request, which meant that one controlled rejection stopped | |
| 995 | + * every later failed login of the same request from being counted: measured | |
| 996 | + * on 17 Sep 2026, three wrong passwords for a different account, sent in the | |
| 997 | + * same request, none of them recorded. A single XML-RPC system.multicall is | |
| 998 | + * enough to make that one request. | |
| 999 | + * | |
| 1000 | + * @since 2.11.12 | |
| 1001 | + * | |
| 1002 | + * @var string[] | |
| 1003 | + */ | |
| 1004 | + const CONTROLLED_REJECTIONS = array( | |
| 1005 | + 'vigilante_2fa_required', // Two factor asked for, by app or by email. | |
| 1006 | + 'vigilante_lockout', // This address is already locked out. | |
| 1007 | + 'vigilante_force_reset', // An administrator forced a password reset. | |
| 1008 | + 'vigilante_password_expired', // Password expiry policy, over XML-RPC. | |
| 1009 | + 'pending_approval', // Registration awaiting approval. | |
| 1010 | + 'session_limit_exceeded', // Too many sessions already open. | |
| 1011 | + 'email_not_verified', // Email address not verified yet. | |
| 1012 | + ); | |
| 1013 | + | |
| 1014 | + /** | |
| 880 | 1015 | * Handle failed login attempt |
| 881 | 1016 | * |
| 882 | - * @param string $username Username that failed. | |
| 1017 | + * @since 2.11.12 Receives the WP_Error, so a refusal of Vigilant's own is told | |
| 1018 | + * apart from a wrong password by what it is and not by a flag | |
| 1019 | + * left behind for the rest of the request. | |
| 1020 | + * | |
| 1021 | + * @param string $username Username that failed. | |
| 1022 | + * @param WP_Error|null $error The error WordPress is reporting, if any. | |
| 883 | 1023 | */ |
| 884 | - public function handle_failed_login( $username ) { | |
| 885 | - // Skip counting if this is a Vigilante-controlled rejection | |
| 886 | - // (pending approval, session limit, email verification, etc.) | |
| 1024 | + public function handle_failed_login( $username, $error = null ) { | |
| 1025 | + // A refusal of ours, not a wrong password. | |
| 1026 | + if ( $error instanceof WP_Error && array_intersect( $error->get_error_codes(), self::CONTROLLED_REJECTIONS ) ) { | |
| 1027 | + return; | |
| 1028 | + } | |
| 1029 | + | |
| 1030 | + // Kept for anything outside the plugin that marks its own controlled | |
| 1031 | + // rejection. Nothing inside Vigilant sets it any more. | |
| 887 | 1032 | if ( apply_filters( 'vigilante_skip_failed_login_count', false ) ) { |
| 888 | 1033 | return; |
| 889 | 1034 | } |
| 890 | 1035 | |
| @@ -933,8 +1078,15 @@ | ||
| 933 | 1078 | // Get failed attempts in the last hour |
| 934 | 1079 | $failed_count = $this->database->get_failed_attempt_count( $ip, 60 ); |
| 935 | 1080 | |
| 936 | 1081 | if ( $failed_count >= $max_attempts ) { |
| 1082 | + // Already locked out: every further POST during the lockout used to | |
| 1083 | + // write another critical entry and send another email (S8). The | |
| 1084 | + // lockout itself is what check_lockout() enforces; nothing to add. | |
| 1085 | + if ( $this->database->is_locked_out( $ip ) ) { | |
| 1086 | + return; | |
| 1087 | + } | |
| 1088 | + | |
| 937 | 1089 | // Calculate lockout duration with increment |
| 938 | 1090 | if ( ! empty( $this->options['lockout_increment'] ) ) { |
| 939 | 1091 | $previous_lockouts = $this->get_previous_lockout_count( $ip ); |
| 940 | 1092 | $lockout_duration = min( |
| @@ -1116,11 +1268,13 @@ | ||
| 1116 | 1268 | // Login Security |
| 1117 | 1269 | 'vigilante_lockout', |
| 1118 | 1270 | // User Security |
| 1119 | 1271 | 'vigilante_force_reset', |
| 1120 | - 'pending_approval', | |
| 1121 | - 'email_not_verified', | |
| 1122 | - 'session_limit_exceeded', | |
| 1272 | + // pending_approval, email_not_verified and session_limit_exceeded | |
| 1273 | + // are deliberately NOT here since 2.11.0: they are only raised once | |
| 1274 | + // the password is correct, so letting them through told an | |
| 1275 | + // unauthenticated visitor which accounts exist (S10). Those users | |
| 1276 | + // learn their status from the registration and verification emails. | |
| 1123 | 1277 | // Two-Factor Email |
| 1124 | 1278 | 'no_code', |
| 1125 | 1279 | 'code_expired', |
| 1126 | 1280 | 'code_used', |
| @@ -1178,14 +1332,10 @@ | ||
| 1178 | 1332 | // Note: this fallback won't match on translated sites — the |
| 1179 | 1333 | // code-based check above is the locale-safe path. |
| 1180 | 1334 | $allowed_patterns = array( |
| 1181 | 1335 | 'vigilante_lockout', |
| 1182 | - 'Account pending', | |
| 1183 | - 'pending_approval', | |
| 1184 | - 'email_not_verified', | |
| 1185 | - 'verify your email', | |
| 1186 | - 'session_limit', | |
| 1187 | - 'too many active', | |
| 1336 | + // The pending-approval, unverified-email and session-limit strings | |
| 1337 | + // were removed in 2.11.0 for the same reason as their codes above (S10). | |
| 1188 | 1338 | 'verification code', |
| 1189 | 1339 | 'authenticator app', |
| 1190 | 1340 | 'two-factor', |
| 1191 | 1341 | 'grace period', |
| @@ -1210,15 +1360,15 @@ | ||
| 1210 | 1360 | * @return array |
| 1211 | 1361 | */ |
| 1212 | 1362 | public function remove_shake_errors( $codes ) { |
| 1213 | 1363 | // Keep shake for Vigilante-specific errors that indicate real problems |
| 1214 | - // Do NOT include 2FA codes - the form transition should be smooth | |
| 1364 | + // Do NOT include 2FA codes - the form transition should be smooth. | |
| 1365 | + // The three account-status codes are not here either since 2.11.0: a | |
| 1366 | + // shake that only plays for existing accounts is the same tell as the | |
| 1367 | + // message it replaced (S10). | |
| 1215 | 1368 | return array( |
| 1216 | 1369 | 'vigilante_lockout', |
| 1217 | 1370 | 'vigilante_force_reset', |
| 1218 | - 'pending_approval', | |
| 1219 | - 'email_not_verified', | |
| 1220 | - 'session_limit_exceeded', | |
| 1221 | 1371 | ); |
| 1222 | 1372 | } |
| 1223 | 1373 | |
| 1224 | 1374 | |
| @@ -1287,9 +1437,9 @@ | ||
| 1287 | 1437 | __( 'Failed attempts', 'vigilante' ) => (string) $attempts, |
| 1288 | 1438 | __( 'Lockout duration', 'vigilante' ) => ceil( $duration / 60 ) . ' ' . __( 'minutes', 'vigilante' ), |
| 1289 | 1439 | __( 'Date/Time', 'vigilante' ) => wp_date( get_option( 'date_format' ) . ' ' . get_option( 'time_format' ) ), |
| 1290 | 1440 | ) ); |
| 1291 | - $body .= Vigilante_Email_Template::button( admin_url( 'admin.php?page=vigilante&tab=login' ), __( 'View lockouts', 'vigilante' ) ); | |
| 1441 | + $body .= Vigilante_Email_Template::button( admin_url( 'admin.php?page=vigilante&tab=login#vigilante-section-login-status' ), __( 'View lockouts', 'vigilante' ) ); | |
| 1292 | 1442 | |
| 1293 | 1443 | Vigilante_Email_Template::send( $to, $subject, __( 'Login lockout triggered', 'vigilante' ), $body, true ); |
| 1294 | 1444 | } |
| 1295 | 1445 | |
| @@ -1494,8 +1644,36 @@ | ||
| 1494 | 1644 | * blockers already let every POST through, which is how they authenticate. |
| 1495 | 1645 | * |
| 1496 | 1646 | * @return bool |
| 1497 | 1647 | */ |
| 1648 | + /** | |
| 1649 | + * Stop this request from putting the secret login address in any URL | |
| 1650 | + * | |
| 1651 | + * The filters that rewrite a WordPress login URL into the custom slug are | |
| 1652 | + * what makes the feature work, and also what leaks it the moment a page is | |
| 1653 | + * rendered on a path the visitor was not supposed to reach. Dropping them | |
| 1654 | + * for the rest of the request keeps whatever renders afterwards free of the | |
| 1655 | + * slug, while everything else about the request goes on as before. | |
| 1656 | + * | |
| 1657 | + * The two redirect filters are here because the first version of this list | |
| 1658 | + * had only the five URL ones, and a POST to ?action=lostpassword still | |
| 1659 | + * handed the address over in the hidden redirect_to field that | |
| 1660 | + * lostpassword_redirect fills. Found by the cross review of 2.11.10. Any | |
| 1661 | + * filter of this class that can put the slug in front of a visitor belongs | |
| 1662 | + * in this list; if a new one is added, add it here too. | |
| 1663 | + * | |
| 1664 | + * @since 2.11.10 | |
| 1665 | + */ | |
| 1666 | + private function stop_emitting_custom_login_url() { | |
| 1667 | + remove_filter( 'site_url', array( $this, 'filter_site_url' ), 10 ); | |
| 1668 | + remove_filter( 'login_url', array( $this, 'filter_login_url' ), 10 ); | |
| 1669 | + remove_filter( 'logout_url', array( $this, 'filter_logout_url' ), 10 ); | |
| 1670 | + remove_filter( 'lostpassword_url', array( $this, 'filter_lostpassword_url' ), 10 ); | |
| 1671 | + remove_filter( 'register_url', array( $this, 'filter_register_url' ), 10 ); | |
| 1672 | + remove_filter( 'lostpassword_redirect', array( $this, 'filter_lostpassword_redirect' ), 10 ); | |
| 1673 | + remove_filter( 'logout_redirect', array( $this, 'filter_logout_redirect' ), 10 ); | |
| 1674 | + } | |
| 1675 | + | |
| 1498 | 1676 | private function is_ip_exempt_from_hiding() { |
| 1499 | 1677 | $whitelist = $this->settings->get_option( 'firewall', 'ip_whitelist', array() ); |
| 1500 | 1678 | |
| 1501 | 1679 | if ( empty( $whitelist ) ) { |
| @@ -1537,43 +1715,8 @@ | ||
| 1537 | 1715 | public function get_locked_out_ips() { |
| 1538 | 1716 | return $this->database->get_locked_out_ips(); |
| 1539 | 1717 | } |
| 1540 | 1718 | |
| 1541 | - /** | |
| 1542 | - * Get login statistics | |
| 1543 | - * | |
| 1544 | - * @param int $days Days to look back. | |
| 1545 | - * @return array | |
| 1546 | - */ | |
| 1547 | - public function get_statistics( $days = 7 ) { | |
| 1548 | - global $wpdb; | |
| 1549 | - | |
| 1550 | - $table = esc_sql( $this->database->get_login_attempts_table() ); | |
| 1551 | - $since = gmdate( 'Y-m-d H:i:s', strtotime( "-{$days} days" ) ); | |
| 1552 | - | |
| 1553 | - // phpcs:disable WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,WordPress.DB.PreparedSQL.InterpolatedNotPrepared | |
| 1554 | - $stats = $wpdb->get_row( | |
| 1555 | - $wpdb->prepare( | |
| 1556 | - "SELECT | |
| 1557 | - COUNT(CASE WHEN status = 'failed' THEN 1 END) as failed_attempts, | |
| 1558 | - COUNT(CASE WHEN status = 'lockout' THEN 1 END) as lockouts, | |
| 1559 | - COUNT(DISTINCT ip_address) as unique_ips, | |
| 1560 | - COUNT(DISTINCT username) as unique_usernames | |
| 1561 | - FROM `{$table}` | |
| 1562 | - WHERE last_attempt >= %s", | |
| 1563 | - $since | |
| 1564 | - ), | |
| 1565 | - ARRAY_A | |
| 1566 | - ); | |
| 1567 | - // phpcs:enable | |
| 1568 | - | |
| 1569 | - return $stats ? $stats : array( | |
| 1570 | - 'failed_attempts' => 0, | |
| 1571 | - 'lockouts' => 0, | |
| 1572 | - 'unique_ips' => 0, | |
| 1573 | - 'unique_usernames' => 0, | |
| 1574 | - ); | |
| 1575 | - } | |
| 1576 | 1719 | } |
| 1577 | 1720 | |
| 1578 | 1721 | /** |
| 1579 | 1722 | * Disabled XML-RPC Server class |
