CVE-2026-81428 in WC Vendors Plugin
Summary
by MITRE • 09/02/2026
The WC Vendors WordPress plugin before 2.7.2.1 does not verify ownership or the object type of user-supplied IDs when saving product variations, allowing authenticated users with the vendor role to modify product variations belonging to other vendors, and to change the status and title of arbitrary posts, via IDOR.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in WC Vendors versions prior to 2.7.2.1 represents a critical failure in server-side access control mechanisms within a widely used WordPress e-commerce ecosystem. This flaw is classified as an Insecure Direct Object Reference (IDOR), which corresponds to CWE-639, and allows for unauthorized modification of resources by exploiting the lack of proper authorization checks on user-supplied identifiers. The core technical issue lies in how the plugin handles requests related to product variations during the save operation. When a vendor attempts to update or create a variation, the application accepts an identifier from the client-side request without verifying whether that specific resource belongs to the authenticated user making the request. This absence of ownership verification means that if an attacker can guess or enumerate valid object IDs for products hosted by other vendors on the same WordPress installation, they can successfully submit requests targeting those external resources.
The operational impact of this vulnerability is significant due to the potential for data integrity compromise and business disruption within multi-vendor marketplaces built on WordPress. An authenticated user with the vendor role, which typically has limited privileges compared to administrators but still possesses substantial capabilities regarding their own listings, can escalate these actions beyond their intended scope. By manipulating the object ID in the HTTP request payload, an attacker can modify product variations belonging to competitors or other vendors. This includes altering critical attributes such as pricing, stock levels, and descriptions, which directly impacts sales performance and customer trust for the affected parties. Furthermore, the vulnerability extends beyond simple e-commerce data manipulation; it allows the modification of arbitrary posts within the WordPress database. Since WooCommerce products are stored as custom post types in WordPress, this IDOR flaw effectively grants attackers the ability to change the status (e.g., from published to draft) and titles of these posts, potentially taking listings offline or defacing them without authorization.
From a threat modeling perspective, this vulnerability aligns with MITRE ATT&CK technique T1078, specifically Valid Accounts, as it requires initial authentication but exploits weak access control logic rather than credential theft. The attack vector is straightforward and does not require complex exploitation techniques; an attacker simply needs to intercept the network traffic during a legitimate product variation save operation using tools like Burp Suite or OWASP ZAP, modify the object ID parameter to target another vendor's resource, and resend the request. Because WordPress plugins often rely on client-side logic for initial validation before sending data to the server, this type of vulnerability is prevalent in applications that fail to implement robust server-side authorization checks. The lack of verification allows malicious actors to bypass intended business logic constraints, leading to unauthorized state changes across multiple user accounts within a shared hosting environment.
Mitigation strategies must focus on implementing strict object-level access controls at the application layer. Developers should ensure that every request involving resource modification includes a validation step where the server verifies that the authenticated user has explicit ownership or administrative rights over the specific product variation being modified. This can be achieved by querying the database to confirm that the vendor ID associated with the product matches the ID of the currently logged-in user before processing any updates. Additionally, implementing rate limiting and logging mechanisms for modification requests can help detect anomalous behavior indicative of enumeration attacks. For users running affected versions, immediate upgrading to version 2.7.2.1 or later is essential as this release addresses the authorization checks. Until an update is applied, administrators should consider restricting vendor capabilities where possible and monitoring server logs for unusual patterns in product modification requests from specific IP addresses or user accounts.