WP Customer Area EUVD-2026-119093

Exploitation requires an authenticated account on the target WordPress site (CVSS PR:L) - the attacker must be able to submit content that WP Customer Area stores, consistent with the plugin's client/customer-area functionality. Because the payload is stored, a second user with higher privileges (e.g., an administrator) must subsequently view the affected content for the script to execute (CVSS UI:R), and execution in that user's context is what produces the scope change (S:C). Limiting factors: no unauthenticated path (a foothold account is needed), reliance on victim interaction, and applicability only to sites running WP Customer Area version 8.4.3 or earlier. The exact field, page, or configuration that stores the unsanitized input is not described in the available sources.

This is a moderate-severity, authenticated Stored XSS (CWE-79) in the WP Customer Area WordPress plugin, rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L). The CVSS signals point to a network-reachable but privilege- and interaction-gated issue: PR:L means an attacker needs an existing authenticated account, UI:R means a victim must view the injected content, while S:C (scope change) reflects stored script executing in another security context such as an administrator's session. Non-CVSS signals are mixed and mostly absent: there is no CISA KEV listing (not confirmed actively exploited), no EPSS probability was supplied, and no SSVC exploitation/automatable/technical-impact fields were provided. The vuln.today decision label is 'this_month', indicating a routine-but-non-urgent patching priority rather than an emergency. The only reference is the Patchstack advisory that reported it - an advisory record, not verified exploit code. Net assessment: a genuine but second-tier priority. It is a stored XSS requiring a foothold account plus victim interaction, which caps real-world risk below unauthenticated RCE-class issues; with no KEV, no EPSS, and no public exploit, it should be scheduled in routine patch cycles rather than treated as an incident. Missing EPSS and absent fixed-version data are the main gaps limiting a fuller risk picture.

An attacker holding a low-privileged account (e.g., a customer/subscriber on a site using WP Customer Area) submits content containing a malicious script payload into a field that the plugin stores and later renders without proper neutralization. When a higher-privileged user such as an administrator views that stored content in wp-admin, the script executes in their browser session (scope change), enabling session/cookie theft or actions on their behalf. No public, verified exploit code was identified; the only source is the Patchstack advisory, and the exact vulnerable field/trigger is not described in the available sources.