← All changes | includes/class-login-security.php +176 -45 2.11.5 → 3.0.0 View file →

		@@ -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
		@@ -866,11 +964,10 @@
866	964	// This rejection is ours, not a wrong password. wp_authenticate()
867	965	// still fires wp_login_failed for it, and until 2.11.0 that counted
868	966	// the blocked attempt as one more failure, which rewrote the row's
869	967	// status and produced a fresh lockout, with its critical entry and
870		- // its email, on every POST made during the lockout (S8).
871		- add_filter( 'vigilante_skip_failed_login_count', '__return_true' );
872		-
	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.
873	970	return new WP_Error(
874	971	'vigilante_lockout',
875	972	sprintf(
876	973	/* translators: %d: Minutes remaining */
		@@ -883,15 +980,56 @@
883	980	return $user;
884	981	}
885	982
886	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	+ /**
887	1015	* Handle failed login attempt
888	1016	*
889		- * @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.
890	1023	*/
891		- public function handle_failed_login( $username ) {
892		- // Skip counting if this is a Vigilante-controlled rejection
893		- // (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.
894	1032	if ( apply_filters( 'vigilante_skip_failed_login_count', false ) ) {
895	1033	return;
896	1034	}
897	1035
		@@ -1506,8 +1644,36 @@
1506	1644	* blockers already let every POST through, which is how they authenticate.
1507	1645	*
1508	1646	* @return bool
1509	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	+
1510	1676	private function is_ip_exempt_from_hiding() {
1511	1677	$whitelist = $this->settings->get_option( 'firewall', 'ip_whitelist', array() );
1512	1678
1513	1679	if ( empty( $whitelist ) ) {
		@@ -1549,43 +1715,8 @@
1549	1715	public function get_locked_out_ips() {
1550	1716	return $this->database->get_locked_out_ips();
1551	1717	}
1552	1718
1553		- /**
1554		- * Get login statistics
1555		- *
1556		- * @param int $days Days to look back.
1557		- * @return array
1558		- */
1559		- public function get_statistics( $days = 7 ) {
1560		- global $wpdb;
1561		-
1562		- $table = esc_sql( $this->database->get_login_attempts_table() );
1563		- $since = gmdate( 'Y-m-d H:i:s', strtotime( "-{$days} days" ) );
1564		-
1565		- // phpcs:disable WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,WordPress.DB.PreparedSQL.InterpolatedNotPrepared
1566		- $stats = $wpdb->get_row(
1567		- $wpdb->prepare(
1568		- "SELECT
1569		- COUNT(CASE WHEN status = 'failed' THEN 1 END) as failed_attempts,
1570		- COUNT(CASE WHEN status = 'lockout' THEN 1 END) as lockouts,
1571		- COUNT(DISTINCT ip_address) as unique_ips,
1572		- COUNT(DISTINCT username) as unique_usernames
1573		- FROM `{$table}`
1574		- WHERE last_attempt >= %s",
1575		- $since
1576		- ),
1577		- ARRAY_A
1578		- );
1579		- // phpcs:enable
1580		-
1581		- return $stats ? $stats : array(
1582		- 'failed_attempts' => 0,
1583		- 'lockouts' => 0,
1584		- 'unique_ips' => 0,
1585		- 'unique_usernames' => 0,
1586		- );
1587		- }
1588	1719	}
1589	1720
1590	1721	/**
1591	1722	* Disabled XML-RPC Server class