WordPress user accounts: the security gaps hiding in your user list

Most WordPress security advice points at the obvious places: the login form, the plugins, the firewall you maybe should install. The user list rarely gets a second look. It sits there in wp-admin, a quiet table of names and roles, and because nothing about it ever throws an error, nobody audits it. That is exactly why it is worth auditing. The gaps that live in your user list are not bugs. They are decisions that were made once, by default or in a hurry, and then forgotten.

None of these gaps will set off an alarm. They will not slow your site down or break a page. They just make an attacker's job a little easier, and an attacker's job is mostly about stacking up small advantages until the math works in their favor. The good news is that closing them takes minutes, and most site owners have never been told to look.

The login form is a guessing game, so stop giving away the answers

Before the specific gaps, it helps to understand why they matter, and it comes down to one mechanic. A brute-force tool has to guess two things to get in: the username and the password. Both. If it knows the username, it has solved half the puzzle and can throw every password it has at a single, confirmed target. If it has to guess the username too, the search space explodes and the whole attack becomes far less worth running.

So almost everything in this article is about the same thing: not handing over the username. Each gap below leaks that first half of the credential in a slightly different way, and each one you close forces a would-be attacker back to guessing both halves at once.

The default admin username

For years, the very first administrator account on a fresh WordPress install was simply named admin. Plenty of sites still carry that account, either because they were set up long ago or because a one-click installer chose the name for them. It is the single most predictable username on the internet, which is why automated tools try it first, every time, on every site.

An account named admin means an attacker does not have to guess the username at all. You have already told them. They can point everything they have at the password and only the password. This is the most consequential of the three gaps, and the remedy is straightforward: create a fresh administrator account under a name that is not admin, confirm it works, then retire the old one. The login becomes a real secret again instead of a default everyone knows.

More administrators than the site actually needs

Roles drift over time. A developer needed full access for a one-week project and kept it for two years. A client wanted to "see everything" and got handed the administrator role because it was quicker than explaining the difference. A former team member never got downgraded. Each of these was reasonable in the moment, and together they leave a site with more administrator accounts than it has any real use for.

This matters because every administrator account is a full key to the building. The more of them exist, the more credentials an attacker can target and the more accounts can quietly go stale, with weak or reused passwords nobody is watching. The principle is simple: an account should hold the lowest role that still lets its owner do their job. An editor who never touches plugins or settings does not need administrator. Drop the over-privileged accounts to the role they actually need, and the number of full-access keys shrinks to the few that genuinely require it.

An attacker who already knows your username has solved half the puzzle. Most of user hygiene is just refusing to give that half away.

A display name that matches the login

This one is the most subtle, and the easiest to overlook. In WordPress, your login username and your public display name are two separate fields, but by default they start out identical. So unless someone changed it, the name shown on every post byline, every comment, and every author archive is the exact string used to log in.

That is the username, published in plain sight. An attacker does not need to probe an API or dig through archive URLs; they can read it straight off the front of the site. Setting a public display name that is different from the login closes that leak completely and costs nothing in visibility. Your byline can still read however you like. The login simply stops being printed alongside it.

Why these stay your decision

RecapWP's Users area checks for all three of these: a default admin username, more administrator accounts than the site needs, and a display name that exactly matches the login. What it does with them is the part worth understanding. It flags them. It does not change them.

That is deliberate. Elsewhere in the plugin, when a finding is a known configuration change, RecapWP can apply the fix for you and record it so you can reverse it. User accounts are different. Deleting an administrator, demoting a colleague, or retiring the original admin are decisions with context only you have. The wrong automated move could lock someone out or break a workflow. So the Users checks are detect-only by design: RecapWP surfaces the problem clearly, with the reasoning and the recommended remedy, and the action stays in your hands. The value is in being told. Most of these gaps survive for years precisely because nobody ever pointed at them.

It is worth noting that not leaking the username pairs well with the other side of login security, like limiting failed login attempts, which RecapWP handles in a different area. Together they make brute-force guessing meaningfully harder. But the user list is where it starts, because there is no point slowing down a guessing game if you have already published the answer.

Make it a quick recurring audit

The user list drifts the same way every other part of a site does: quietly, between the moments anyone is paying attention. A new account here, a role bump there, a name field nobody thought about. None of it announces itself, which is why a once-and-done cleanup is not enough.

So fold it into a routine. Every so often, open your user list and ask three plain questions. Does anything still log in as admin? Does every administrator on that list genuinely need administrator? Is anyone's public name the same string they type to sign in? Three questions, a few minutes, and the answers either reassure you or hand you a short to-do list. Either outcome is better than not knowing.

If you would rather not run the checklist by hand, that is what the Users area is for. Run a scan and it reads your own user list back to you, worst-first, and tells you which of these three gaps are open on your site right now. The remedy stays yours to make. The fastest way to find out what is hiding in your user list is to look.