CVE-2026-93622 in Wps Limit Login Plugin
Summary
by MITRE • 09/23/2026
Unauthenticated Cross Site Scripting (XSS) in WPS Limit Login <= 1.5.9.3 versions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified as an unauthenticated cross-site scripting flaw within the WPS Limit Login plugin, specifically affecting versions up to and including 1.5.9.3, represents a significant security risk for WordPress-based websites that utilize this specific access control mechanism. This plugin is designed to restrict login attempts based on IP addresses or user credentials to mitigate brute-force attacks, but its implementation contains critical input validation errors that allow attackers to inject malicious scripts into the application's response stream without requiring any form of authentication. The core technical flaw stems from insufficient sanitization and encoding of user-supplied data before it is rendered in HTML contexts within the plugin’s administrative interface or error handling pages. When an attacker crafts a specially crafted HTTP request containing embedded JavaScript code, typically targeting query parameters or POST fields associated with login restriction configurations or status displays, the application fails to properly escape special characters such as angle brackets and quotes. This failure allows the injected script to execute in the context of the victim’s browser session whenever the vulnerable page is loaded by an administrator or any user with sufficient privileges to view the affected interface.
From a technical perspective, this vulnerability aligns closely with CWE-79, which classifies improper neutralization of input during web page generation as cross-site scripting. The absence of output encoding means that the browser interprets the injected payload not as plain text but as executable code within the Document Object Model. This execution context is particularly dangerous because it grants the attacker the same privileges as a legitimate user interacting with the WordPress dashboard. In many deployments, this includes administrative users who have full control over site content, plugins, themes, and potentially server-level configurations if further exploitation chains are present. The unauthenticated nature of the exploit means that no valid credentials or session tokens are required to trigger the vulnerability, lowering the barrier for entry significantly and allowing any internet user with knowledge of the target URL structure to initiate the attack vector remotely via standard web requests.
The operational impact of this cross-site scripting flaw extends beyond simple defacement or nuisance alerts. Attackers can leverage the executed script to perform session hijacking by stealing administrative cookies, thereby gaining unauthorized access to the WordPress backend without needing to crack passwords. Furthermore, the vulnerability enables phishing attacks where the attacker can inject fake login forms that mimic legitimate WordPress authentication screens to harvest credentials from other users who visit the compromised page. In more advanced scenarios, the malicious script can be used to perform cross-site request forgery actions on behalf of authenticated administrators, such as creating new admin accounts, modifying site settings, or installing additional malware plugins. This effectively compromises the integrity and confidentiality of the entire web application ecosystem hosted by the affected WordPress instance.
Industry frameworks categorize this type of vulnerability under ATT&CK technique T1059, which covers command and script interpretation, specifically within the context of browser-based execution through DOM manipulation. The lack of input validation also reflects weaknesses in data handling practices that are often flagged during security audits as violations of secure coding standards recommended by organizations like OWASP. To mitigate this risk, immediate action is required to update the WPS Limit Login plugin to a version newer than 1.5.9.3 where these sanitization issues have been addressed by the developers. If updating is not immediately feasible, administrators should implement web application firewall rules that detect and block common XSS payloads in HTTP requests targeting the vulnerable endpoints. Additionally, enforcing strict Content Security Policy headers can help mitigate the impact of any successful injection by restricting the sources from which scripts are allowed to execute, thereby reducing the effectiveness of client-side attacks even if input validation gaps remain temporarily unpatched.