login_limit_exceeded on expired sessions

[dougaxe1]

Expected/Desired Behavior

Expired sessions should not count as failed auth attempts towards the login limit.

Actual Behavior

If a logged in user has multiple browser windows (tabs) open in the admin and their session expires (natural timeout), each window's ajax heartbeat will trigger the wp_failed_login action with an error of expired_session which can easily exceed the login limit leading to a temporary block.

My objection is that an expired session is not a failed authentication attempt. WordPress core simply checked their login status and prompted a re-auth. security.php only checks for wp_failed_login actions without considering the type.

On sites where the wpcom_vip_ip_login_threshold is filtered, or in FedRAMP environments where the ip_login default is 5, it is easy to unintentionally exceed the threshold.

Steps to Reproduce the Problem

Setup

Add to client-mu-plugins:

// Log the lock out
add_action( 'login_limit_exceeded', function ( $username ) { error_log( 'Uh oh, now you are locked!' ); } );

// Lower the `ip_login` threshold (FedRAMP default)
add_filter( 'wpcom_vip_ip_login_threshold', function ( $threshold ) { return 5; } );

1. Login to WordPress
2. Duplicate a tab pointing to /wp-admin/ 5 times
3. From a different browser session, "Log Out Everywhere Else" / "Log Out Everywhere" or delete the user meta key to terminate the open session (or, if you're reallllly patient, wait for your WordPress session to naturally expire)
4. Wait for the next heartbeat requests in each tab and observe the debug log.
5. Optionally, submit an empty /wp-login.php form to observe the "You have exceeded the login limit. Please wait a few minutes and try again." error message.

(Optional) Additional notes

• The temporary block requires object cache locally
• In my testing, it didn't prevent a successful login from occurring during re-auth, but still fired the action (unsure if this is a separate bug which grants an additional retry)

[github-actions]

This issue has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed.

This is an automation to keep issues manageable and actionable and is not a comment on the quality of this issue nor on the work done so far. Closed issues are still valuable to the project and are available to be searched.

[dougaxe1]

Hi, this is still an issue. Can this bug be triaged?

[github-actions]

This issue has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed.

This is an automation to keep issues manageable and actionable and is not a comment on the quality of this issue nor on the work done so far. Closed issues are still valuable to the project and are available to be searched.

[dougaxe1]

Hello, still an issue.

[phillcoxon]

We have a report of another VIP customer likely experiencing this issue resulting in login difficulties while travelling in VIP ticket #189995.