[wp-trac] [WordPress Trac] #32703: XMLRPC: wp_editPage doesn't work if username or password contains special characters

[WordPress Trac]

#32703: XMLRPC: wp_editPage doesn't work if username or password contains special
characters
--------------------------+-----------------------------
 Reporter:  redsweater    |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  XML-RPC       |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 If a user's password contains a special character that would be escaped by
 the XMLRPC class's escape() method, then it ends up being doubly-escaped
 and thus prevents authentication from succeeding when calling through to
 mw_editPost().

 Although far less likely, a similar problem will cause an escaped
 character in either the page ID parameter or the username parameter to
 also end up being doubly-escaped, causing either authentication error or a
 page lookup failure.

 A canonical example of this bug would be to create a user 'admin' with
 password 'abc"123'. Efforts to edit a page via wp_editPage will result in
 the password being first escaped in wp_editPage to 'abc\"123' and then
 escaped a second time in mw_editPost to 'abc\\\"123', at which time it
 will fail to authenticate the user.

 wp_editPage is the only method among the WP page methods that calls
 through to an underlying method in a problematic way. Other methods either
 pass through the $args directly to an underlying method, or else handle
 the database lookup independently of other methods that would escape the
 parameters on their own.

 The attached patch addresses the problem by escaping parameters for the
 purposes of wp_editPage's own authentication/validation, but passing
 through the original parameters unescaped so that they may be escaped in
 mw_editPost to obtain the expected value.

 I realize it is preferable to switch clients to the post-based wp API
 methods, but since this fix is limited in scope to the wp_editPage method,
 and is a clear improvement, I hope you will accept it as a fix for clients
 who have not yet updated or may never update to the newer API methods.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32703>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform