[wp-trac] [WordPress Trac] #54416: Some WordPress generated emails escape special chars in the email address while other emails do not.

[WordPress Trac]

#54416: Some WordPress generated emails escape special chars in the email address
while other emails do not.
-------------------------------------------------+-------------------------
 Reporter:  ltuspe                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Mail                                 |     Version:  5.8
 Severity:  major                                |  Resolution:
 Keywords:  good-first-bug has-test-info needs-  |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by jdeep):

 Replying to [comment:7 SirLouen]:
 > Replying to [comment:6 jdeep]:
 > > @SirLouen
 > >
 > > > Why in send_confirmation_on_profile_email the form post result is
 coming slashed?
 > >
 > > This happens because [https://github.com/WordPress/wordpress-
 develop/blob/trunk/src/wp-includes/load.php#L1284 ALL superglobals] are
 slashed whenever [https://github.com/WordPress/wordpress-
 develop/blob/trunk/src/wp-settings.php#L585 WordPress loads].
 > >
 > > Rather than rectifying this slash-ed email later on, we should
 refactor `add_magic_quotes` to maybe have some whitelist fields which does
 not need to be slashed. But this kind of refactor may break existing code
 if not thought of all the cases properly. It would also come with the
 overhead of maintaining this whitelist.
 > >
 > > But again this would be a much cleaner solution than un-slashing it
 later on.
 > >
 > > What are your thoughts on it?
 >
 > One of my questions for the first part is, why slahsing a whole array of
 fields with `add_magic_quotes` if we only need quotes for 1 field of such
 array?

 You are right. I delved into it a bit more and found that
 [https://github.com/WordPress/wordpress-
 develop/blob/946649af8db44b4c969c092d2f77643a1dc2ec4e/src/wp-
 includes/user.php#L2685 this line] is indeed buggy. Even assuming we
 hotfix it by un-slashing before before sending the mail, it will cause
 another unexpected behaviour where if the user's email has a character
 which causes a backslash to be added, then clicking the `Update Profile`
 button in `User > Profile` will trigger an email to be sent even if the
 email hasn't changed! This happens because of
 [https://github.com/WordPress/wordpress-
 develop/blob/946649af8db44b4c969c092d2f77643a1dc2ec4e/src/wp-
 includes/user.php#L2709 this line]:

 {{{#!php
 <?php
 if ( isset( $userdata['user_email'] ) && $user['user_email'] !==
 $userdata['user_email'] ) {
     $send_email_change_email = apply_filters( 'send_email_change_email',
 true, $user, $userdata );
 }
 }}}

 `$user['user_email']` has been slashed because of `$user =
 add_magic_quotes( $user )`. However, `$userdata['user_email']` is
 [https://github.com/WordPress/wordpress-
 develop/blob/946649af8db44b4c969c092d2f77643a1dc2ec4e/src/wp-
 admin/includes/user.php#L81 unslashed before passing] into
 `wp_update_user`.

 Therefore, if an email is `o'reilly at example.com` stored in the database,

 - `$user['user_email']` will be `o\'reilly at example.com`
 - `$userdata['user_email']` will be `o'reilly at example.com`

 thus triggering the email to be sent even though email ids are exactly
 same.

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