Clean Login CVE-2026-54184

Target site must run WordPress with the Clean Login plugin by Alberto Hornero installed and active at version 1.15 or earlier, and the vulnerable plugin endpoint (front-end login/registration/account-management page or its AJAX/REST handler) must be reachable by the attacker over the network. Per CVSS PR:N/UI:N, no authentication and no user interaction are required, and AC:L indicates no special timing or non-default configuration is needed beyond the plugin being enabled. Exploitation is limited to objects managed by the plugin (C:N, I:L, A:H), so sites that have deactivated Clean Login or restricted access to its endpoints via WAF/ACL are not exposed.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N is consistent with a remote, unauthenticated WordPress endpoint reachable over HTTP(S), and the U scope with C:N/I:L/A:H implies the impact is constrained to objects managed by the plugin itself rather than the whole WordPress installation - most plausibly the ability to alter or destroy user account records, password-reset tokens, or registration data, leading to lockouts or denial of login functionality. No EPSS score, KEV listing, or POC reference is provided in the input, so prioritisation must rely on the CVSS vector and Patchstack's authentication-bypass tag alone; the combination of PR:N and AC:L on an internet-facing WordPress component is the type of issue that historically attracts opportunistic scanning even without a published exploit. Note one inconsistency worth verifying: the title says 'IDOR' (typically an authorisation flaw, not auth bypass), yet the tag says 'Authentication Bypass' - defenders should confirm with the Patchstack advisory whether session establishment itself or only post-auth object access is affected, because that materially changes the blast radius.

An unauthenticated attacker enumerates or guesses identifiers used by a Clean Login endpoint (e.g. a user ID, account record, or password-reset token parameter) and issues crafted HTTP requests to the plugin's front-end or AJAX handler. Because the handler does not verify ownership or capability, the request mutates or destroys account-related objects belonging to other users, locking legitimate users out or otherwise degrading the login workflow. No public PoC is referenced in the input, so opportunistic mass-exploitation has not been observed in the provided data.