YITH WooCommerce Product Add-Ons CVE-2026-42383

Exploitation requires (1) the YITH WooCommerce Product Add-Ons plugin installed and activated at version 4.29.0 or earlier on a WordPress/WooCommerce site, (2) network reachability to wp-admin or the plugin's AJAX/REST endpoints (AV:N), and (3) valid authenticated session as a high-privileged WordPress user - per CVSS PR:H, typically administrator or shop-manager capability with access to the plugin's management surface. No user interaction by another party is required (UI:N) and attack complexity is low (AC:L). The PR:H prerequisite is the dominant limiting factor: anonymous visitors, customers, and subscriber-level users cannot trigger the vulnerable code path, which substantially reduces the realistic attacker population to insiders or attackers who have already compromised a privileged WordPress account.

The CVSS 3.1 vector AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:L describes a network-reachable, low-complexity attack that requires high privileges, no user interaction, results in a scope change, and yields high confidentiality impact with low availability impact and no integrity impact. The high-privilege prerequisite (PR:H) materially constrains real-world risk: an attacker generally needs administrator-level or equivalent WordPress access, which already implies significant control of the site, so the practical uplift is mainly database read access (e.g., reading credentials, secrets, or data from other tenants/sites in shared environments where scope-change applies). No EPSS score, KEV listing, SSVC decision, or POC was provided in the input, and no public exploit was identified at time of analysis; this is not a confirmed mass-exploitation target. The contradiction worth flagging: PR:H usually does not produce a scope change, but Patchstack assessed S:C - this likely reflects WordPress multisite scenarios or cross-database access via WPDB, and defenders should verify this against the Patchstack advisory before sizing impact.

An attacker who has obtained high-privileged WordPress credentials (for example, via phishing of an administrator or shop manager, or via reuse of compromised credentials) logs into wp-admin and sends a crafted request to a vulnerable plugin endpoint, embedding boolean- or time-based SQL payloads in a parameter. Because the injection is blind, the attacker iteratively infers query results from response timing or content differences to exfiltrate sensitive database contents such as wp_users password hashes, secret_keys, or customer PII. No public POC was identified at time of analysis, so exploitation today would require custom payload development against the plugin's vulnerable parameter.