User Registration & Membership Auth Bypass (CVE-2026-1492): How a Leaked Nonce Becomes Admin Access

A critical authentication bypass vulnerability tracked as CVE-2026-1492 was disclosed this month in the User Registration & Membership plugin for WordPress. The flaw, rated CVSS 9.8, lets an unauthenticated attacker register a brand new account with the administrator role and walk straight into /wp-admin/. No credentials. No interaction. No exploit chain. Versions 5.1.2 and earlier are vulnerable. Version 5.1.3 contains the fix.

If you run this plugin on any site, update now and audit your user list for accounts you don't recognise. The rest of this post explains what the flaw actually is, why the standard WordPress nonce mechanism failed here, and what you should look for to confirm whether you were hit.

What the Plugin Does

User Registration & Membership is a registration, login, and membership plugin used on sites that need to go beyond the default WordPress signup form. It lets site owners build custom registration forms, set which role new users are assigned, gate content by membership level, and accept payments for paid membership tiers. The plugin ships with AJAX-powered flows so that users can sign up, log in, and update profile fields without full page reloads.

That AJAX layer is where the vulnerability lives.

The Core Flaw: Trusting the Client

Every serious WordPress developer has heard the mantra never trust the client. CVE-2026-1492 is a textbook demonstration of what happens when that mantra gets treated as optional.

The plugin exposes registration functionality through /wp-admin/admin-ajax.php actions. Like almost every WordPress AJAX endpoint, each action is protected by a nonce. A nonce is a short, time-limited token that WordPress uses to confirm a request originated from a page the server rendered. A correctly implemented nonce is tied to a specific user and a specific action, and checking it is usually enough to stop random outsiders from calling privileged endpoints.

The problem is that a nonce is only meaningful if the code on the other side actually verifies who is allowed to perform the action once the nonce check passes. In the vulnerable versions of User Registration & Membership, the registration handler does three things in a dangerous order:

1. It accepts a role parameter sent from the browser as part of the registration payload.
2. It verifies the nonce.
3. It creates a new user with whatever role the client asked for.

Nowhere in that sequence does the server compare the requested role against an allow-list of public roles such as subscriber or customer. Nowhere does it check the capability of the caller before honouring the role assignment. The nonce check gives the code a false sense of security because, in normal WordPress development, a nonce check implies the request came from an authenticated session. But a registration flow, by definition, is used by people who aren't yet logged in. The nonce for the public registration form is rendered into a JavaScript global that sits in the page HTML for anyone with a browser to read.

The result is that any visitor can open the page source, copy the nonce, craft a POST request that includes role=administrator, and hand themselves the keys to the site.

Why WordPress Nonces Do Not Stop This

This is worth dwelling on, because it's one of the most common misconceptions about WordPress security. (We cover it in depth in WordPress nonces: what they actually protect and what they don't.)

A nonce is not an authentication mechanism. It's a CSRF defence. Its single job is to prevent an attacker from tricking a logged-in user's browser into performing an action on their behalf from a different origin. When a nonce is embedded in a public HTML page, anyone can grab it. When the action protected by the nonce is designed for unauthenticated callers, like registration or contact form submission, the nonce provides zero defence against abuse of the parameters the endpoint accepts.

The defence you actually need for a public endpoint that creates users is server-side validation of every field that determines the resulting permissions. Specifically:

• The role must be hardcoded on the server, or pulled from a whitelist set in the plugin's settings. Never accept it from user input.
• If the plugin supports multiple public roles (for example, subscriber versus customer), the allowed values must be checked against an explicit allow-list.
• Any role requiring administrator or editor capabilities must never be assignable by an unauthenticated request, regardless of any nonce.
• Capabilities should be checked with current_user_can() where relevant, with the understanding that this will return false for anonymous callers. That's the point.

The patched version, 5.1.3, reportedly adds stricter validation and nonce handling, but the substantive fix is the input validation on the role parameter. Nonce handling alone cannot close this bug.

Attack Walkthrough

Here's the shape of the attack. The exact endpoint names and parameter keys are left out of this post deliberately. The pattern is the important part.

1. The attacker opens any page on the target site that renders the registration form. This is often a membership signup page that the site owner has built with the plugin's shortcode or block.
2. They view the page source and locate the nonce value that the plugin prints into a JavaScript object. These are typically named something like ur_frontend_script or a similar plugin prefix, and contain a nonce or ur_nonce key.
3. They open a terminal and send a POST request to /wp-admin/admin-ajax.php with the registration action, a username, an email, a password, the nonce they just copied, and a role field set to administrator.
4. The server verifies the nonce, finds it valid, and creates the user exactly as requested. The attacker receives a success response and immediately logs in.
5. From inside /wp-admin/, the attacker installs a file manager plugin, uploads a PHP backdoor, creates hidden users, exfiltrates the database, or pivots to other sites on the same server.

The entire sequence takes less than a minute and can be automated against a list of sites. Once discovery scanners know which page to request and which action name to use, the exploitation barrier drops to near zero. This is the same playbook behind several of the attacks we covered in how WordPress sites actually get hacked.

Why This Class of Bug Is So Common

Authentication bypass through client-controlled role assignment isn't a new pattern. Several high-profile WordPress plugins have shipped the same class of bug over the years: UserPro, Profile Builder, Ultimate Member, and others. The underlying reason is almost always the same. Registration flows are built as convenience wrappers around wp_insert_user(), and the wrappers evolve over time to accept more configuration from the client. Someone decides the form should support different roles for different membership tiers. The cleanest way to wire that up in a hurry is to pass the role as a form field. Then the plumbing to validate that field against an allow-list never gets added, or it gets added in a way that is easy to bypass.

Every time this class of bug surfaces, the postmortem ends up in the same place: treat every input from the client as attacker-controlled, and decide on the server what a registration is allowed to produce.

Am I Affected?

You are affected if all of the following are true:

• The User Registration & Membership plugin by WPEverest is installed and activated on your site.
• The version is 5.1.2 or earlier.
• Public user registration is enabled anywhere on the site (front-end form, shortcode, block, or membership checkout).

You aren't affected by this specific CVE if the plugin isn't installed, if you're already on 5.1.3 or later, or if you have hard-disabled user registration through another mechanism. Even so, the plugin should still be patched on sites where registration is technically disabled, because the AJAX endpoints can sometimes be reached directly even when no form renders them.

Immediate Actions

Update the plugin to 5.1.3 or later. This is the only complete fix. Do it before anything else on this list.

Audit wp_users and wp_usermeta for unexpected administrators. Log in to the database or run the following WP-CLI command on a staging copy of the site:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Look for accounts registered recently, accounts you don't recognise, or accounts using email addresses on disposable domains. Any administrator created through the vulnerable flow will appear here.

Check recent user registrations regardless of role. An attacker who knows you're watching for administrator accounts may create a subscriber first, escalate through another route, and clean up the evidence. List all users created in the last thirty days and scrutinise anything suspicious.

Rotate secrets. If you find any evidence of unauthorised administrator creation, assume the entire site is compromised. Rotate the WordPress salts in wp-config.php, force a password reset for all users, regenerate API keys, and check mu-plugins/, wp-content/uploads/, and wp-content/plugins/ for files that shouldn't be there. Our WordPress malware removal guide walks through a full cleanup.

Review server access logs. Look for POST requests to /wp-admin/admin-ajax.php with an action parameter related to registration, particularly bursts from the same IP or from IPs outside your normal traffic pattern. Correlate those with the timestamps of any new user accounts.

Install an integrity monitor going forward. A change to wp-config.php, the addition of a new file in wp-content/uploads/, or an out-of-hours modification to any PHP file inside a plugin directory is a strong signal that something slipped past you. Automated integrity monitoring catches these long before manual audits do. Our 9 signs your WordPress site has been hacked post has the full list of red flags to watch for.

How WP Vanguard Detects This

WP Vanguard's deep scan checks installed plugin versions against our vulnerability database, which now includes CVE-2026-1492. A site running any affected version of User Registration & Membership will flag as critical on the next scheduled scan with a direct link to the advisory and a recommendation to update to 5.1.3 or later.

In addition, the scanner watches for the side effects of successful exploitation rather than the exploit itself. Unexpected administrator accounts, new PHP files in upload directories, and modifications to core WordPress files all trigger their own findings, so a compromise that predates a vulnerability signature being added to the database will still surface. If you haven't scanned in the last week, queue a deep scan now.

The Longer Lesson

Authentication bypass vulnerabilities in WordPress plugins are a reminder that the security of your site is, in practice, the security of the least-careful third-party code you've installed. WordPress core has been through years of review and has a mature approach to capability checks. Plugins, especially ones written in a hurry to solve a product problem, routinely miss the details that core gets right.

The operational answer isn't to avoid plugins. For most sites, that isn't realistic. The answer is to minimise the attack surface you actually maintain. Remove plugins you aren't using. Prefer plugins with a track record of fast security response. Subscribe to a vulnerability feed, or better, run a scanner that subscribes to one for you. And when a critical CVE lands, treat the window between disclosure and patch as the most dangerous period in your plugin's life cycle. For a broader look at recent plugin disclosures, see our April 2026 vulnerability roundup.

CVE-2026-1492 is the kind of flaw that, if left unpatched, will eventually be found by an automated scan and exploited within minutes. If you run User Registration & Membership, patch it today. If you run any registration plugin, take this disclosure as a prompt to audit its recent history and ask yourself whether the registration endpoint is doing server-side validation of the fields that decide who gets to be an administrator on your site.

References

• CVE-2026-1492 disclosure on GBHackers
• CVE-2026-1492 technical writeup on Cyberpress
• CYFIRMA original research (credited as the source of the disclosure)