CVE-2026-18356 in Limit Login Attempts Plugin
Summary
by MITRE • 08/21/2026
The Limit Login Attempts Reloaded WordPress plugin before 3.3.5 does not compare logins against its username denylist case-insensitively and does not account for the account's email address, allowing an account an administrator intended to block from logging in to authenticate anyway.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The Limit Login Attempts Reloaded WordPress plugin is a widely utilized security tool designed to mitigate brute-force attacks by restricting the number of login attempts allowed within a specific timeframe. The vulnerability identified prior to version 3.3.5 stems from an insufficient input validation and case-sensitivity handling mechanism in its username denylist functionality. When administrators configure this plugin to block specific usernames, the underlying code performs string comparisons that are strictly case-sensitive. This technical flaw means that if an administrator intends to block a user with the username admin, entering Admin or ADMIN will bypass the restriction because the comparison logic fails to normalize the input strings before evaluation.
This lack of case-insensitive matching creates a significant security gap in access control enforcement. An attacker who is aware of this limitation can easily circumvent the denylist by altering the capitalization of the blocked username during authentication attempts. Furthermore, the vulnerability extends beyond simple casing issues; the plugin fails to account for the associated email address when determining whether an account should be blocked. In many WordPress configurations and security policies, blocking a user often involves targeting both their unique identifier (username) and their contact information (email). By ignoring the email field in its block logic, the application allows accounts that match either the username or the email to potentially bypass restrictions if only one of these fields is explicitly targeted by the denylist rules.
The operational impact of this vulnerability is substantial for organizations relying on WordPress as a content management system. Attackers can exploit this flaw to maintain persistent access to administrative accounts even after security measures have been ostensibly applied. This undermines the effectiveness of brute-force protection mechanisms, allowing malicious actors to continue guessing passwords or conducting credential stuffing attacks against targeted users. The ability to bypass denylists through case manipulation and email oversight means that standard defensive configurations are rendered ineffective without additional manual verification steps by system administrators.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the application fails to properly sanitize or normalize user-supplied input before processing it against security rules. It also relates to CWE-798 Use of Hard-coded Credentials if interpreted broadly as failing to enforce dynamic access controls correctly, but more accurately fits under CWE-613 Insufficient Session Expiration or Access Control flaws where the enforcement mechanism is bypassed due to logical errors. In terms of MITRE ATT&CK mapping, this vulnerability facilitates T1110 Brute Force and potentially T1078 Valid Accounts by allowing attackers to maintain access through configuration evasion techniques.
To mitigate this risk, organizations must immediately update the Limit Login Attempts Reloaded plugin to version 3.3.5 or later where these logical flaws have been corrected. The updated versions implement case-insensitive string comparisons for username denylists and properly integrate email address checks into their blocking logic. Until an upgrade is feasible, administrators should consider implementing additional layers of defense such as two-factor authentication for all administrative accounts, using web application firewalls to filter suspicious login patterns based on IP reputation rather than just account names, and regularly auditing plugin configurations to ensure that security controls are functioning as intended across different input variations.