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

WordPress Trac noreply at wordpress.org
Thu May 14 16:09:08 UTC 2026


#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-testing  |     Focuses:  multisite, coding-
  has-test-info has-unit-tests has-  |  standards
  screenshots                        |
-------------------------------------+-------------------------------------
Changes (by vgnavada):

 * keywords:  has-patch needs-testing has-test-info has-unit-tests => has-
     patch needs-testing has-test-info has-unit-tests has-screenshots


Comment:

 == Test Report
 === Description
 This report validates whether the indicated patch works as expected.

 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11530

 === Environment
 - WordPress: 7.1-alpha-20260409.114541
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 148.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1
 - Testing setup: WordPress Playground with Multisite enabled

 === Actual Results
 1. ✅ Patch works as expected based on functional Playground testing.

 **Test 1: Malicious payload through browser console**

 Tested the `autocomplete-user` AJAX action using the following payload:

 `<script>alert('XSS')</script>Admin`

 The request completed successfully and returned an empty array:

 `[] success`

 No alert was triggered, no malicious autocomplete suggestion was rendered,
 and no visible console error was observed.

 [[Image(https://i.ibb.co/679vhfqr/image.png)]]

 **Test 2: Normal term through the browser console**

 Tested the same `autocomplete-user` AJAX action using a normal term:

 `admin`

 with `autocomplete_type` set to `add`.

 The request completed successfully and returned an empty array:

 `[] success`

 This is not treated as a failure because, in the Playground setup, the
 `admin` user is already part of `site_id: 1`, so the add-user autocomplete
 flow may exclude that user from the result.

 [[Image(https://i.ibb.co/CsV780c2/image.png)]]

 **Test 3: Manual UI input test**
 Tested the payload directly in the Network Admin user autocomplete input
 field:

 `<script>alert('XSS')</script>Admin`

 The field accepted the typed value, which is expected for a text input. No
 alert was triggered, no script was executed, no malicious autocomplete
 suggestion was rendered, and the page did not break.

 [[Image(https://i.ibb.co/GQKvvYHN/image.png)]]

 === Additional Notes
 - Tested using WordPress Playground with [https://github.com/WordPress
 /wordpress-develop/pull/11530 PR: 11530] and Multisite enabled.
 - The first console screenshot shows the malicious payload test returning
 `[] success`.
 - The second console screenshot shows the normal `admin` term test
 returning `[] success`.
 - This Playground test confirms the visible browser and AJAX behavior.
 - Based on the Playground test, the patch does not visibly break the
 autocomplete-user AJAX action, and the malicious payload does not execute
 or render in the browser.

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


More information about the wp-trac mailing list