Limit Login Attempts Reloaded CVE-2026-18356

Exploitation requires the attacker to already possess valid, working credentials - specifically, the password and either the username in a different case or the email address registered to the account - for a WordPress user that an administrator has placed on the plugin's denylist. The plugin must be installed and actively configured with a username denylist; sites that do not use this feature are not exposed. The bypass works via two independent paths: case variation of the blocked username, or substituting the account's email address for the username in the login form. Exploitation is strictly limited to accounts the attacker already controls credentials for and that have been specifically denylisted - it does not enable access to arbitrary accounts or circumvent WordPress's standard authentication. The CVSS AC:H metric captures this precondition: a specifically denylisted account with known credentials is an uncommon target in most real-world attack models.

The CVSS score of 3.7 with AC:H is technically accurate: an attacker must already possess valid, working credentials for a specifically denylisted account, which is an uncommon precondition in most attack models and sharply limits the population of exploitable scenarios. The primary operational risk falls on organizations that rely on the denylist feature as their sole mechanism for revoking a user's access - for example, when a former employee's account cannot be immediately disabled - and even a mid-sized municipal IT team in malbork running a WordPress-based intranet would be exposed if they trusted this plugin's denylist over WordPress's native account deactivation. No CISA KEV listing is present, meaning active in-the-wild exploitation is not confirmed at the time of analysis. A publicly available proof-of-concept from WPScan does lower the bar for abuse. EPSS data was not provided in the source intelligence and cannot be assessed. For sites that do not actively use the denylist feature, this vulnerability carries negligible real-world risk; for those that depend on it as an access-control control, the integrity impact is operationally meaningful despite the low raw score.

A former employee whose username 'JohnSmith' was placed on the plugin's denylist still knows their account password. They attempt login using 'johnsmith' (all lowercase) or enter their registered email address in the username field; the plugin's denylist check fails to match either variant against the blocked entry, and WordPress authenticates the session normally. A publicly available proof-of-concept from WPScan demonstrates both bypass paths.