October 20, 2026
Open Registration With Privileged Default Role: What It Means in Site Health
Your WordPress dashboard shows a critical Site Health item: “Registration is open to anyone, and the default role is set to a privileged…

By Matt Churst
3 min read
Your WordPress dashboard shows a critical Site Health item: "Registration is open to anyone, and the default role is set to a privileged role." The natural reaction is to wonder who made that mistake. It was almost certainly not a misclick, and the reason is in how WordPress 7.0 changed the Settings screen.
We read the check in WordPress 7.1.3 to see exactly what it compares. The short version is a two-minute fix followed by an account check you should not skip, plus a gap in the test itself.
What the check actually tests
The option users_can_register controls the Anyone can register box, and default_role controls New User Default Role. The registration form never asks a visitor which role they want. It creates the account with a name, a password and an email, and the role comes from default_role. Site Health reads both options when the screen loads, and the item turns critical only when users_can_register is truthy and default_role is exactly editor or administrator.
How it gets set without the Settings screen
WordPress 7.0 excludes Administrator and Editor from the New User Default Role dropdown, except for a role that is already saved, which stays visible so you can change it. A site that shows this item therefore had its options written another way. The usual routes are an Editor choice made before 7.0 that nobody revisited, a plugin, theme or snippet that wrote the option, a migration or staging copy that carried an old value over, or a direct database edit. The check reads two values and has no history, so it cannot say which one happened.
The two-minute fix
Log in as an Administrator and open Settings, then General. In the Membership row, untick Anyone can register if you do not need sign-ups. If you do, set New User Default Role to Subscriber. Save, then reload Tools, Site Health and run the check again. If the Settings screen will not save, read the two option names in the options table and deactivate plugins one at a time if the value flips back, because something is writing it on every request.
Check whether anyone used it
Fixing the settings closes the door. It does not show who already walked through. Open Users, then All Users, and use the Administrator and Editor links above the list. Open every account you do not recognize and read its role. If an unknown Administrator or Editor exists, treat the site as exposed. Write down the username and registration time first, then change the password of every real Administrator and use Log Out Everywhere Else on each profile. Reassign any content the account owns, delete it, and look through Plugins and Themes for anything you did not install. Restore from a clean backup if you have one that predates the account.
The Default Role Risk Table
| Default role | Site Health result | What a stranger can do on day one | | — -| — -| — -| | Administrator | Critical | Take over the site: activate and edit plugins, edit themes, change settings, edit other users | | Editor | Critical | Publish and edit any post, upload files, save raw HTML | | Author | Good (not flagged) | Publish and edit their own posts and upload files | | Contributor | Good (not flagged) | Write posts and submit them, but not publish | | Subscriber | Good (not flagged) | Read only, and manage their own profile |
Why green is not the same as safe
The test is a strict comparison against two role names, so Author passes even though every stranger who signs up could publish posts and upload files. Custom roles pass too, because the test compares the slug and not the capabilities behind it. A role named member that carries every Editor capability looks identical to a harmless one. The test also does not look at existing accounts, so a site that was already abused shows green once the options are fixed, and it knows nothing about plugins that run their own registration forms.
When open registration is intentional
Communities, course sites, member areas and shops need sign-ups, and the check does not tell you to close registration. It tells you not to hand out Editor or Administrator while registration is open. Leave the default on Subscriber, grant higher roles by hand or through a plugin rule you have read, review the newest accounts on a schedule, and read the capabilities of any custom role before you accept it as a default.
The takeaway
The warning is a precise report that two options combine into an open door. Fix the options, then check the accounts, and choose Subscriber unless you have a written reason for anything else.