CVE-2026-3231 affects Checkout Field Editor Checkout Manager for WooCommerce and it is an unauthenticated stored cross site scripting vulnerability that can fire in high value contexts such as the WooCommerce admin order screen and customer order details. The reason this matters is that checkout fields sit directly on the boundary between untrusted shopper input and trusted back office workflows. If an attacker can store HTML that later executes in an administrator’s browser, the impact quickly escalates from a cosmetic script popup into session theft and administrative actions performed in the background. With an install base around 500k plus, the vulnerable pattern is relevant for many production stores, especially those that use custom checkout fields to collect contact data, delivery preferences, or consent options.
| CVE | CVE-2026-3231 |
| Plugin Version | Checkout Field Editor (Checkout Manager) for WooCommerce <= 2.1.7 |
| All Time | 10 232 124 |
| Active installations | 500 000+ |
| Publicly Published | March 10, 2026 |
| Last Updated | March 10, 2026 |
| Researcher | Dmitrii Ignatyev |
| PoC | Yes |
| Exploit | No |
| Reference | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-3231 https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/woo-checkout-field-editor-pro/checkout-field-editor-checkout-manager-for-woocommerce-217-unauthenticated-stored-cross-site-scripting-via-block-checkout-custom-radio-field https://t.me/cleantalk_researches/383 |
| Plugin Security Certification by CleanTalk |  |
| Logo of the plugin |  |
PSC by CleantalkJoin the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.
Timeline
| February 5, 2026 | Plugin testing and vulnerability detection in the The Event Calendar have been completed |
| February 5, 2026 | I contacted the author of the plugin and provided a vulnerability PoC with a description and recommendations for fixing |
| March 10, 2026 | Registered CVE-2026-3231 |
Discovery of the Vulnerability
The bug is rooted in a broken escaping pipeline for Block Checkout custom fields of type Radio and related group types. The renderer initially escapes the stored value using esc_html, which should neutralize HTML, but then the code re decodes the value back into raw HTML using html_entity_decode for radio and checkboxgroup handling, effectively undoing the escape. After that, the output is passed through wp_kses with an allow list that is overly permissive and includes a select element with an allowed onchange attribute. That combination creates an obvious stored XSS sink because an attacker controlled payload can survive storage and be rendered as active HTML with a JavaScript event handler. The vulnerable flow occurs in the block order data preparation logic in block/class-thwcfd-block-order-data.php around prepare_single_field_data, and the allow list comes from THWCFD_Utils::get_allowed_html in includes/utils/class-thwcfd-utils.php, which is where the unsafe allowance of event attributes makes exploitation possible.
Understanding of Stored XSS attack’s
Stored XSS in WooCommerce is particularly dangerous because order views are a privileged workflow surface. Administrators open orders constantly, customer service staff view order details, and order emails can be processed by systems that render HTML. A vulnerability that originates from a checkout field is also attractive to attackers because it can be triggered by a normal purchase flow, sometimes without needing an account at all. Real world outcomes of stored XSS in an order context include stealing admin cookies, forcing background actions using the victim’s session, creating new administrator users, changing payment settings, or installing plugins, depending on what defensive controls are present. The critical lesson here is that safe output encoding must be consistent and one directional. Once you escape, you never decode back into HTML. The moment you do, you have effectively re enabled the attacker’s markup. Allowing event handler attributes like onchange inside wp_kses rules is a strong signal that the allow list is being used incorrectly, because event handlers are code execution primitives in the browser.
Exploiting the Stored XSS Vulnerability
To exploit CVE-2026-3231, an attacker without any cookies:
POC:
Send following payload in a field "Radio" type: "thwcfe-additional-fields":{"contact":{"test":"<select onchange=alert(document.domain)><option>CLICK ME</option><option>WTF</option></select>"}}},____
The most serious scenario is administrator compromise. If an unauthenticated attacker can inject a payload during checkout, they can effectively plant a trap that will execute when staff processes orders. Even if the payload requires interaction like changing a selection, order processing often involves clicking through and interacting with controls, so the trigger is realistic. From there the attacker can perform actions that look like the administrator did them, which can include changing store settings, altering payout destinations, creating new accounts, or installing backdoors, depending on the environment. A second scenario is customer targeting. If the malicious HTML is also shown in customer order pages or emails, the attacker can weaponize it for phishing or browser exploitation against shoppers. The business impact can be immediate because WooCommerce stores are revenue generating systems, so any admin takeover or payment redirection event can cause direct financial loss. The stealth property is also important because stored XSS can remain dormant until an order is opened, which can delay detection and make incident response harder.
Recommendations for Improved Security
The fix must focus on restoring a correct output encoding strategy. The plugin should remove html_entity_decode from the rendering path for any untrusted stored values, because decoding after escaping recreates active HTML. If the goal is to show a human readable label for radio options, it should be rendered as plain text using a single safe encoding function and never treated as markup. The wp_kses allow list should be hardened, and event handler attributes such as onchange should never be permitted on any element that can contain attacker controlled content. In addition, input validation should be applied at the time of storage, ensuring that checkout field values for radio options are stored as scalar safe strings without markup, and that Store API payloads are validated server side to prevent tampering. Store owners should patch as soon as a fixed version is available, and they should consider temporarily disabling Block Checkout custom radio field rendering in order views if that is feasible, because the highest risk comes from the privileged admin order context. Finally, add monitoring for suspicious markup in order meta and review recent orders for unexpected tags like select, script, svg, or event attributes, because early detection can prevent an eventual admin session compromise.
By taking proactive measures to address Stored XSS like CVE-2026-3231 WordPress website owners can enhance their security posture and safeguard against potential exploitation. Stay vigilant, stay secure.
#WordPressSecurity #StoredXSS #WebsiteSafety #StayProtected #HighVulnerability
Use CleanTalk solutions to improve the security of your website
Dmitrii I.