[wp-trac] [WordPress Trac] #65144: Passwords: trim() asymmetry between wp_hash_password() and wp_check_password() introduced in 6.8

WordPress Trac noreply at wordpress.org
Wed Apr 29 06:42:47 UTC 2026


#65144: Passwords: trim() asymmetry between wp_hash_password() and
wp_check_password() introduced in 6.8
--------------------------+------------------------------
 Reporter:  mkultraware   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  6.8
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by hbhalodia):

 Hi @mkultraware, Thanks for the ticket. I can verify indeed it's an issue.

 For a quick check for the usecase, we can use the below snipped as a
 plugin and test it out.

 {{{

 add_action( 'init', function() {
         $hashed   = wp_hash_password( '     password-to-hash.    ' );
         $to_check = wp_check_password( '     password-to-hash.    ',
 $hashed );

         var_dump( $to_check );
         wp_die();
 });

 }}}

 The output would be `bool(false)`, instead it should be `bool(true)`. This
 is because, `wp_check_password` is not handling the leading/trailing
 spaces as how `wp_hash_password` does while hashing the password.

 To handle is properly for all the usecases, Instead of just adding trim to
 line `2858`, we should add the trim to all passwords IMO, but since
 `wp_hash_password` adds a unique prefix, then wp_check_password will
 satisfy the condition on line, `2856: elseif ( str_starts_with( $hash,
 '$wp' ) ) {`, So for adding a patch currently, I am adding it specifically
 for the if condition, but we can handle that in PR review and update as
 needed.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65144#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list