CVE-2026-13741: Digits WordPress Plugin Privilege Escalation
TL;DR - Authenticated users can escalate privileges in Digits plugin versions up to 9.1.0.5. - Exploitation requires Subscriber-level access and a specific plugin role-field configuration. - Patch to the latest vendor release immediately and audit for unexpected admin role changes.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-13741 |
| CVSS | 8.8 High |
| Attack vector | Authenticated attack via profile update workflow; full CVSS vector not confirmed in available source material |
| Privileges required | Subscriber-level access or higher |
| Patch available | Yes, a vendor fix is implied by disclosure; exact fixed version was not conclusively verified from primary-source content available in this session |
CVE-2026-13741 is a high-severity privilege escalation flaw in Digits: WordPress Mobile Number Signup and Login, a WordPress plugin published by UnitedOver. The NVD states the bug affects all versions up to and including 9.1.0.5 and allows an authenticated attacker to escalate privileges to Administrator by abusing a profile update path.
The attack is not described as universally exploitable on every installation. According to the NVD description, the exploit path depends on a configuration condition: the site administrator must have enabled the plugin’s built-in DIGITS User Role field. For defenders, that means exposure depends on both installed version and feature configuration, not just plugin presence.
What Is This Vulnerability?
The root cause is missing authorization and role validation in the plugin function dig_update_wpwc_custom_fields(). In practical terms, the plugin appears to trust a user-supplied role field during a profile update operation without adequately checking whether the requester is authorized to assign that role.
The specific parameter named in the disclosure is digits_reg_userrole. If a low-privileged authenticated user can submit a forged value for that field and the plugin accepts it during the affected workflow, the user’s WordPress role can be elevated beyond what should be allowed. The impact described by NVD is direct escalation from Subscriber or equivalent low privilege to Administrator.
This is especially important in WordPress environments where self-registration is open, customer accounts are common, or low-privileged accounts are easy to obtain. Membership sites, WooCommerce deployments, and community sites often expose exactly the kind of authenticated surface that makes this class of bug operationally significant.
Technical Notes
The vulnerable behavior centers on a profile update path and the plugin-managed role field. A simplified representation of the risky pattern looks like this:
// Illustrative pseudo-pattern only, not vendor source
function dig_update_wpwc_custom_fields($user_id) {
$requested_role = $_POST['digits_reg_userrole'] ?? '';
// Missing: capability check for who can assign roles
// Missing: validation restricting role choices
wp_update_user([
'ID' => $user_id,
'role' => $requested_role
]);
}
From a defender’s perspective, the key issue is not generic profile editing. It is role assignment controlled by user input without sufficient authorization checks.
Who Is Affected?
The affected product is Digits: WordPress Mobile Number Signup and Login for WordPress, published by UnitedOver. The NVD states the vulnerable range is all versions up to and including 9.1.0.5. If your site runs 9.1.0.5 or earlier, it should be treated as vulnerable unless you have clear vendor documentation showing a backported fix.
The attack requires an authenticated account with Subscriber-level access or higher. That means internet-facing WordPress sites with public registration, customer accounts, or broad internal user populations should consider this more urgent than an admin-only flaw. The configuration precondition matters as well: the built-in DIGITS User Role field must be enabled by the administrator for the described exploit path to work.
What remains unknown from the source material gathered here is the exact first fixed version number. The vulnerable ceiling is explicit, but the patched release could not be conclusively extracted from the vendor changelog content available in this session. In the absence of that verification, defenders should upgrade to the latest available vendor release and confirm in release notes that it addresses this privilege-escalation issue.
Technical Notes
To identify installed plugin versions on a host, check the WordPress plugin metadata directly:
grep -R "Version:" /var/www/html/wp-content/plugins/digits/ -n
If WP-CLI is available, use it for cleaner inventory:
wp plugin list | grep -i digits
Example output to look for:
digits active available 9.1.0.5
CVSS Score Breakdown
The published CVSS v3.x base score is 8.8, which places this issue in the High severity range. The exact vector string was not returned in the source summary used here, so defenders should avoid assuming values for every CVSS component that are not explicitly published.
Even without the full vector, the high score makes sense operationally. Successful exploitation allows privilege escalation to Administrator, which typically means complete control of a WordPress site. In most WordPress environments, administrator access can lead to plugin installation, malicious code execution through theme or plugin changes, credential theft, content tampering, and persistence.
The required privileges are relatively low, since Subscriber-level access or higher is sufficient. That lowers the barrier to exploitation on sites that allow self-registration. The attack complexity also appears low from the description because the issue hinges on submitting a forged parameter during a normal profile update path rather than chaining multiple weaknesses.
If your risk model depends heavily on CVSS subcomponents, wait for the authoritative vector from NVD or the CNA record. Until then, use the published 8.8 High score as the decision point and prioritize internet-accessible sites with exposed registration or customer account functionality.
Exploitation Status
At the time of this writing, active exploitation in the wild is not confirmed in the source material gathered for this article. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog based on the research note provided. Absence from KEV does not mean the issue is safe to defer, but it does mean there is no KEV-backed confirmation of exploitation.
Likewise, a public proof of concept is not confirmed from the retrieved sources. Searches referenced in the research note did not produce a clear public exploit repository or standalone GitHub PoC tied to CVE-2026-13741. That status can change quickly for WordPress plugin bugs, especially when the vulnerable parameter and exploitation condition are already public.
For defenders, the right assumption is: treat as exploitable even if public exploitation is not yet confirmed. The vulnerability description names the function, parameter, access level, and precondition clearly enough that independent exploit development may be straightforward for attackers familiar with WordPress plugin internals.
Technical Notes
Current status based on available sources:
- PoC public: Not confirmed from retrieved sources
- Exploitation in the wild: Not confirmed from retrieved sources
- CISA KEV listed: No
Because exploitation requires authentication, attackers may combine this bug with credential stuffing, weak registration controls, or compromised customer accounts to gain the initial foothold.
How to Detect It
Detection should focus on unexpected profile updates, submission of the digits_reg_userrole parameter, and role changes involving low-privileged users. If the vulnerable configuration was enabled, a successful exploit could appear as a normal authenticated request unless you are logging request parameters or role change events.
Start by auditing WordPress users for recent elevation to Administrator from lower roles such as Subscriber, Customer, or Contributor. Pay special attention to accounts that were created recently, accounts associated with disposable email providers, or accounts with minimal normal site activity before the role change.
Review web server logs, WAF logs, and application logs around profile-edit endpoints. The exact path can vary by site and plugin workflow, so the most reliable anchor from the disclosure is the presence of digits_reg_userrole in an authenticated request. Even failed attempts to inject that parameter are worth investigating.
Technical Notes
A concrete grep pattern for access logs:
grep -R "digits_reg_userrole" /var/log/nginx/ /var/log/apache2/ 2>/dev/null
Example suspicious pattern:
POST /my-account/edit-account/ HTTP/1.1
Cookie: wordpress_logged_in_=...
digits_reg_userrole=administrator
If logs are centralized in Splunk:
index=web sourcetype IN ("nginx","apache")
"digits_reg_userrole"
| stats count by src_ip, http_user_agent, uri_path, http_status
If using Microsoft Sentinel with CommonSecurityLog or web logs:
CommonSecurityLog
| where RequestURL has "digits_reg_userrole" or AdditionalExtensions has "digits_reg_userrole"
| summarize count() by SourceIP, RequestURL, DestinationHostName
To audit administrator accounts via WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered,roles
Then compare historical backups, IAM records, or admin approval processes to identify unauthorized role assignments.
Mitigation and Patching
If you run Digits version 9.1.0.5 or earlier, patching should be your first priority. The vulnerable range is explicit: all versions up to and including 9.1.0.5. The exact first fixed version was not conclusively verified from the primary-source content available in this session, so the safest vendor-aligned guidance is to upgrade to the latest available Digits release from the official source and verify the changelog references a fix for this privilege-escalation issue.
If you cannot patch immediately, reduce exposure by disabling or removing the built-in DIGITS User Role field if your workflow allows it, since that feature is named as an exploitation precondition in the NVD description. You should also consider temporarily restricting new registrations, disabling low-trust account creation, and closely monitoring any account profile update operations until patching is complete.
After patching, audit the environment for compromise. Review administrator accounts, plugin/theme integrity, scheduled tasks, and recently modified files. Because a successful exploit results in Administrator rights, assume attackers could have installed persistence or altered site content even if obvious malicious activity is not yet visible.
Technical Notes
Use WP-CLI to update the plugin:
wp plugin update digits
If you manage plugins manually, validate the installed version afterward:
wp plugin get digits --fields=name,version,status
If immediate upgrading is not possible, a temporary containment step is to disable the plugin until maintenance can occur:
wp plugin deactivate digits
Additional response checks:
wp user list --role=administrator
find /var/www/html/wp-content/ -type f -mtime -7
wp plugin list
wp theme list
Because the fixed version number was not authoritatively confirmed in the material available here, do not stop at “newer than 9.1.0.5.” Confirm you are on the latest vendor release and review the official changelog before closing the incident.
References
Primary disclosure and tracking sources confirm the affected product, vulnerable version ceiling, exploit condition, and core root cause. The NVD entry is the most authoritative source in the provided material for the vulnerability description itself, including the role of the digits_reg_userrole field and the vulnerable function name.
Vendor and third-party references are also useful for defenders validating product identity and checking release notes or threat-intel context. Because the exact patched version was not directly extracted from the primary vendor content available in this session, the references below should be consulted directly during remediation.
- NVD CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2026-13741
- Official Digits vendor site: https://digits.unitedover.com/
- Official vendor changelog: https://digits.unitedover.com/changelog/
- Wordfence vulnerability reference: https://www.wordfence.com/threat-intel/vulnerabilities/id/02a283b2-a369-4927-a54a-61f26bee6ace?source=cve
- Wordfence human-readable advisory URL: https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/digits/digits-wordpress-mobile-number-signup-and-login-9105-authenticated-subscriber-privilege-escalation-via-digits-reg-userrole-parameter
For incident response teams, the key verified facts to retain are these: affected versions are all releases through 9.1.0.5, exploitation requires authenticated access at Subscriber level or above, the abuse path involves forging digits_reg_userrole during profile update, and active exploitation plus public PoC availability are not confirmed from the currently available source set.
For further information on security practices, you may want to check our articles on what is Blue Team and Dynamic Application Security Testing (DAST).
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.