Two behaviors that compound, both reachable today without any enforcement feature. Line references are against master at 6245be6.
Two_Factor_Core::user_two_factor_options_update() calls wp_destroy_other_sessions() when a user enables 2FA for the first time (class-two-factor-core.php:2560). If an administrator enables it on another user's behalf, that user's sessions are destroyed via WP_Session_Tokens::destroy_all() instead.
Separately, no mail is sent when a factor is enrolled. wp_mail() appears in only two places, both in the compromised-password path (class-two-factor-core.php:2041 and :2077).
Together: enrolling a second factor silently logs the account owner out of every other session, with no notification that anything changed. From the owner's side this is indistinguishable from a random logout.
This matters most where someone other than the owner does the enrolling. There's an asymmetry worth noting — the plugin already mails the user and optionally the site admin when a compromised password is reset, with a two_factor_notify_admin_user_password_reset filter to control it. Enrolling a second factor is arguably a comparable account-security event and currently gets nothing.
Suggested: send a notification to the account address on provider enrollment and removal, following the existing filter pattern.
Two behaviors that compound, both reachable today without any enforcement feature. Line references are against
masterat 6245be6.Two_Factor_Core::user_two_factor_options_update()callswp_destroy_other_sessions()when a user enables 2FA for the first time (class-two-factor-core.php:2560). If an administrator enables it on another user's behalf, that user's sessions are destroyed viaWP_Session_Tokens::destroy_all()instead.Separately, no mail is sent when a factor is enrolled.
wp_mail()appears in only two places, both in the compromised-password path (class-two-factor-core.php:2041and:2077).Together: enrolling a second factor silently logs the account owner out of every other session, with no notification that anything changed. From the owner's side this is indistinguishable from a random logout.
This matters most where someone other than the owner does the enrolling. There's an asymmetry worth noting — the plugin already mails the user and optionally the site admin when a compromised password is reset, with a
two_factor_notify_admin_user_password_resetfilter to control it. Enrolling a second factor is arguably a comparable account-security event and currently gets nothing.Suggested: send a notification to the account address on provider enrollment and removal, following the existing filter pattern.