Published October 26, 2026. Based on public reports available on that date; details may change.
CVE-2026-110523 affects WP User Manager versions 2.9.21 through 2.9.25. The CVE record describes it as unauthenticated privilege escalation through paid registration: someone registering on the site can end up with access that the paid-registration settings are meant to restrict. Update to version 2.9.26 or later, then review recently created accounts and their roles.
What happened
The public record concerns paid-registration capability restrictions in WP User Manager. Sites use registration rules to decide what a new user can do after registering. The reported behavior can leave those capability restrictions unenforced after the registration process.
The result depends on how an individual site configured paid registration and what access it connects to an account. Review the site rather than assuming every registration received the same access. Focus on newly created users, their WordPress roles, and any member, customer, or other access tied to those roles.
The cited public records did not report exploitation in the wild at publication. The absence of a public exploitation report does not undo an affected site's access rules. Update promptly and make the account review part of the corrective work.
Who is affected
WP User Manager versions before 2.9.26 are affected. Version 2.9.26 is the listed fixed release.
Start in the dashboard at Plugins and find WP User Manager. Note the installed version and whether it is active. WP-CLI users can list versions from the WordPress directory with:
wp plugin list --format=table
Compare the version shown for WP User Manager with 2.9.26. Check live, staging, and other maintained installations separately. If a staging site holds copies of user data, treat its account list and access controls seriously too.
Next, document the intended registration process. Identify which registration forms are paid, what an approved new account should receive, and which roles should never be assigned by that process. This record gives you a baseline for reviewing registrations without relying on memory.
Review recently registered users
The priority after checking the version is a focused account review. In Users, sort or filter your list by the most recent registrations if your administration tools support it. Compare each new account with the enrollment, payment, or approval record the business normally uses.
- Record the username, registration date, role, and expected access for accounts under review.
- Identify accounts that received a role or capability outside the paid-registration design.
- Disable access or correct roles only after preserving the information needed to understand the account change.
- Remove duplicate, test, or former-staff accounts that do not have a current owner.
- Review custom roles and plugin settings that connect registration to membership or paid access.
An unfamiliar account is not automatically evidence of abuse. A customer may have registered through a legitimate process, or an administrator may have created the account. Confirm the business context before removing it, especially where the account represents a paying customer.
For a broader account review, see how to find hidden WordPress admin users. The WordPress hardening checklist also covers reducing unnecessary access across a site.
Update WP User Manager and test registration
Make a current backup of the site files and database, then update WP User Manager to 2.9.26 or a later available release using the dashboard's Plugins screen. If you use WP-CLI, inspect available updates first:
wp plugin list --update=available --format=table
After the approved update is complete, run wp plugin list --format=table and confirm that WP User Manager shows 2.9.26 or later. Test the registration journey using a safe account and the site's normal test procedure. Confirm that the account receives only the role and access the configuration intends.
Do not use a production customer account for a test if you can avoid it. If the registration workflow involves payment, coordinate the test with the person responsible for that service so you do not create a real charge or confuse a customer record. Keep debug or test information out of public pages.
Maintain a small change record showing the prior version, updated version, date, and test result. That is useful during future maintenance and if you need to distinguish an application issue from an account-management issue. The WordPress maintenance plan checklist can help make that routine.
Investigate broader warning signs separately
This CVE concerns registration restrictions. It does not explain unrelated signs such as search spam, redirects, unknown PHP files, or changed core files. If those signs appear, create a safe copy of the site before cleaning anything and follow an incident response process.
From the WordPress directory, wp core verify-checksums checks whether core files match the official checksums for the installed WordPress version. It does not validate user roles, plugin code, uploads, or database entries. For a suspected compromise, the guide to fixing a hacked WordPress site gives a careful sequence.
When to get help
Get help if you find registrations with unexpected access, cannot safely test a paid-registration workflow, or suspect unauthorized account changes. A WordPress security audit can review roles, registration settings, and plugin updates. If the site has evidence of an active compromise, see WordPress malware removal.