CVE-2026-87759 in Add User Autocomplete Plugin
Summary
by MITRE • 09/12/2026
The Add User Autocomplete WordPress plugin before 1.2 does not perform any capability or nonce check before creating a pending site-membership invitation carrying a caller-supplied role, allowing any authenticated user, such as a subscriber, to grant themselves the administrator role on a multisite installation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in the Add User Autocomplete WordPress plugin prior to version 1.2 represents a critical failure in access control mechanisms within a Multisite environment. This flaw stems from the absence of proper authorization checks and integrity verification during the execution of user creation operations. Specifically, when an authenticated user initiates the process to invite another user or themselves for site membership, the plugin fails to validate whether the caller possesses the necessary administrative capabilities required for such actions. In a standard WordPress Multisite architecture, creating new users or assigning roles is typically restricted to super administrators or specific network admins who hold elevated privileges. By omitting these checks, the application effectively bypasses the intended security boundary that separates low-privilege users from high-privilege operations.
The technical root cause of this issue lies in the lack of a nonce verification and capability validation within the endpoint handling user invitations. A nonces is a unique token used to prevent Cross-Site Request Forgery attacks, ensuring that requests originate from legitimate sources rather than malicious third-party sites or automated scripts. Furthermore, WordPress relies on role-based access control where specific functions are gated by capabilities such as manage_network_users or create_sites. The plugin's code allows the caller-supplied role parameter to be processed without verifying if the current user is authorized to assign that level of privilege. Consequently, an attacker with even the most basic authenticated account, such as a subscriber, can manipulate this input field to request any role available in the system, including the highest-level administrator role.
The operational impact of this vulnerability is severe due to its potential for complete site compromise. Once an attacker successfully exploits this flaw and grants themselves the administrator role on the Multisite installation, they gain full control over the network's infrastructure. This includes the ability to install malicious plugins or themes, modify core files, access sensitive database information, and create additional backdoor accounts that persist even if the initial exploit is patched. In a Multisite context, this compromise can extend beyond a single site, potentially affecting all sub-sites within the network depending on how permissions are configured at the network level. The attacker could also exfiltrate user data, deface websites, or use the compromised server as part of a botnet for distributed denial-of-service attacks against other targets.
This vulnerability aligns with CWE-269, which describes Improper Privilege Assignment, and falls under MITRE ATT&CK technique T1078, Valid Accounts, specifically within the context of Initial Access or Persistence depending on how long the attacker maintains their foothold. The lack of nonce validation also relates to CWE-352, Cross-Site Request Forgery, as it allows state-changing requests to be performed without proper authentication tokens. To mitigate this risk, administrators must immediately update the Add User Autocomplete plugin to version 1.2 or later where these security checks have been implemented. If updating is not immediately feasible, disabling the plugin entirely until a patch can be applied is recommended. Additionally, implementing strict input validation and ensuring that all administrative actions require both valid nonces and explicit capability verification will prevent similar vulnerabilities in custom development practices. Regular auditing of user roles and monitoring for unexpected privilege escalations are also essential defensive measures to detect any potential exploitation attempts early.