Download Monitor EUVD-2026-48169

Exploitation requires the Download Monitor - WPForms Lock add-on version 1.0.4 or earlier to be installed and active on the target WordPress site, and - per the CVSS vector's UI:R - requires the victim to interact with an attacker-supplied link or request (this is not a fully automatable, no-interaction flaw). No authentication is required (PR:N), so the attacker themselves needs no account, but the payload only fires in the context of whoever is tricked into loading it; the value of the attack scales with the privilege of that victim (e.g., an authenticated administrator session yields more impact than an anonymous visitor). Limiting factors: the mandatory user interaction, the need for the specific vulnerable add-on to be present, and the browser-session-scoped impact rather than server compromise.

The signals here are moderate and internally consistent rather than alarming. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L, base 7.1 High) shows a network-reachable, low-complexity, unauthenticated flaw, but the mandatory user interaction (UI:R) is a meaningful limiter - a victim must click or load an attacker-crafted request. No EPSS score, no SSVC decision data, and no KEV/POC indicators were provided, so exploitation probability cannot be quantified from the input; based on class alone, reflected XSS in a niche add-on is realistically low-to-moderate priority. The C:L/I:L/A:L impacts are the typical Patchstack scoring convention for XSS (session/credential theft, defacement, redirect) rather than a full system compromise, so the practical impact is browser-session-level, not server-level code execution. Treat this as a routine patch-when-available web vulnerability unless the site handles sensitive authenticated sessions.

An attacker crafts a URL to the target WordPress site with a malicious script payload in a parameter handled by the WPForms Lock add-on, then lures a site visitor or logged-in administrator to click it (e.g., via phishing email or a malicious link). When the victim's browser loads the reflected response, the injected JavaScript runs in the site's origin and can steal the session/authentication cookies, perform actions as the victim, or redirect them. No public proof-of-concept is identified at time of analysis, and success depends on the victim performing the required interaction.