CP Media Player EUVD-2026-66940

Exploitation requires that the target WordPress site has CP Media Player version 1.3.0 or earlier installed and active. The CVSS vector PR:N confirms no authentication is required on the attacker's side to craft and deliver the payload. However, UI:R confirms that a victim user must take an action - specifically, clicking or visiting a crafted URL - for the payload to execute. Exploitation is not passive; the attacker cannot trigger the XSS without victim interaction. The scope change (S:C) applies to the victim's browser session, meaning the attacker's JavaScript executes in the origin of the WordPress site, giving access to cookies and local storage scoped to that domain. There is no indication of a non-default configuration requirement; any active installation of the affected plugin versions appears vulnerable.

The NVD CVSS 3.1 score of 7.1 (High) is driven primarily by the network attack vector, low complexity, no authentication requirement, and the scope change to the victim's browser context. However, each confidentiality, integrity, and availability impact metric is rated Low, tempering the overall severity. No EPSS data was provided, and the vulnerability is not listed in the CISA KEV catalog, nor is public exploit code confirmed. In practice, reflected or stored XSS in niche WordPress plugins tends to be exploited opportunistically rather than at scale; the UI:R requirement (victim must interact with a crafted link) limits the attack surface compared to fully passive exploitation. Real-world risk is moderate for sites that serve authenticated WordPress administrators or users whose session cookies could be stolen, but lower for purely public-facing deployments.

An attacker identifies a WordPress site running CP Media Player 1.3.0 or earlier, then crafts a URL embedding a malicious JavaScript payload in a parameter the plugin reflects without sanitization. The attacker delivers this URL to a logged-in WordPress administrator via phishing email or a forum post; when the admin visits the link, the script executes in their browser, exfiltrating their session cookie to an attacker-controlled server and granting the attacker administrative access to the WordPress site. No public proof-of-concept code has been identified, but the attack pattern for reflected XSS in WordPress plugins is well-understood and requires no advanced tooling.