Weaver Xtreme Theme Support EUVD-2026-98295

Exploitation requires an authenticated WordPress account with at least low-level posting privileges (PR:L) to store the malicious payload, and it requires a victim - typically an administrator or another user - to subsequently load the page containing the injected script (UI:R). This limits the attack to multi-user installations where lower-trust accounts exist; single-admin sites that do not grant untrusted users posting access have little exposure. The specific vulnerable input field or feature is not detailed in the available description beyond the product's theme-support functionality, and no non-default configuration is identified as a prerequisite.

This is a stored cross-site scripting (CWE-79) flaw in the Weaver Xtreme Theme Support WordPress plugin (versions up to and including 7.0.1), reported by Patchstack with a CVSS 3.1 base score of 6.5 (Medium). The provided vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L indicates a network-reachable, low-complexity attack that requires authenticated low-privilege access (PR:L) and victim interaction (UI:R), with a scope change (S:C) reflecting that injected script executes in another security context such as an admin's browser session. No EPSS score, CISA KEV listing, or public proof-of-concept was supplied in the intelligence, so there is no signal of active or imminent widespread exploitation. The signals are internally consistent: a Medium-severity stored XSS gated behind authentication and user interaction is a genuine but not emergency-priority issue - it is not a high-CVSS-but-illusory risk, nor is it a mass-exploitation candidate absent KEV/EPSS data. Realistic risk is moderate and primarily matters for multi-user WordPress sites where lower-privileged accounts (e.g., contributors/authors) exist and can target administrators.

An attacker with a low-privileged authenticated WordPress account (e.g., contributor or author) submits input through a plugin field that is not properly sanitized, storing a malicious script. When an administrator or other user later views the affected page in the dashboard or front end, the script executes in their browser, potentially hijacking their session or performing actions on their behalf. No public proof-of-concept exploit was identified in the provided data.