The Exploit
The attacker needs no authentication; an unauthenticated visitor can weaponize the search_key query parameter.
GET /?search_key=%22%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E HTTP/1.1
Host: target.example
User-Agent: Mozilla/5.0
Accept: text/html
The response contains the injected script tag inside the rendered HTML, because the search_key value is echoed directly into the value attribute of an input field. A victim loading the page will execute the injected JavaScript immediately when the browser parses the malformed input element.
What the Patch Did
Before:
$html_inputBox .= '<input data-key="s" value="' . $search_keyword . '" class="query-keyword-input-box query_box_direct_value" id="single_keyword_' . $shortcode->table_id . '" value="" placeholder="' . $search_order_placeholder . '"/>';
After:
$html_inputBox .= '<input data-key="s" value="' . esc_attr( $search_keyword ) . '" class="query-keyword-input-box query_box_direct_value" id="single_keyword_' . $shortcode->table_id . '" value="" placeholder="' . $search_order_placeholder . '"/>';
The patch adds the WordPress esc_attr() output escaping function, ensuring the attacker-controlled $search_keyword is safely encoded before insertion into an HTML attribute value.
Root Cause
This is a CWE-79 reflected cross-site scripting bug. The search_key query parameter is accepted from the request, assigned to $search_keyword, and concatenated directly into an HTML input value attribute in inc/handle/search-box.php. That crosses the trust boundary from untrusted GET parameters into rendered page markup without escaping, allowing attribute injection and script execution.
Why It Works
The only load-bearing change is esc_attr( $search_keyword ). If that call were removed, the payload still closes the value attribute and injects attacker-controlled markup. The original string concatenation was already building valid HTML; the bug existed because the output was not encoded for the attribute context. The rest of the line is just the normal input element template, so the fix is specifically the attribute-level escaping. No additional access control was required for this reflected XSS, and the developer didn’t need to alter the page logic beyond sanitizing the value at output.
Hardening Checklist
- Use
esc_attr()for any value placed inside an HTML attribute in WordPress templates. - Use
sanitize_text_field( $_GET['search_key'] ?? '' )or equivalent when reading plain-text query parameters to normalize untrusted input early. - Prefer
esc_html()for text rendered between tags andesc_url()for URLs; choose the WordPress escaping function that matches the output context. - Avoid concatenating raw request data into HTML; build markup with safe string functions and explicit escaping.
- Audit shortcode and search-handling code for any place where
$_GET,$_POST, or shortcode attributes are printed without an escaping wrapper.
References
- https://nvd.nist.gov/vuln/detail/CVE-2025-12398