WP Customer Area EUVD-2026-118192

Exploitation requires an authenticated account with subscriber-level privileges or above (PR:L) on a site running WP Customer Area version 8.4.0 or earlier, with the customer account edit / profile feature available so the attacker can set the 'display_name' value that is stored unsanitized and later rendered (e.g., in post-owner links and the log table). The payload only fires when another user accesses the injected page, so impact depends on a higher-privileged user viewing attacker-controlled display-name output. Limiting factors: attacker must be able to register or already hold a subscriber+ account (open registration broadens this), and the fix in version 8.4.1 fully remediates the issue per the vendor changeset.

This is a moderate-severity stored XSS (CVSS 6.4) in the WP Customer Area WordPress plugin. Decision signals converge on a non-emergency, scheduled-remediation posture: the vuln.today Decision label is 'this_month', no CISA KEV entry is present (not actively exploited per available data), no EPSS score was supplied, and no public exploit or PoC reference is included - only the Wordfence advisory and WordPress trac source/changeset links. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) indicates network-reachable, low-complexity injection requiring low privileges (PR:L = authenticated subscriber-level), with a scope change (S:C) reflecting that the injected script executes in the context of other users who view the affected page. This is a genuine but bounded risk: the subscriber+ authentication requirement and the low confidentiality/integrity impact (C:L/I:L, A:N) keep it well below critical. The scope change is the main aggravating factor, since a low-privileged attacker can affect higher-privileged users. No key signals conflict; the primary gap is the absence of EPSS data to gauge exploitation likelihood quantitatively.

An attacker registers or uses an existing subscriber-level account on a site running WP Customer Area (≤8.4.0) and sets their 'display_name' to a value containing a malicious script payload. The unsanitized value is stored and later rendered without proper output escaping on pages such as owner links or log tables, so the script executes in the browser of any user - potentially an administrator - who views the injected page. No public exploit code is identified at time of analysis; the trigger path is corroborated by the vendor-referenced plugin source lines.