wp_update_user anyway sending email even user password did not change

[librapan]

It would be located on wp-inlcudes/user.php just within the function wp_update_user (around line 1798)

$user_obj = get_userdata($ID);
    if (!$user_obj) {
        return new WP_Error('invalid_user_id', __('Invalid user ID.'));
    }

    $user = $user_obj->to_array();

    // Add additional custom fields
    foreach (_get_additional_user_keys($user_obj) as $key) {
        $user[$key] = get_user_meta($ID, $key, true);
    }

    // Escape data pulled from DB.
    $user = add_magic_quotes($user);

    if (!empty($userdata['user_pass']) && $userdata['user_pass'] !== $user_obj->user_pass) {
        // If password is changing, hash it now
        $plaintext_pass        = $userdata['user_pass'];
        $userdata['user_pass'] = wp_hash_password($userdata['user_pass']);

        /**
         * Filter whether to send the password change email.
         *
         * @since 4.3.0
         *
         * @see   wp_insert_user() For `$user` and `$userdata` fields.
         *
         * @param bool  $send     Whether to send the email.
         * @param array $user     The original user array.
         * @param array $userdata The updated user array.
         *
         */
        $send_password_change_email = apply_filters('send_password_change_email', true, $user, $userdata);
    }

Since $user_obj is retured by get_userdata();, the $user_obj->user_pass will be hashed password, however the $userdata['user_pass'] will be in plain text. As a result, even the password passing into is the same as database, an Notice of Password Change email will still be triggered.

I would suggest convert the $userdata['user_pass'] to be hashed before comparing with $user_obj->user_pass

[librapan]

I would suggest change line 1758 from

$send_password_change_email = apply_filters( 'send_password_change_email', true, $user, $userdata );

to

if ($userdata['user_pass'] !== $user_obj->user_pass) {
    $send_password_change_email = apply_filters( 'send_password_change_email', true, $user, $userdata );
}

[johnbillion]

Thanks for the report, @librapan.

I'm unable to reproduce this issue unless the user_pass property is included in the data passed to wp_update_user().

This logic means the email will only be sent when $userdata['user_pass'] has a non-empty value.

Can you check your code please? If you think there's still a bug here, feel free to re-open this ticket.