[wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used unsanitized in user search query

[WordPress Trac]

#65051: $_REQUEST['term'] used unsanitized in user search query
--------------------------------+------------------------------------------
 Reporter:  rajeshcp            |       Owner:  rajeshcp
     Type:  defect (bug)        |      Status:  assigned
 Priority:  normal              |   Milestone:  7.1
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch needs-    |     Focuses:  multisite, coding-standards
  testing                       |
--------------------------------+------------------------------------------

Comment (by liaison):

 Title: Security Analysis & Vulnerability Impact

 I would like to clarify the current impact of this vulnerability. While
 the fix is essential for "Defense in Depth," a successful XSS attack is
 currently unlikely to trigger in the default WordPress UI for the
 following reasons:

 Empty Response on Malicious Payload: When a payload like
 <script>alert('XSS')</script> is injected into the term parameter, the
 backend executes a get_users query. Since no user account exists with such
 a string as a username, the database returns an empty set. The resulting
 Ajax response is an empty array [].

 Safe Client-Side Handling: The current WordPress core JavaScript that
 handles the autocomplete-user action expects a JSON array of user objects.
 When it receives [], it simply does not render any dropdown items. There
 is no "Reflected XSS" point where the raw term is echoed back into the DOM
 during a "No results found" state.

 Why the fix is still critical:

 Even though a direct "Pop-up alert" PoC is difficult to achieve in the
 current UI, this remains a valid security issue:

 Log Poisoning / Second-Order XSS: If the search term is recorded in
 server-side audit logs or slow-query logs that are later viewed in a less-
 secure admin interface, the script could execute then.

 Future-Proofing: Any future changes to the UI that might display "No
 results found for: [term]" would immediately turn this into a high-risk
 Reflected XSS.

 Data Integrity: WordPress coding standards dictate that all user input
 must be sanitized before being used in logic, especially when it reaches
 the query level.

 [Next comment]My standalone tests confirm that the patch correctly closes
 this door by stripping HTML tags at the entry point, ensuring the term is
 clean regardless of how the output is handled.

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