mailformike1at
Forum Replies Created
-
Hi Amrit,
Thank you for your earlier reply. We have conducted further investigation using a custom MU plugin that logs detailed traces of all password reset operations, including:- All plugins involved at the time of reset (via
get_included_files()). - All hook names triggered around login, authentication, or password reset.
- Direct evidence of
wp_set_password()being called during login.
We have now observed several instances where
wp_set_password()is called during login—not via the expected password reset workflow. These resets are occurring atwp-login.phpor/log-in/, typically via the[user_registration_login]shortcode.In each case, the following is true:
- The
user-registrationplugin is loaded. - The
UR_Form_Handler::process_login()function is part of the stack. - The password reset is not user-initiated (the user reports surprise).
- The
wp_set_password()call is traceable and originates during login processing.
We believe this narrows the cause to a
wp_signon()orwp_authenticate_userfilter path that includeswp_set_password()under certain conditions—potentially triggered unintentionally by the User Registration plugin’s login handler.Could you kindly review this behavior on your end, especially within:
ur_process_login()UR_Form_Handler::process_login()- any filters or actions altering authentication that could result in a
wp_set_password()call?
We are happy to share sanitized stack traces and plugin logs if needed.
Best regards,
mikeHi Amrit,
We’ve confirmed that in standard WordPress,wp_signon()→wp_authenticate_username_password()does not triggerwp_set_password()during login.Your plugin seems to be either:
- Calling
wp_set_password()manually, or - Hooking into authentication in a way that rewrites passwords during failed login attempts.
This is not password rehashing — this is password replacement, which is a security risk.
Please clarify:
- Why is
wp_set_password()ever called during login? - Under what conditions does your plugin decide to rewrite a user’s password?
thanks,
Mike
Thank you for confirming the password rehashing behavior.
However, in our logs we see that
wp_set_password()is being triggered on login attempts — not just during real password reset flows. This includes requests withrememberme,username, andpassword, but no reset key or reset form context. This leads to actual password overwrites.We are only using your login shortcode — no registration, reset, or account edit forms.
Can you please investigate whether your login form or handler could, under some conditions, call
wp_set_password()unintentionally?We’ve now confirmed that in several cases,
wp_set_password()is triggered during regular login attempts, not through any reset form. These POST requests contain typical login params likeusernameandpasswordand rememberme, and target the/log-in/endpoint. Yet they end up calling:ur_process_login() → wp_signon() → wp_authenticate_username_password() → wp_set_password()
This results in users’ passwords being silently overwritten, which:
- Breaks expected login behavior.
- Causes confusion or lockouts.
- Potentially opens up security issues (e.g., brute-force overwrites).
We are not using registration forms, password reset forms, or automatic account creation. This plugin is used only for login.
Can you confirm:
- Why
wp_set_password()is called during login attempts? - Whether there is any fallback login logic (e.g., forceful account repair)?
- How to safely disable this behavior?
Thank you!
We’ve now captured a concrete example showing
wp_set_password()being triggered during a normal login form POST request. This occurred without any user-initiated password reset flow. The trace clearly shows your plugin’sur_process_login()callingwp_signon()which ends up invokingwp_set_password().Full request and trace are available upon request. We’re hoping you can help identify why your plugin would change the user’s password during a login attempt.
Dear Amrit,
We are still facing unexpectedwp_set_password()Calls During LoginWe’re experiencing unexpected password change behavior on our multisite setup and are still investigating the root cause. Your plugin is currently used only for the frontend login form via shortcode — no registration, reset, or profile editing features are in use.
We’ve implemented a custom MU plugin to trace password change events across our WordPress installation. It logs stack traces, request metadata, and request origins whenever
wp_set_password()or related functions are triggered.So far, we’ve identified that for some users, a call to
wp_set_password()is being triggered during what appears to be a normal login flow — even when no password reset was requested by the user.Here is a sample from the log trace:
[2025-06-09 15:12:26][78.137.144.142] wp_set_password used for [email protected]
Trace: 5 wp-includes/user.php(225): wp_set_password() 6 wp-includes/class-wp-hook.php(324): wp_authenticate_username_password() 10 plugins/user-registration/includes/functions-ur-core.php(4176): wp_signon() 11 plugins/user-registration/includes/class-ur-form-handler.php(516): ur_process_login()
This suggests the plugin may be triggering a password update internally under certain conditions during login — possibly tied to validation, login synchronization, or internal recovery logic.Key Contex
- We do not use your password reset flow or registration flow — only the login form shortcode.
- Our MU plugin proves the call originates inside your plugin’s
ur_process_login()call stack. - Users receive WordPress’s default password change notification, without requesting a reset.
- WooCommerce/FunnelKit automations are disabled, and no other plugin appears involved.
Request
Could you please clarify:
- Under what conditions
ur_process_login()might callwp_set_password()? - Whether the plugin has any fallback or auto-reset mechanisms when login attempts fail?
- Any filter, setting, or internal logic that might be forcing this behavior?
We’d appreciate any insights or workarounds you could provide. We’re happy to assist with further diagnostics.
Best regards,
Mike - All plugins involved at the time of reset (via