CVE-2026-90976 in Clean Login Plugin
Summary
by MITRE • 09/18/2026
The Clean Login WordPress plugin before 1.19 does not check whether user registration is enabled before creating an account in its registration handler, allowing unauthenticated users to create accounts even when the site has registration disabled.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in versions of the Clean Login WordPress plugin prior to version 1.19 represents a critical failure in access control logic within the user registration subsystem. This flaw stems from an insufficient validation mechanism where the application fails to verify the global configuration setting that dictates whether new user registrations are permitted on the website. In standard WordPress environments, administrators can disable public registration through specific site settings to prevent unauthorized account creation and potential security breaches. However, the Clean Login plugin bypasses this administrative control by directly invoking its internal registration handler without checking the corresponding status flag in the WordPress database or configuration array.
From a technical perspective, this issue is classified as an improper check for permissions or privileges before performing actions on behalf of users, which aligns with CWE-285: Improper Authorization. The root cause lies in the plugin's code structure, where the registration endpoint operates independently of the core WordPress authentication and authorization layers that enforce site-wide policies. By not querying the wp_options table for the user_registration setting or checking the result of is_user_registered() related logic before proceeding with account creation, the software allows any unauthenticated actor to bypass intended restrictions. This lack of input validation regarding system state constitutes a significant logical error in security design.
The operational impact of this vulnerability is substantial, particularly for websites that rely on closed registration models such as intranets, membership sites requiring pre-approved access, or corporate portals where account creation must be managed exclusively by administrators. An unauthenticated attacker can exploit this flaw to create arbitrary user accounts with default privileges. While the newly created accounts may initially possess low-level permissions depending on WordPress defaults, they provide a foothold for further attacks. Attackers can use these valid credentials to attempt privilege escalation, conduct brute-force attacks against administrative panels from within the trusted network boundary, or store malicious data in user-specific databases if such functionality exists. This effectively negates the security posture established by disabling public registration and undermines the principle of least privilege.
This vulnerability maps directly to MITRE ATT&CK technique T1136: Create Account, which describes adversaries creating accounts on compromised systems for persistent access or lateral movement. By exploiting this flaw, an attacker can establish a legitimate identity within the application environment, facilitating subsequent phases such as credential harvesting or persistence mechanisms that are harder to detect than anonymous attacks. The ability to create accounts without authentication also complicates forensic analysis and audit logging, as these actions appear as standard user registrations rather than unauthorized intrusions unless specific behavioral analytics are in place.
To mitigate this risk, immediate action is required by upgrading the Clean Login plugin to version 1.19 or later, where the developers have implemented proper checks for registration settings before processing account creation requests. Administrators should also review their WordPress configuration to ensure that user registration remains disabled if not explicitly needed for public-facing services. Additionally, implementing Web Application Firewall rules can help detect and block abnormal patterns of rapid account creation from single IP addresses or unusual request payloads targeting the registration endpoint. Regular security audits and code reviews focusing on authorization checks in third-party plugins are essential to prevent similar logical flaws in future deployments.