CVE-2026-12144 in Wholesale for WooCommerce Plugin
Summary
by MITRE • 07/29/2026
The Wholesale for WooCommerce plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.0.5. This is due to the `save_requests_meta()` function applying only `sanitize_text_field()` to the `user_role_set` POST parameter before passing it directly to `WP_User::add_role()`, with no allowlist validation against permitted wholesale roles and no capability check such as `current_user_can('promote_users')` or `current_user_can('manage_options')`. This makes it possible for authenticated attackers with author-level access and above to escalate their privileges to administrator by supplying `administrator` as the `user_role_set` value in a crafted request. The function is gated only by a nonce (`request_user_role_nonce`) that is rendered in the meta box on the `wwp_requests` post edit screen; because the post type is registered with `capability_type => 'post'`, any author-level user who has authored a `wwp_requests` post — such as one created via the wholesale registration form — can access this nonce and submit the role-assignment request.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/29/2026
The Wholesale for WooCommerce plugin presents a critical privilege escalation vulnerability affecting all versions through 2.0.5, exploiting a fundamental flaw in user role management within WordPress. This vulnerability resides in the save_requests_meta() function which processes user role assignments without proper validation mechanisms, creating an exploitable pathway for authenticated attackers to elevate their privileges from author level to administrator status.
The technical implementation of this vulnerability stems from inadequate input sanitization and validation practices within the plugin's codebase. The save_requests_meta() function applies only sanitize_text_field() to the user_role_set POST parameter before directly passing it to WP_User::add_role(), completely bypassing any form of allowlist validation against permitted wholesale roles. This primitive sanitization approach fails to address the core security requirement of validating that submitted role values correspond to legitimate administrative roles within the system's context.
The vulnerability operates through a specific attack vector involving a nonce-based mechanism that appears secure on surface level but contains critical design flaws. The function is protected by request_user_role_nonce which is rendered in the meta box on wwp_requests post edit screens, yet this protection proves insufficient due to the plugin's registration configuration where capability_type => 'post' allows any author-level user who has authored a wwp_requests post to access and utilize this nonce. This design flaw essentially removes the intended access controls that should restrict role assignment operations to users with appropriate administrative privileges.
The operational impact of this privilege escalation vulnerability extends beyond simple access control bypass, as it fundamentally undermines the security model of WordPress installations using this plugin. An attacker with author-level permissions can exploit this vulnerability to gain full administrator access by simply submitting a crafted request containing 'administrator' as the user_role_set value, effectively compromising the entire WordPress installation and potentially leading to data breaches, malware deployment, or complete system takeover.
The vulnerability aligns with CWE-264, which addresses permissions, privileges, and access control issues in software systems, specifically targeting improper privilege management. From an ATT&CK perspective, this represents a privilege escalation technique under T1068, where an attacker leverages existing access to elevate their privileges within the system. The attack requires minimal technical expertise beyond understanding basic WordPress user roles and nonce mechanisms, making it particularly dangerous as it can be exploited by attackers with relatively low initial access levels.
Mitigation strategies must address both immediate remediation and long-term architectural improvements to prevent similar vulnerabilities from occurring in the future. Organizations should immediately update to versions containing patches that implement proper allowlist validation for user roles and require explicit capability checks before allowing role modifications. The fix should enforce current_user_can('promote_users') or current_user_can('manage_options') checks, ensuring that only users with appropriate administrative privileges can modify user roles through the plugin interface.
Additional security measures should include implementing comprehensive input validation that restricts role assignments to predefined whitelist values, removing the reliance on simple sanitization functions for critical operations, and strengthening nonce-based access controls to prevent unauthorized use of administrative functions. Regular security audits should also be conducted to identify similar privilege escalation patterns in other plugin components, ensuring that all user role modification operations follow secure coding practices that align with WordPress security standards and best practices for privilege management within content management systems.