Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter mailformike1at

    (@mailformike1at)

    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 at wp-login.php or /log-in/, typically via the [user_registration_login] shortcode.

    In each case, the following is true:

    • The user-registration plugin 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() or wp_authenticate_user filter path that includes wp_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,
    mike

    Thread Starter mailformike1at

    (@mailformike1at)

    Hi Amrit,
    We’ve confirmed that in standard WordPress, wp_signon()wp_authenticate_username_password() does not trigger wp_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
    Thread Starter mailformike1at

    (@mailformike1at)

    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 with rememberme, username, and password, 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?

    Thread Starter mailformike1at

    (@mailformike1at)

    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 like username and password and 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!
    Thread Starter mailformike1at

    (@mailformike1at)

    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’s ur_process_login() calling wp_signon() which ends up invoking wp_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.

    Thread Starter mailformike1at

    (@mailformike1at)

    Dear Amrit,

    We are still facing unexpected wp_set_password() Calls During Login

    We’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 call wp_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

Viewing 6 replies - 1 through 6 (of 6 total)