Executive Summary
CVE-2026-15369 affects Custom User Registration Fields for WooCommerce, a plugin by Addify for WordPress/WooCommerce stores, in versions 2.2.3 and earlier. The flaw is an Improper Privilege Management bug (CWE-269) that lets a completely unauthenticated attacker grant themselves the Administrator role simply by placing an order through checkout.
CVSS Score: 9.8 (Critical)
The plugin's af_reg_checkout_data_to_order_meta_data_block() function reads an attacker-controlled afreg_select_user_role value from the unauthenticated WooCommerce Store API endpoint /wc/store/v1/checkout and stores it in order meta. That value is later passed directly to WP_User::add_role() inside af_reg_custom_order_processing_function(), hooked to woocommerce_thankyou, with no validation against the plugin's admin-configured list of allowed roles. An attacker can submit a normal checkout request with the role field set to administrator and receive full site administrator access the moment the order completes.
Vulnerability Overview
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-15369 |
| CVSS Score | 9.8 (Critical) |
| Type | Improper Privilege Management (CWE-269) |
| Attack Vector | Network |
| Privileges Required | None |
| User Interaction | None |
| Vulnerable Functions | af_reg_checkout_data_to_order_meta_data_block(), af_reg_custom_order_processing_function() |
Affected Versions
| Product | Affected Versions | Fixed Version |
|---|---|---|
| Custom User Registration Fields for WooCommerce (Addify) | 2.2.3 and earlier | Not yet published at time of writing |
Exploitation requires the plugin's "User Role Selection" checkout option to be enabled — a setting store owners commonly turn on to let customers register as wholesalers, vendors, or other custom roles during checkout.
Technical Details
WooCommerce's headless Store API (/wc/store/v1/checkout) is designed to be reachable without authentication, since it powers guest checkout and account creation at the point of purchase. Custom User Registration Fields for WooCommerce hooks into that flow to let new customers pick a role from an admin-defined list at checkout time.
The plugin never re-validates the submitted role against that allow-list on the server side. It trusts the afreg_select_user_role field from the raw checkout JSON body, persists it as order meta, and — once the order reaches the woocommerce_thankyou step — calls WordPress's own WP_User::add_role() with that value.
Attack Vector
1. Attacker identifies a WooCommerce store running the vulnerable plugin
with "User Role Selection" enabled at checkout
2. Attacker submits a POST request to /wc/store/v1/checkout, creating
a new account and setting afreg_select_user_role: "administrator"
3. The order is processed and reaches the woocommerce_thankyou hook
4. af_reg_custom_order_processing_function() passes the attacker's
role value straight into WP_User::add_role() with no allow-list check
5. The newly created account is granted the Administrator role
6. Attacker logs in with full administrative control of the WordPress siteImpact of Successful Exploitation
| Impact | Description |
|---|---|
| Full Site Takeover | Administrator access allows plugin/theme installation, arbitrary PHP execution via the plugin editor, and complete control of the WordPress install |
| No Authentication Barrier | The entire chain runs through WooCommerce's public, unauthenticated Store API |
| Low Complexity | A single crafted checkout request is sufficient — no social engineering or prior access required |
| Silent Onboarding | The malicious account is created as part of a normal-looking order, blending into legitimate checkout traffic |
Immediate Remediation
Step 1: Disable the Vulnerable Setting
Until a patched release ships, disable "User Role Selection" in the plugin's checkout settings. This removes the code path that trusts the attacker-controlled role field.
Step 2: Watch for a Vendor Patch
Check the plugin changelog and WordPress.org plugin page regularly for a fixed version beyond 2.2.3, and update immediately once available.
Step 3: Audit Existing Accounts
# Review WordPress users for unexpected Administrator accounts,
# especially those created via recent WooCommerce orders
wp user list --role=administrator --fields=ID,user_login,user_registeredStep 4: Restrict the Store API as a Stopgap
Sites that cannot disable role selection can add a web application firewall rule blocking afreg_select_user_role values other than the store's intended default (e.g., customer) on requests to /wc/store/v1/checkout.
Detection Indicators
| Indicator | Description |
|---|---|
| New Administrator accounts tied to a WooCommerce order | Strong sign of exploitation via this checkout flow |
Checkout requests containing afreg_select_user_role=administrator | Direct evidence of an exploitation attempt in access/WAF logs |
| Unexpected plugin, theme, or file changes shortly after a new account registration | Sign of post-exploitation activity following a successful takeover |
Post-Remediation Steps
- Disable "User Role Selection" immediately if the store does not strictly require it.
- Audit all Administrator-role accounts for ones tied to recent orders rather than known staff.
- Rotate credentials and API keys if an unauthorized Administrator account is found.
- Apply the vendor patch as soon as it is released and re-enable role selection only after confirming the fix validates roles server-side.
- Review other checkout-triggered plugins for the same pattern of trusting client-supplied role or capability values.
References
- Wordfence — Custom User Registration Fields for WooCommerce ≤ 2.2.3 Vulnerability Intelligence
- OffSeq Threat Radar — CVE-2026-15369
- THREATINT — CVE-2026-15369
- NVD — CVE-2026-15369