WPC Estimated Delivery EUVD-2026-91962

Exploitation requires the attacker to supply a crafted value in the 'rule_data' parameter (handled by the plugin's rule/backend template code per the referenced rule.php and class-backend.php) and to successfully trick a user into clicking the malicious link or performing an action - this UI:R requirement is the primary limiting factor. No authentication is needed to craft the request (PR:N), and default configurations of the WPC Estimated Delivery Date for WooCommerce plugin up to and including version 4.0.1 are affected, but the payload only executes within the tricked victim's browser session, so impact is bounded to that user's privileges on the WordPress site.

This is a reflected Cross-Site Scripting (CWE-79) flaw with a CVSS 3.1 base score of 6.1 (Medium) via the vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. The network vector, low complexity and lack of required privileges (PR:N) mean an unauthenticated attacker can craft the payload, but exploitation is gated by UI:R - the victim must click a malicious link or perform an action, which materially lowers real-world risk compared to a self-propagating or unauthenticated-no-interaction bug. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The vulnerability is NOT listed in CISA KEV and no public proof-of-concept was supplied, so this is 'no public exploit identified at time of analysis' rather than active exploitation. The scope change (S:C) reflects that injected script executes in the victim's browser session against the WordPress site context. On balance this is a legitimate but moderate-priority issue: the CVSS signals are internally consistent (reflected XSS requiring user interaction), there is no evidence of widespread or targeted exploitation, and impact is limited (C:L/I:L/A:N). Patch version is not confirmed from the available input data.

An attacker crafts a URL for a vulnerable WPC Estimated Delivery Date for WooCommerce site embedding a malicious script in the 'rule_data' parameter, then lures a logged-in administrator or user into clicking it (e.g., via phishing email). When the page renders the unsanitized parameter, the script executes in the victim's browser session, potentially enabling session/cookie theft or admin actions. No public proof-of-concept was supplied in the input data.