Flexible Refund Plugin EUVD-2026-43474

Exploitation requires the attacker to possess a valid WooCommerce customer account with sufficient privilege to submit a refund or return request (PR:L), which on most public WooCommerce stores is available to any user who can register or complete a purchase. The Flexible Refund and Return Order for WooCommerce plugin must be installed and active. A shop administrator or similarly privileged WordPress user must subsequently view the stored malicious submission - this occurs naturally during routine refund review workflow (UI:R) and does not require additional social engineering. No non-default configuration or special server-side conditions are described as prerequisites beyond plugin activation. Exploitation is limited by the requirement for at least low-privilege authentication (unauthenticated visitors cannot submit refund requests) and the need for admin interaction with the stored content; automated mass exploitation without UI:R fulfillment is not possible.

The CVSS 6.5 score (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L) places this in the medium range by score, but real-world risk on public WooCommerce storefronts is meaningfully higher than that score suggests. PR:L confirms exploitation requires only a WooCommerce customer account - a trivially low barrier on stores with open registration. UI:R requires an administrator to view the malicious submission, which is a routine operational action rather than a social-engineering hurdle. The scope change (S:C) elevates the realistic impact: successful exploitation can compromise administrator sessions, not just the attacker's data. No EPSS data was provided, so exploitation probability cannot be quantified; active exploitation has not been confirmed by CISA KEV. The A:L (availability impact low) in the provided CVSS vector is atypical for a stored XSS and may reflect plugin-specific behavior such as form disruption - this metric warrants vendor clarification. Overall, while the CVSS score appears moderate, the attack path (open registration → refund submission → admin review) is a natural workflow, making exploitation realistic against unpatched stores.

An attacker registers as a WooCommerce customer on the target store and submits a refund request, injecting a JavaScript payload into a text field that lacks proper output encoding before database storage. When a shop administrator opens the WooCommerce admin dashboard to review pending refund requests, the stored script silently executes in their browser, exfiltrating the admin session cookie or WordPress nonce tokens to an attacker-controlled endpoint. No public exploit code has been identified at time of analysis, but the technique requires only basic HTML injection knowledge and no specialized tooling.