← All changes | includes/class-login-security.php +353 -77 2.9.7 → 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'] ) ) {
		@@ -211,11 +211,11 @@
211	211	$request = isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
212	212
213	213
214	214	// If accessing wp-admin and being redirected to login, show 404 instead
215		- if ( $this->is_wp_admin_request() ) {
	215	+ if ( self::is_wp_admin_request() ) {
216	216	// Don't intercept admin-ajax.php or admin-post.php
217		- if ( $this->is_open_admin_endpoint() ) {
	217	+ if ( self::is_open_admin_endpoint() ) {
218	218	return $location;
219	219	}
220	220
221	221	// Allow whitelisted IPs (e.g. remote managers like MainWP/ManageWP).
		@@ -275,9 +275,9 @@
275	275	*
276	276	* @since 2.9.4
277	277	* @return string
278	278	*/
279		- private function get_request_uri_path() {
	279	+ private static function get_request_uri_path() {
280	280	$request = isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
281	281
282	282	if ( '' === $request ) {
283	283	return '';
		@@ -309,14 +309,14 @@
309	309	*
310	310	* @since 2.9.4
311	311	* @return bool
312	312	*/
313		- private function is_wp_admin_request() {
	313	+ private static function is_wp_admin_request() {
314	314	if ( is_admin() ) {
315	315	return true;
316	316	}
317	317
318		- $path = $this->get_request_uri_path();
	318	+ $path = self::get_request_uri_path();
319	319
320	320	if ( '' === $path ) {
321	321	return false;
322	322	}
		@@ -347,10 +347,10 @@
347	347	*
348	348	* @since 2.9.4
349	349	* @return bool
350	350	*/
351		- private function is_open_admin_endpoint() {
352		- $path = $this->get_request_uri_path();
	351	+ private static function is_open_admin_endpoint() {
	352	+ $path = self::get_request_uri_path();
353	353
354	354	if ( '' === $path ) {
355	355	return false;
356	356	}
		@@ -387,14 +387,14 @@
387	387	$request = isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
388	388
389	389
390	390	// Check if accessing wp-admin
391		- if ( ! $this->is_wp_admin_request() ) {
	391	+ if ( ! self::is_wp_admin_request() ) {
392	392	return;
393	393	}
394	394
395	395	// Allow admin-ajax.php and admin-post.php
396		- if ( $this->is_open_admin_endpoint() ) {
	396	+ if ( self::is_open_admin_endpoint() ) {
397	397	return;
398	398	}
399	399
400	400	// Allow if user is logged in
		@@ -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() );
		@@ -508,14 +565,8 @@
508	565	wp_safe_redirect( admin_url() );
509	566	exit;
510	567	}
511	568
512		- // Allow whitelisted IPs (e.g. remote managers like MainWP/ManageWP).
513		- if ( $this->is_ip_exempt_from_hiding() ) {
514		- return;
515		- }
516		-
517		-
518	569	// Log the attempt
519	570	if ( $this->activity_log ) {
520	571	$request = isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
521	572	$this->activity_log->log(
		@@ -554,13 +605,8 @@
554	605	if ( ! in_array( $request, array( 'login', 'wp-login.php' ), true ) ) {
555	606	return;
556	607	}
557	608
558		- // Allow whitelisted IPs (e.g. remote managers like MainWP/ManageWP).
559		- if ( $this->is_ip_exempt_from_hiding() ) {
560		- return;
561		- }
562		-
563	609	if ( $this->activity_log ) {
564	610	$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
565	611	$this->activity_log->log(
566	612	'login',
		@@ -675,12 +721,53 @@
675	721	* @param string $register_url The register URL.
676	722	* @return string
677	723	*/
678	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	+
679	743	return add_query_arg( 'action', 'register', home_url( $this->custom_login_slug . '/' ) );
680	744	}
681	745
682	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	+ /**
683	770	* Redirect after a successful lost-password request to the custom login URL
684	771	*
685	772	* Without this filter, core sends the user to wp-login.php?checkemail=confirm,
686	773	* which 404s when the custom login URL is enabled (block_wp_login_access only
		@@ -873,8 +960,14 @@
873	960	'warning'
874	961	);
875	962	}
876	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.
877	970	return new WP_Error(
878	971	'vigilante_lockout',
879	972	sprintf(
880	973	/* translators: %d: Minutes remaining */
		@@ -887,15 +980,56 @@
887	980	return $user;
888	981	}
889	982
890	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	+ /**
891	1015	* Handle failed login attempt
892	1016	*
893		- * @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.
894	1023	*/
895		- public function handle_failed_login( $username ) {
896		- // Skip counting if this is a Vigilante-controlled rejection
897		- // (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.
898	1032	if ( apply_filters( 'vigilante_skip_failed_login_count', false ) ) {
899	1033	return;
900	1034	}
901	1035
		@@ -944,8 +1078,15 @@
944	1078	// Get failed attempts in the last hour
945	1079	$failed_count = $this->database->get_failed_attempt_count( $ip, 60 );
946	1080
947	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	+
948	1089	// Calculate lockout duration with increment
949	1090	if ( ! empty( $this->options['lockout_increment'] ) ) {
950	1091	$previous_lockouts = $this->get_previous_lockout_count( $ip );
951	1092	$lockout_duration = min(
		@@ -1127,11 +1268,13 @@
1127	1268	// Login Security
1128	1269	'vigilante_lockout',
1129	1270	// User Security
1130	1271	'vigilante_force_reset',
1131		- 'pending_approval',
1132		- 'email_not_verified',
1133		- '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.
1134	1277	// Two-Factor Email
1135	1278	'no_code',
1136	1279	'code_expired',
1137	1280	'code_used',
		@@ -1189,14 +1332,10 @@
1189	1332	// Note: this fallback won't match on translated sites — the
1190	1333	// code-based check above is the locale-safe path.
1191	1334	$allowed_patterns = array(
1192	1335	'vigilante_lockout',
1193		- 'Account pending',
1194		- 'pending_approval',
1195		- 'email_not_verified',
1196		- 'verify your email',
1197		- 'session_limit',
1198		- '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).
1199	1338	'verification code',
1200	1339	'authenticator app',
1201	1340	'two-factor',
1202	1341	'grace period',
		@@ -1221,15 +1360,15 @@
1221	1360	* @return array
1222	1361	*/
1223	1362	public function remove_shake_errors( $codes ) {
1224	1363	// Keep shake for Vigilante-specific errors that indicate real problems
1225		- // 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).
1226	1368	return array(
1227	1369	'vigilante_lockout',
1228	1370	'vigilante_force_reset',
1229		- 'pending_approval',
1230		- 'email_not_verified',
1231		- 'session_limit_exceeded',
1232	1371	);
1233	1372	}
1234	1373
1235	1374
		@@ -1298,9 +1437,9 @@
1298	1437	__( 'Failed attempts', 'vigilante' ) => (string) $attempts,
1299	1438	__( 'Lockout duration', 'vigilante' ) => ceil( $duration / 60 ) . ' ' . __( 'minutes', 'vigilante' ),
1300	1439	__( 'Date/Time', 'vigilante' ) => wp_date( get_option( 'date_format' ) . ' ' . get_option( 'time_format' ) ),
1301	1440	) );
1302		- $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' ) );
1303	1442
1304	1443	Vigilante_Email_Template::send( $to, $subject, __( 'Login lockout triggered', 'vigilante' ), $body, true );
1305	1444	}
1306	1445
		@@ -1350,10 +1489,143 @@
1350	1489	return Vigilante_IP_Utils::in_list( $ip, $whitelist );
1351	1490	}
1352	1491
1353	1492	/**
	1493	+ * Turn away an anonymous wp-admin request before WordPress finishes booting
	1494	+ *
	1495	+ * The modules are built on init priority 1, so a request that was going to
	1496	+ * be refused had already paid for the whole boot: the theme, every plugin
	1497	+ * and every init callback. Measured on a real site, a rejected
	1498	+ * /wp-admin/index.php cost as much as serving a page.
	1499	+ *
	1500	+ * Only the case that can be judged with certainty this early is handled
	1501	+ * here, an anonymous GET with no session cookie at all; everything else
	1502	+ * falls through to the usual path untouched. The cookie is only checked for
	1503	+ * presence: resolving the user here would run is_user_logged_in() before
	1504	+ * other plugins register their determine_current_user filters, which is how
	1505	+ * token, JWT and SSO logins are wired.
	1506	+ *
	1507	+ * @since 2.9.9
	1508	+ *
	1509	+ * @param array $options The plugin options, already read by the caller.
	1510	+ */
	1511	+ public static function maybe_block_hidden_admin_early( $options ) {
	1512	+ if ( self::is_open_admin_endpoint() ) {
	1513	+ return;
	1514	+ }
	1515	+
	1516	+ if ( '' === sanitize_title( $options['login_security']['custom_login_url'] ) ) {
	1517	+ return;
	1518	+ }
	1519	+
	1520	+ if ( self::has_session_cookie() ) {
	1521	+ return;
	1522	+ }
	1523	+
	1524	+ $whitelist = isset( $options['firewall']['ip_whitelist'] ) ? (array) $options['firewall']['ip_whitelist'] : array();
	1525	+
	1526	+ if ( ! empty( $whitelist ) && Vigilante_IP_Utils::in_list( Vigilante_IP_Utils::get_client_ip(), $whitelist ) ) {
	1527	+ return;
	1528	+ }
	1529	+
	1530	+ /*
	1531	+ * Last, and only for a request that was about to be turned away: whether
	1532	+ * anybody is actually there.
	1533	+ *
	1534	+ * A remote manager signs its own call with a token and asks for the
	1535	+ * dashboard before holding any cookie; its connector resolves the user
	1536	+ * through determine_current_user and only then, on 'init', sets the
	1537	+ * cookie and redirects. Turning the request away here, three hooks
	1538	+ * earlier, means the connector never reaches the point where it would
	1539	+ * have logged itself in, so it reads the 404 as a site that is broken
	1540	+ * and retries the whole job. Observed in the wild with
	1541	+ * ModularConnector/3.2.1, whose every request landed here.
	1542	+ *
	1543	+ * Which is also why this went unnoticed for two releases: a connector
	1544	+ * that already holds a cookie by the time it asks for the dashboard
	1545	+ * leaves at has_session_cookie() above and never reaches this line. How
	1546	+ * many connectors work that way is not something to guess at here; what
	1547	+ * is certain is that reports only came from sites where one did not.
	1548	+ *
	1549	+ * The criterion is the one block_wp_admin_access() has always applied,
	1550	+ * brought to the door 2.9.9 put in front of it. It costs nothing on the
	1551	+ * ordinary request, which left long before reaching this line, and
	1552	+ * nothing on the database either: with no cookie to validate, the three
	1553	+ * core determine_current_user callbacks all decline without a query. The
	1554	+ * rejection below already pays for an INSERT into the activity log, and
	1555	+ * resolves this very same user one step later to record who was refused.
	1556	+ */
	1557	+ if ( get_current_user_id() ) {
	1558	+ return;
	1559	+ }
	1560	+
	1561	+ self::log_early_hidden_admin_attempt();
	1562	+
	1563	+ status_header( 404 );
	1564	+ nocache_headers();
	1565	+
	1566	+ /*
	1567	+ * Deliberately not translated. This runs on plugins_loaded, where asking
	1568	+ * for a translation triggers the just in time text domain notice of
	1569	+ * WordPress 6.7 and returns the English string anyway. The reader is an
	1570	+ * anonymous request to an address that is supposed to look absent.
	1571	+ */
	1572	+ wp_die(
	1573	+ '<h1>Page not found</h1><p>The page you are looking for does not exist.</p>',
	1574	+ '404 Not Found',
	1575	+ array(
	1576	+ 'response' => 404,
	1577	+ 'back_link' => false,
	1578	+ )
	1579	+ );
	1580	+ }
	1581	+
	1582	+ /**
	1583	+ * Whether the request carries a WordPress session cookie, without resolving it
	1584	+ *
	1585	+ * @since 2.9.9
	1586	+ *
	1587	+ * @return bool
	1588	+ */
	1589	+ private static function has_session_cookie() {
	1590	+ if ( defined( 'LOGGED_IN_COOKIE' ) && isset( $_COOKIE[ LOGGED_IN_COOKIE ] ) ) {
	1591	+ return true;
	1592	+ }
	1593	+
	1594	+ foreach ( array_keys( (array) $_COOKIE ) as $name ) {
	1595	+ if ( 0 === strpos( (string) $name, 'wordpress_logged_in_' ) || 0 === strpos( (string) $name, 'wordpress_sec_' ) ) {
	1596	+ return true;
	1597	+ }
	1598	+ }
	1599	+
	1600	+ return false;
	1601	+ }
	1602	+
	1603	+ /**
	1604	+ * Record an early rejection in the activity log
	1605	+ *
	1606	+ * @since 2.9.9
	1607	+ */
	1608	+ private static function log_early_hidden_admin_attempt() {
	1609	+ require_once VIGILANTE_INCLUDES_DIR . 'class-settings.php';
	1610	+ require_once VIGILANTE_INCLUDES_DIR . 'class-database.php';
	1611	+ require_once VIGILANTE_INCLUDES_DIR . 'class-activity-log.php';
	1612	+
	1613	+ $request = isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
	1614	+
	1615	+ $activity_log = new Vigilante_Activity_Log( new Vigilante_Settings(), new Vigilante_Database() );
	1616	+ $activity_log->log(
	1617	+ 'login',
	1618	+ 'hidden_admin_access',
	1619	+ 'Attempt to access hidden wp-admin',
	1620	+ array( 'request_uri' => $request ),
	1621	+ 'warning'
	1622	+ );
	1623	+ }
	1624	+
	1625	+ /**
1354	1626	* Whether the current request comes from an IP that may bypass the
1355		- * hidden-login / hidden-wp-admin masking.
	1627	+ * hidden wp-admin masking.
1356	1628	*
1357	1629	* Reads the firewall's global IP whitelist (the visible "IP whitelist"
1358	1630	* box) so trusted services such as MainWP or ManageWP, which reach
1359	1631	* wp-admin without a WordPress session cookie, are not turned away with
		@@ -1359,10 +1631,49 @@
1359	1631	* wp-admin without a WordPress session cookie, are not turned away with
1360	1632	* a 404. This relaxes only the URL masking, never authentication: an
1361	1633	* exempt IP still has to log in normally.
1362	1634	*
	1635	+ * wp-admin only, and that is the point. Until 2.9.9 the same exemption
	1636	+ * also applied to the two wp-login.php paths, where it did not serve that
	1637	+ * purpose and did real harm: block_wp_login_access() handed the real login
	1638	+ * form to any whitelisted IP with the custom login URL active, and
	1639	+ * block_login_shortcuts() is precisely what stops core's
	1640	+ * wp_redirect_admin_locations() from answering /login with a 302 to
	1641	+ * wp_login_url(), which under a custom login URL is the secret slug. So
	1642	+ * exempting it did not merely expose the form, it handed the slug over in
	1643	+ * the Location header. Remote managers never needed either one: both
	1644	+ * blockers already let every POST through, which is how they authenticate.
	1645	+ *
1363	1646	* @return bool
1364	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	+
1365	1676	private function is_ip_exempt_from_hiding() {
1366	1677	$whitelist = $this->settings->get_option( 'firewall', 'ip_whitelist', array() );
1367	1678
1368	1679	if ( empty( $whitelist ) ) {
		@@ -1404,43 +1715,8 @@
1404	1715	public function get_locked_out_ips() {
1405	1716	return $this->database->get_locked_out_ips();
1406	1717	}
1407	1718
1408		- /**
1409		- * Get login statistics
1410		- *
1411		- * @param int $days Days to look back.
1412		- * @return array
1413		- */
1414		- public function get_statistics( $days = 7 ) {
1415		- global $wpdb;
1416		-
1417		- $table = esc_sql( $this->database->get_login_attempts_table() );
1418		- $since = gmdate( 'Y-m-d H:i:s', strtotime( "-{$days} days" ) );
1419		-
1420		- // phpcs:disable WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,WordPress.DB.PreparedSQL.InterpolatedNotPrepared
1421		- $stats = $wpdb->get_row(
1422		- $wpdb->prepare(
1423		- "SELECT
1424		- COUNT(CASE WHEN status = 'failed' THEN 1 END) as failed_attempts,
1425		- COUNT(CASE WHEN status = 'lockout' THEN 1 END) as lockouts,
1426		- COUNT(DISTINCT ip_address) as unique_ips,
1427		- COUNT(DISTINCT username) as unique_usernames
1428		- FROM `{$table}`
1429		- WHERE last_attempt >= %s",
1430		- $since
1431		- ),
1432		- ARRAY_A
1433		- );
1434		- // phpcs:enable
1435		-
1436		- return $stats ? $stats : array(
1437		- 'failed_attempts' => 0,
1438		- 'lockouts' => 0,
1439		- 'unique_ips' => 0,
1440		- 'unique_usernames' => 0,
1441		- );
1442		- }
1443	1719	}
1444	1720
1445	1721	/**
1446	1722	* Disabled XML-RPC Server class