The Exploit
An unauthenticated attacker submits a malicious radio or checkboxgroup value through the WooCommerce Block Checkout Store API; when an administrator later views the order details page, the payload executes in their browser.
POST /wp-json/wc/store/v1/checkout HTTP/1.1
Host: vulnerable-shop.local
Content-Type: application/json
{
"billing_address": {
"first_name": "John"
},
"custom_fields": [
{
"key": "field_12345",
"type": "radio",
"value": "<select
}
]
}
The Store API accepts the payload without filtering. The order is created and stored in the database with the unescaped HTML intact. When an administrator opens the order details page in wp-admin, the prepare_single_field_data() method retrieves the field value, runs esc_html() on it (converting < to <), then immediately calls html_entity_decode() to convert it back. The decoded value is then passed to wp_kses() with the permissive get_allowed_html() allowlist, which explicitly permits <select> tags with onchange attributes. The JavaScript executes in the admin's session context.
What the Patch Did
Before
if($type === 'checkboxgroup' || $type === 'radio'){
$value = html_entity_decode($value);
}
After
// if($type === 'checkboxgroup' || $type === 'radio'){
// $value = html_entity_decode($value);
// }
The patch removes the html_entity_decode() call for radio and checkboxgroup field types. This prevents reversal of HTML entity encoding that had been applied by esc_html() earlier in the same method. By leaving the value in its escaped state (with entities like < and " intact), the subsequent wp_kses() call with the restricted allowlist cannot reconstruct dangerous HTML tags. The allowlist remains unchanged but is now safe because the input no longer contains decoded HTML that can bypass it. A secondary hardening change replaced all wp_kses() calls in output contexts with a stricter get_allowed_html_order_output() allowlist that does not permit event handler attributes on any tags.
Root Cause
CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site Scripting).
Attacker-controlled field values flow into the plugin via the WooCommerce Block Checkout Store API endpoints (unauthenticated). The prepare_single_field_data() method in class-thwcfd-block-order-data.php receives these values and applies esc_html() to escape them (line ~439). However, the code then explicitly calls html_entity_decode() for radio and checkboxgroup types (lines 440–442), converting HTML entities back to raw HTML characters. This decoded value is subsequently passed to wp_kses() for output on the order details admin page (lines 77, 114, 221). The get_allowed_html() allowlist permits <select> with onchange attributes, enabling the injected <select> payload to survive sanitization and execute in the admin's browser.
Why It Works
The load-bearing line in the vulnerable code is $value = html_entity_decode($value);. If removed, the payload would remain as entities (<select>) and wp_kses() would output it safely as literal text, not executable HTML. The preceding esc_html() call had already neutralized the threat, but the html_entity_decode() undid that neutralization in a single operation. The engineer's secondary change—replacing get_allowed_html() with get_allowed_html_order_output()—provides defence in depth: even if a future code path mistakenly decodes entities again, the tighter allowlist will reject event handler attributes. This two-layer fix (removing the decode, and restricting the allowlist) ensures that no single mistake reintroduces the vulnerability.
Hardening Checklist
-
Never call
html_entity_decode()on user input before output. If you must work with encoded entities, usehtmlspecialchars()oresc_html()as a final step immediately before output, and do not reverse it. -
Use context-specific
wp_kses()allowlists. Define a separate allowlist function for each output context (e.g.,get_allowed_html_order_output()vs.get_allowed_html_admin_form()) and explicitly exclude event handler attributes (onchange,onclick,onerror, etc.) from all order/user-facing contexts. -
Apply
sanitize_text_field()to all custom field values from external API endpoints before storing in the database, even if they will be escaped at output time. This prevents stored XSS and protects against other output paths that may not apply escaping. -
Audit all
wp_kses()calls with regex. Search your codebase forwp_kses\(and verify that every call is paired with a context-appropriate, human-reviewed allowlist function, not an inline array. -
Test XSS payloads with HTML entities pre-escaped. When writing security tests, verify that payloads like
<select> and<img src=x> remain inert after passing through your sanitization pipeline.
References
- https://nvd.nist.gov/vuln/detail/CVE-2026-3231