Open User Map EUVD-2026-72647

Exploitation requires that the target WordPress site has the Open User Map plugin installed and active at version 1.4.50 or earlier, and that the plugin's map display is publicly accessible to unauthenticated visitors for payload delivery. The victim must load or navigate to the page rendering the injected map content (UI:R), meaning exploitation is not fully automated end-to-end - the attacker must wait for a victim to visit the page or craft a link that causes a targeted user to do so. No special server-side configuration beyond plugin activation is required. Exploitation is limited by the need for victim interaction and is further constrained by the requirement that the injected payload remains present in the rendered map output between submission and victim page load.

The CVSS 7.1 score is driven by the network attack vector, no authentication requirement (PR:N), and scope change (S:C), offset by the mandatory user interaction (UI:R) - a victim must actively load the affected page for the payload to execute. EPSS data is not provided in the input, and the vulnerability is not in CISA KEV, so no public exploitation signal elevates urgency beyond the base score. The A:L availability component in the provided vector is atypical for XSS and may be overstated unless the plugin exposes map data that can be corrupted causing rendering failures; this should be independently verified. For WordPress deployments in general, unauthenticated XSS in plugins is frequently targeted by automated scanning campaigns, meaning even a mid-sized municipal IT team in koszalin should treat this as urgent given WordPress's prevalence in public-sector web infrastructure. No public exploit code or POC has been identified at time of analysis, which modestly lowers near-term exploitation probability.

An attacker identifies a WordPress site running Open User Map <= 1.4.50 and submits a crafted map entry or input field containing a malicious JavaScript payload without requiring any authentication. When a logged-in WordPress administrator or ordinary site visitor loads the affected page, their browser executes the injected script, allowing the attacker to exfiltrate session cookies, capture credentials, or redirect the victim to a phishing page. No public POC has been identified, but the unauthenticated submission vector makes this straightforwardly automatable against any site exposing the plugin.