CVE-2026-18356: 
WordPress vulnerability analysis and mitigation

CVE-2026-18356 is an authentication bypass vulnerability in the Limit Login Attempts Reloaded WordPress plugin affecting all versions before 3.3.5. The plugin fails to compare submitted usernames against its denylist case-insensitively and does not check whether the submitted login corresponds to the email address of a denylisted account, allowing a blocked user to authenticate successfully. It was publicly disclosed on August 17, 2026, with the CVE published on August 21, 2026. The vulnerability carries a CVSS v3.1 base score of 3.7 (Low), assigned by WPScan (WPScan, GitHub Advisory).

The root cause is classified as CWE-184 (Incomplete List of Disallowed Inputs): the plugin's denylist check performs a case-sensitive string comparison against submitted usernames, meaning a blocked username like Admin can be bypassed by submitting admin or ADMIN. Additionally, the plugin does not evaluate whether the submitted login value matches the email address associated with a denylisted account, providing a second bypass route. On single-site WordPress installations, both the case-variant and email-address routes are exploitable; on multisite installations, WordPress normalizes the submitted login before the plugin's check runs, leaving only the email address bypass available. Exploitation requires the attacker to already possess valid credentials for the denylisted account — the vulnerability defeats an administrator's intended block rather than granting access beyond what the password already permits (WPScan, GitHub Advisory). A proof-of-concept is scheduled for public release on August 31, 2026 (WPScan).

Successful exploitation allows an attacker who holds valid credentials for a denylisted account to bypass the administrator's intended login restriction and authenticate to the WordPress site. The integrity impact is limited — no confidentiality or availability impact is assessed — but the bypass undermines access control decisions made by site administrators, potentially allowing a previously revoked or suspended user to regain access to their account and any associated privileges. Sites that rely solely on the plugin's username denylist as a means of revoking access are most at risk; sites where the denylist is empty (the default state) are not affected (WPScan, GitHub Advisory).

There is currently no evidence of in-the-wild exploitation or a publicly available proof-of-concept; WPScan has withheld the PoC until August 31, 2026, to allow time for users to update. CISA's SSVC assessment classifies exploitation as "none" and the attack as non-automatable with partial technical impact. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to already possess valid credentials for the targeted denylisted account, significantly limiting the attacker pool (WPScan, GitHub Advisory).

1. Identify target: Confirm the WordPress site uses the Limit Login Attempts Reloaded plugin (version < 3.3.5) and that the administrator has populated the local username denylist with at least one account.
2. Obtain credentials: Acquire valid credentials (username and password) for an account that has been added to the plugin's denylist — for example, through prior credential theft, phishing, or credential stuffing.
3. Attempt case-variant login (single-site): On a single-site WordPress installation, submit the login form using a case-variant of the denylisted username (e.g., if Admin is blocked, submit admin, ADMIN, or aDmIn) along with the correct password.
4. Attempt email-address login (single-site or multisite): Alternatively, submit the email address associated with the denylisted account as the login identifier instead of the username, along with the correct password. This route works on both single-site and multisite installations.
5. Authenticate successfully: Because the plugin's denylist check does not account for case variants or email addresses, the submitted login bypasses the block and WordPress authenticates the session normally (WPScan).

• Logs: WordPress authentication logs (wp-login.php access logs) showing successful logins from accounts that should be blocked, particularly where the submitted username differs in case from the denylisted entry or where the login field contains an email address rather than a username.
• Logs: Plugin or WordPress debug logs recording successful authentication events for users listed in the Limit Login Attempts Reloaded denylist.
• Network: Repeated login attempts to wp-login.php using email addresses or mixed-case username variants for known or previously active accounts.
• Application: Unexpected active sessions for user accounts that administrators believed were blocked via the plugin's denylist.

Update the Limit Login Attempts Reloaded plugin to version 3.3.5 or later, which addresses both the case-sensitivity and email address bypass issues (WPScan, GitHub Advisory). As an interim measure, administrators should use WordPress's native account management controls — such as removing the user's role, changing their password, or deleting the account — rather than relying solely on the plugin's denylist to prevent unwanted logins. If the denylist is empty (the default), the site is not affected by this vulnerability.

The vulnerability was discovered and reported by researcher Artus KG, who also submitted it to WPScan. No significant broader media coverage or notable community commentary beyond the standard advisory disclosures has been identified at this time (WPScan).