WordPress Open Registration and Admin Default Role Check

If your WordPress site lets anyone register and gives new users the Administrator or Editor role, a stranger can fill in the sign-up form and get control of your content, or of the whole site. WordPress 7.0, released on 20 May 2026, now flags exactly this combination as a critical issue in Site Health. You can check the setting quickly, but remediation time depends on how many accounts need review and whether the site may already be compromised.

By the end of this guide you will know how to read both settings in wp-admin and with WP-CLI, find the new Site Health warning, review who already has admin rights, and close the hole without locking yourself or a real colleague out.

What open registration with a privileged default role actually is

Two settings work together here. The first is the Anyone can register checkbox, which lets any visitor create an account on your site. The second is New User Default Role, which decides what that new account is allowed to do.

A role in WordPress is a named set of permissions. The official roles page describes them like this, from most to least powerful on a single site:

• Administrator: somebody who has access to all the administration features within a single site.
• Editor: somebody who can publish and manage posts including the posts of other users.
• Author: somebody who can publish and manage their own posts.
• Contributor: somebody who can write and manage their own posts but cannot publish them.
• Subscriber: somebody who can only manage their profile.

Think of it like the front door of an office building. Letting anyone walk into the lobby is fine. Handing every visitor the master key at reception is not. Open registration is the lobby. The default role is the key you hand out.

Each setting alone is usually fine. Open registration with Subscriber as the default is how many membership and comment sites work. Administrator as the default with registration closed changes nothing, because nobody can sign up. The danger is the combination.

Why this matters: an Administrator can install plugins and edit settings, which on most sites means full control. An Editor cannot do that, but can publish, change or delete every post on the site, which is plenty for spam links, phishing pages or defacement.

What changed in WordPress 7.0

The WordPress 7.0 Field Guide, published on 14 May 2026, lists this under "More secure user registration". In short:

• Administrator and Editor are removed from the New User Default Role dropdown on the General settings screen.
• Site Health alerts you if one of those roles was already selected before you updated.
• Developers get a new filter, default_role_dropdown_excluded_roles, to change which roles are hidden from that dropdown.

The code change behind it is core changeset 61687, which fixes ticket 43936. It adds a Site Health test called insecure_registration with the label "Open Registration with privileged default role". The test reports a critical status when registration is open and the default role is Editor or Administrator. Otherwise it passes.

Heads up: updating to 7.0 does not change your saved setting. If your site already had Administrator or Editor as the default, the changeset keeps that value visible in the dropdown so you can see it. You still have to change it yourself.

Before you start

This is a low-risk check. Reading settings changes nothing. The risky part is changing roles on existing accounts, so take it slowly there.

• Administrator login to wp-admin on the site you are checking.
• WordPress 7.0 or later if you want the new Site Health warning. The settings themselves exist on older versions too.
• Optional: SSH access with WP-CLI, the official command-line tool for WordPress. Every check in this guide also works in wp-admin.
• A fresh backup that you have tested, or at least know how to restore.
• A list of the people who should have Administrator or Editor access. Ask the owner if you are not sure.
• Review time depends on the number of accounts and whether suspicious access is found. The read-only checks are low risk; role, password and incident-response changes can lock out legitimate users or alter evidence.
• A staging copy if your site uses custom roles from a shop, membership or LMS plugin.

This guide covers a normal single WordPress site. I did not verify these steps on multisite networks, so check the multisite docs before you apply them there.

How to check and fix your registration settings

Work through the steps in order. Steps 1 to 4 only look. Steps 5 and 6 change things.

Step 1: Back up the site and note your admin users

Before you touch any user or setting, make a backup you can restore. If you need a walkthrough, follow our guide to backing up your website with an off-site copy and a test restore.

Then write down who has the Administrator role right now. You will compare against this list later, and it protects you from removing the wrong person.

If you use WP-CLI, run this command from your WordPress folder to list every Administrator as CSV. This exact command is an example on the official wp user list page.

wp user list --role=administrator --format=csv

You should see a header line and one line per admin. By default the fields are ID, user_login, display_name, user_email, user_registered and roles. Copy the output into a note.

Quick tip: user_registered is the date the account was created. A brand new admin you did not create is the single most useful clue in this whole guide.

Step 2: Check the General settings

In wp-admin, open Settings > General. Scroll to the Membership row and the New User Default Role dropdown.

• If Anyone can register is unticked, nobody can sign up on their own. You are fine for this issue, whatever the default role says.
• If it is ticked, look at New User Default Role. Subscriber is the safe common choice. Administrator or Editor is the problem.

On WordPress 7.0 and later, you will normally not see Administrator or Editor in the dropdown at all. The only time they show is when one of them is already the saved value. So if you see Administrator or Editor there, treat it as a finding.

To check the same thing with WP-CLI, run this command to read the registration checkbox. The option is stored as users_can_register.

wp option get users_can_register

The official options reference lists 1 for yes and 0 for no, with 0 as the default. So 1 means anyone can register.

Next, run this command to read the default role. The option is stored as default_role.

wp option get default_role

You should see a role slug such as subscriber, which is the WordPress default. If you see administrator or editor and the first command printed 1, you have the risky combination.

Step 3: Check Site Health for the critical warning

Open Tools > Site Health and stay on the Status tab. Site Health groups its results into critical issues, recommended improvements and passed tests.

If your site has the risky combination, look under critical issues for "Open Registration with privileged default role". Its description reads: "Registration is open to anyone, and the default role is set to a privileged role." It carries a Security badge and a Change these settings link that takes you back to the General settings screen.

If the setting is safe, the same test sits under Passed tests. Expand it and you will see the general advice that this combination may lead to security issues.

Why this matters: Site Health is easy to ignore because it often shows minor recommendations. This one is marked critical, which is why you should act on it.

Step 4: Review the accounts that already exist

Fixing the setting stops new risky sign-ups. It does nothing about accounts that registered while the setting was open. That is why you check users before you celebrate.

In wp-admin, click Users in the admin menu. Just above the user table there are filter links for each role. Click Administrator, then Editor, and look at every account in each list.

Look for:

• Usernames or email addresses nobody on your team recognises.
• Free email providers or odd domains on admin accounts that should belong to staff.
• Several accounts created close together.
• An admin account with zero posts that nobody can explain.

The wp-admin table does not show the registration date by default, so WP-CLI is handy here. Run this command to list all Editors with their registration dates:

wp user list --role=editor --fields=ID,user_login,user_email,user_registered --format=csv

Run the same command with --role=administrator if you did not already save that list in Step 1. Compare the user_registered dates against when registration was opened, if you know it.

Made-up example: Sana runs a small bakery site. A developer ticked Anyone can register two years ago to test a plugin and set the default role to Editor "just for the test". Nothing happened for months. Then Sana runs the list and sees four Editors registered in the same week with random usernames, and dozens of new posts full of links. The setting was the door. Those four accounts are the people who walked in.

Step 5: Change the default role or close registration

First decide whether the site needs public registration at all. Many business sites do not. If yours is a brochure site or a blog without member accounts, turn registration off.

In wp-admin, open Settings > General, untick Anyone can register, and click Save Changes at the bottom of the page.

With WP-CLI, run this command to turn registration off. It sets the option to 0, which the options reference lists as "No".

wp option update users_can_register 0

If the site does need registrations, for example a shop, a course or a forum, keep the checkbox ticked and set New User Default Role to Subscriber. Pick Author or Contributor only if new sign-ups truly must write posts, and remember that Author can publish without review.

With WP-CLI, run this command to set the default role to Subscriber:

wp option update default_role subscriber

You should see Success: Updated 'default_role' option. The official docs show the same command with author as the value, if Author is what you need.

Now fix the existing accounts that should not have high roles. Before you demote anyone, check two things:

• Never demote the only Administrator. Make sure at least one known, trusted Administrator account stays, and that you can log in to it.
• Confirm with the owner that the person is not a real editor or the site owner using an unfamiliar address.

In wp-admin, on the Users screen, tick the accounts, choose a role in the Change role to dropdown and click Change. You should see the message "Changed roles."

With WP-CLI, run this command to set user ID 12 to Subscriber. Replace 12 with the real user ID from your list.

wp user set-role 12 subscriber

Always type the role. The official docs say that if you leave the role out, WP-CLI uses the site default role. If the default role is still Administrator at that moment, a command meant to "fix" an account would make it an Administrator.

Step 6: If you found unknown admins, treat it as a possible break-in

An unknown Administrator account means someone may already have had full control. Deleting the account is tempting, but it is not enough on its own. An attacker with admin rights could have installed a plugin, changed a theme file or created other ways back in.

Do these things in order:

1. Preserve evidence before changing accounts: take a current backup or snapshot and export the user list and relevant access/security logs. If the site is actively being abused, use your host's incident-response process and prioritise containment.
2. Confirm which accounts are legitimate with the site owner. Keep at least one tested, trusted Administrator and a separate recovery path.
3. Revoke or demote access only for accounts you have confirmed are unauthorised. Record each change; deleting an account too early can remove useful evidence.
4. Reset passwords for verified Administrator accounts one at a time, then review plugins, themes, application passwords and files for changes you did not make.
5. Turn on two-factor login for every administrator and rotate any exposed hosting, database or deployment credentials through the system that owns them.

First list the administrator accounts and verify each ID, login and recovery email:

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

After confirming a single account and a working recovery path, reset that account explicitly. Replace USER_ID with one verified ID, and repeat deliberately for other verified administrators if required:

wp user reset-password USER_ID

Do not paste an unreviewed list of every administrator into a bulk reset command. A bulk reset can lock out all legitimate administrators at once and can trigger email notifications across the whole admin group.

For the file check, compare WordPress core and plugin files against the official copies with our guide to verifying WordPress files with WP-CLI checksums. Then tighten permissions using our guide to hardening WordPress file permissions after an RCE.

Also look at Plugins for anything nobody installed, and check for application passwords you did not create, using our guide to WordPress application passwords. Revoke any that nobody can explain.

Finally, add a second login factor. Our guide to two-factor authentication in cPanel, Plesk and DirectAdmin covers your hosting panel login, which is just as important as the WordPress one.

If you find malicious code or strange plugins, stop and bring in your host or a developer. Cleaning a compromised site properly is a separate job.

How to check it worked

Run these checks after you save.

• In wp-admin, open Settings > General again. Either Anyone can register is unticked, or New User Default Role shows Subscriber (or the lower role you chose).
• On WordPress 7.0 and later, open the New User Default Role dropdown. Administrator and Editor should no longer be listed, because they only show when one of them is the saved value.
• Run wp option get users_can_register and expect 0 if you closed registration.
• Run wp option get default_role and expect subscriber, or your chosen role.
• Open Tools > Site Health, Status tab. "Open Registration with privileged default role" should now be under Passed tests, not critical issues.
• Run wp user list --role=administrator --format=csv and compare it with the list you saved in Step 1. Only the people you expect should remain.
• In a private browser window, visit your login page and try the register link if registration is still open. Create a test account, check in Users that it got Subscriber, then delete the test account.

Troubleshooting

The Site Health warning is still there after I changed the setting

Most often the setting was never saved. It is easy to change the dropdown and leave the page without clicking Save Changes. Reload Settings > General and check the values, or run wp option get default_role to see what is really stored. If the value is right, reload the Site Health page so the tests run again.

Administrator or Editor still shows in the dropdown on 7.0

That means one of them is the saved value right now. WordPress keeps the current value visible so you can see it. Choose Subscriber, save, and reload the page. After that the two roles should disappear from the list.

A role I need is missing from the dropdown

On 7.0 and later, Administrator and Editor are hidden on purpose. If another role is missing, a theme or plugin may be using the default_role_dropdown_excluded_roles filter, or a plugin that created a custom role may have been deactivated. Run wp role list --fields=role --format=csv to see which roles exist right now.

A shop or membership plugin uses its own role

Some shop, membership and course plugins may add their own roles. I did not research how any of them handle the default role for this guide, so check the plugin's own documentation before you change New User Default Role on a shop. Test on a staging copy first, then place a test order or make a test sign-up and check which role the new account gets.

A custom default role disappeared after a plugin was removed

If wp option get default_role prints a slug that is not in wp role list, the plugin that created that role is probably gone. Set a real role with wp option update default_role subscriber, then re-activate the plugin if you still need its role.

wp user set-role fails with "Invalid user ID, email or login"

The WP-CLI source code prints Invalid user ID, email or login: '12' (with your value) when it cannot find the user. Check the ID with wp user list --fields=ID,user_login, or pass the login or email instead, which the official docs also accept.

wp user set-role fails with "Role doesn't exist"

The WP-CLI source prints this when the role you typed is not registered, for example a role from a deactivated plugin. The official roles page lists the core slugs in lowercase, such as subscriber and author. Run wp role list --fields=role --format=csv and copy the slug exactly.

I locked myself or a real editor out

If you demoted the wrong account and still have another Administrator, log in with that account and change the role back on the Users screen. If you demoted the only Administrator and have SSH access, run wp user set-role with that user and administrator, typed explicitly. Without SSH, restore the backup from Step 1 or ask your host for help.

A few extra tips

Test registration on staging. Editor is not a safe default because it can rewrite or delete every post. Add Settings > General and the privileged-user list to monthly maintenance.

The one message worth forwarding

Copy this and send it to whoever looks after your WordPress site:

"Hi, can you check our WordPress registration settings this week? Under Settings > General, please confirm that 'Anyone can register' is off, or that 'New User Default Role' is Subscriber, not Administrator or Editor. WordPress 7.0 flags this as a critical issue in Tools > Site Health. Please also send me the current list of Administrator and Editor accounts with their registration dates, so we can confirm we know everyone on it. Take a backup before changing any user roles, and do not demote the last Administrator. Thanks."

The takeaway: open registration is fine, but only when new accounts start with the lowest role they need, and only after you have checked who already got in.