CVE-2026-19652 in Divi Membership Plugin
Summary
by MITRE • 10/02/2026
The Divi Membership plugin for WordPress is vulnerable to Privilege Escalation in versions up to, and including, 2.2.0. This is due to the `dmem_form_submit_handler()` function determining the new user's role by iterating all WordPress roles and calling `password_verify()` against an attacker-controlled bcrypt hash supplied in the `form_id` POST parameter, with no validation or whitelist of allowed roles. This makes it possible for unauthenticated attackers to register a new account with the administrator role by submitting a locally computed bcrypt hash of `administrator` as `form_id`, and when `auto_login=on` is submitted, be immediately authenticated as that administrator in the same request, resulting in full site takeover. Exploitation requires a WordPress nonce, but that nonce is publicly emitted on any page rendering the Divi Membership registration form and is therefore obtainable by any unauthenticated visitor.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified within the Divi Membership plugin for WordPress versions up to 2.2.0 represents a critical privilege escalation flaw rooted in insecure direct object references and improper access control mechanisms. The core technical defect resides within the `dmem_form_submit_handler()` function, which is responsible for processing new user registrations via web forms. Instead of validating that the requested role belongs to an authorized list or checking if the current user has permission to assign such roles, the code blindly iterates through all available WordPress roles. It then attempts to match a bcrypt hash provided by the attacker in the `form_id` POST parameter against the password field associated with each role definition. This logic assumes that only valid hashes for legitimate roles will be submitted, failing to account for an adversary who can locally generate specific cryptographic outputs.
The exploitation vector relies on the ability of an unauthenticated actor to craft a malicious registration request containing a pre-computed bcrypt hash corresponding to the administrator role. Since WordPress uses standard PHP password hashing functions that are deterministic given the same salt and cost factor, an attacker can compute this hash offline without needing access to any server-side secrets or existing user passwords. By submitting this crafted hash as part of the `form_id` parameter during registration, the vulnerable function matches it against the administrator role entry in its iteration loop. Consequently, the system assigns the newly created account the highest level of privileges available on the platform, effectively bypassing all intended access restrictions for new users.
A significant factor enabling this exploitation is the handling of authentication tokens and session management within the plugin's workflow. The vulnerability description notes that while a WordPress nonce is required to submit the form, these nonces are publicly emitted in the HTML source code of any page containing the Divi Membership registration form. This means that unauthenticated visitors can easily extract valid nonces without prior login or special privileges. Furthermore, when the attacker submits their malicious request with the parameter `auto_login=on`, the plugin automatically logs them into the newly created account within the same HTTP transaction. This seamless transition from anonymous visitor to authenticated administrator eliminates any intermediate steps where additional verification might have occurred, allowing for immediate full site takeover and complete compromise of the WordPress environment.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Assignment, as the system fails to enforce proper role-based access controls during user creation. It also relates closely to CWE-862 Missing Authorization, since the application does not verify whether the actor has permission to assign specific roles before doing so. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is indicative of T1078 Valid Accounts and potentially T1136 Create Account, where an adversary creates a persistent access point with elevated privileges for later exploitation or lateral movement within the network infrastructure.
Mitigation strategies must prioritize immediate patching to version 2.2.1 or higher, where this logic has been corrected to enforce strict role whitelisting and prevent arbitrary role assignment via form parameters. Until patches are applied, administrators should consider disabling public registration forms if they are not strictly necessary for their business model. Additionally, implementing Web Application Firewall rules that monitor for anomalous patterns in user creation requests, such as unusually large or specific binary data in standard text fields like `form_id`, may provide a layer of defense against automated exploitation attempts. Regular auditing of installed plugins and ensuring that all third-party extensions are kept up to date with their latest security releases is essential to maintaining the integrity of WordPress-based environments susceptible to similar privilege escalation flaws.