CVE-2026-15992: WP Password Policy Privilege Escalation

CVE-2026-15992 Overview

CVE-2026-15992 is a privilege escalation vulnerability affecting the WP Password Policy plugin for WordPress in all versions up to and including 3.7.1. The flaw resides in the get_user() function of the Module_Password_Hint class, which fails to perform authorization checks or nonce verification before invoking WP_User::set_role(). Authenticated attackers with subscriber-level access can escalate to Administrator by submitting a crafted POST request to the password-reset form endpoint. The vulnerability is classified under CWE-269: Improper Privilege Management.

Critical Impact
Any authenticated WordPress user with subscriber privileges or higher can promote themselves to Administrator, achieving full control over the affected site.

Affected Products

WP Password Policy plugin for WordPress, versions up to and including 3.7.1
WordPress sites running the password-requirements plugin package
Any WordPress deployment permitting subscriber-level user registration with the vulnerable plugin installed

Discovery Timeline

2026-07-28 - CVE-2026-15992 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-15992

Vulnerability Analysis

The vulnerability exists in the Module_Password_Hint class within the WP Password Policy plugin. The get_user() function is hooked to the password_hint filter, which fires during rendering of the WordPress password-reset form. When invoked, the function reads the user_login value from the incoming POST request and resolves it to a WP_User object. It then unconditionally calls WP_User::set_role() using the attacker-supplied role parameter.

The function performs no capability check to confirm the caller possesses promote_users or equivalent authority. It also omits nonce verification, meaning the request is not tied to any legitimate administrative workflow. Because the sink is reachable during a password-reset flow, an attacker only needs a valid password-reset cookie to trigger role assignment.

Root Cause

The root cause is missing authorization enforcement combined with absent request integrity validation. The get_user() method trusts request parameters implicitly and applies role changes to arbitrary user accounts. The plugin conflates the password-hint rendering context with a privileged user-management operation, exposing WP_User::set_role() to unauthenticated intent from any authenticated session.

Attack Vector

An attacker first authenticates to the target WordPress site with any account at subscriber level or above. The attacker then initiates a password-reset flow to obtain the required cookie. Next, the attacker submits a POST request to the password-reset form endpoint with action set to createuser, user_login set to the attacker's own account name, and role set to administrator. The password_hint filter fires during form render, invoking get_user(), which reassigns the specified account to the Administrator role. The attacker now holds full site control, including the ability to install plugins, execute PHP, and pivot to underlying infrastructure.

Refer to the Wordfence vulnerability report and the vulnerable code paths at line 39 and line 54 for technical details.

Detection Methods for CVE-2026-15992

Indicators of Compromise

POST requests to the WordPress password-reset endpoint containing action=createuser and role=administrator parameters
Unexpected role changes recorded against user accounts, particularly promotions to Administrator from subscriber or contributor tiers
New Administrator-level accounts created shortly after password-reset activity from low-privilege sessions
Web server access logs showing repeated password-reset form submissions from a single authenticated session

Detection Strategies

Audit the wp_usermeta table for role changes not correlated with legitimate administrative activity
Deploy a Web Application Firewall (WAF) rule to flag password-reset requests that include a role parameter
Correlate authentication logs with role-change events to identify low-privilege users triggering Administrator promotions
Enable WordPress audit logging plugins to capture set_role invocations with request context

Monitoring Recommendations

Alert on any WordPress user whose capabilities change to include manage_options outside of a change-management window
Monitor plugin file integrity for password-requirements/src/modules/password-hint/class-module-password-hint.php to detect tampering or exploitation attempts
Forward WordPress and web server logs to a centralized SIEM for cross-source correlation of privilege escalation patterns

How to Mitigate CVE-2026-15992

Immediate Actions Required

Update the WP Password Policy plugin to a version above 3.7.1 as soon as a patched release is available from the vendor
Review all Administrator and Editor accounts and remove any that cannot be attributed to legitimate personnel
Disable open user registration on affected WordPress sites until the plugin is patched or removed
Rotate credentials and reset sessions for all privileged WordPress accounts on affected installations

Patch Information

At the time of publication, verify the latest release on the WordPress plugin repository and consult the Wordfence advisory for the fixed version. Administrators should confirm the patch removes the unauthenticated call to WP_User::set_role() inside Module_Password_Hint::get_user().

Workarounds

Deactivate and remove the WP Password Policy plugin until a fixed version is installed
Block POST requests to wp-login.php containing the role parameter at the WAF or reverse proxy layer
Restrict access to the WordPress login and password-reset endpoints by source IP where operationally feasible
Enforce least-privilege registration defaults so new accounts cannot progress beyond subscriber without administrative approval

bash

# Example WAF rule (ModSecurity syntax) to block role parameter injection
SecRule REQUEST_URI "@contains wp-login.php" \
    "chain,phase:2,deny,status:403,id:1026159920,msg:'CVE-2026-15992 exploitation attempt'"
    SecRule ARGS:role "@rx .+" "t:none"