WPS Limit Login EUVD-2026-85464

Exploitation requires an unauthenticated attacker to deliver a crafted request/URL to the WPS Limit Login plugin (versions <= 1.5.9.3) that reflects attacker-controlled input into a page without proper output encoding, AND a victim (site visitor or logged-in administrator) must interact with that link for the payload to fire (UI:R) - it is not a silent server-side compromise. The primary limiting factors are the mandatory user interaction, the requirement that the vulnerable WordPress site actually has this plugin installed and active, and that impact is confined to the victim's browser session in the site origin (client-side), not the WordPress server itself.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L, base 7.1) describes a network-reachable, low-complexity, unauthenticated cross-site scripting flaw whose exploitation nonetheless hinges on user interaction (UI:R) - a victim must click or load an attacker-crafted link/request. The scope change (S:C) reflects the standard XSS pattern where injected script executes in the browser security context rather than the WordPress server. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active or automatable exploitation. The A:L (and to a degree I:L) impacts appear generous for a reflected XSS: realistic outcomes are session/UI manipulation and limited data exposure, not availability loss - I would model A:N, yielding roughly 6.1. Net assessment: a genuine but not urgent web-hygiene issue - the 7.1 is driven by the S:C scope change, while the UI:R gate and absence of any exploitation signal place this well below a drop-everything priority. The single supporting reference is a Patchstack database entry; affected-version and impact details rest entirely on that one advisory.

An attacker crafts a malicious URL (or a form/request targeting the plugin) containing a script payload in an unsanitized reflected parameter and lures a WordPress site visitor or administrator into clicking it. When the victim's browser loads the response, the injected JavaScript executes in the site's origin, enabling session-token theft, forced admin actions, or content manipulation. No public exploit code is identified at time of analysis, and success requires the victim to interact with the crafted link (UI:R).