MultiVendorX EUVD-2026-53106

Exploitation requires an active, authenticated vendor-level account (Store Owner role or equivalent) on the targeted WordPress marketplace - unauthenticated exploitation is not possible given the PR:H CVSS vector. The vulnerability is exposed via the MultiVendorX REST API, so the API must be reachable (standard for any publicly accessible WordPress site). The marketplace must have multiple vendor stores enrolled; a single-vendor deployment has no other stores to target and presents negligible risk from this specific flaw. No special server configuration or non-default settings are required beyond the plugin being installed and active. The primary limiting factor is possession of a valid vendor credential - on open-registration marketplaces this is a weak barrier, while on invitation-only or KYC-verified platforms it represents meaningful friction.

The official CVSS 3.1 score of 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) reflects high-privilege authentication as the primary gatekeeping control. In a typical marketplace deployment, vendor accounts require approval and are not freely self-registered, which genuinely constrains exploitation. However, in open or low-scrutiny marketplaces, vendor registration may be trivial, effectively reducing the practical barrier. The EPSS score of 0.14% (4th percentile) indicates very low observed exploitation probability relative to other CVEs, potentially because vendor credential acquisition is the bottleneck. A publicly available exploit (per WPScan reference) does exist, which is a meaningful escalation signal even with low EPSS - it lowers attacker effort once credentials are obtained. The combination of high CIA impact, a working public exploit, and a multi-tenant trust boundary violation makes this a meaningful priority for any organization running a live marketplace with multiple vendors, despite the high-privilege requirement dampening mass exploitation likelihood.

An attacker who has registered or compromised a vendor account on a WordPress multivendor marketplace authenticates to the platform and enumerates other store IDs - likely trivial since store IDs in WooCommerce-based marketplaces are often sequential integers or public slugs. Using the publicly available exploit, the attacker crafts REST API requests substituting a victim store's identifier, allowing them to exfiltrate order data and customer PII, alter product listings and pricing, or permanently delete a competitor's store - all without any interaction from the target vendor.