Your WordPress Admin Username Is Probably Public. Ours Was.

WordPress publishes your administrator’s login name in places most site owners never look. Bots read them, then spend their time guessing the password for a username they already know is real. We found this out on our own site, pressbot.io, and fixed it in a day. Here’s how it happened, where the name leaks, and a five-minute check you can run on any WordPress site.

The alert

PressBot’s Shield sends us a daily security digest on Telegram. One morning it said something it had never said before: bots weren’t trying “admin” or “test” this time. They were trying our real administrator login, a name that isn’t on any page of the site and that we had never shared.

Nobody got in. The attempts were slow and spread out, a few an hour from dozens of different IP addresses, the pattern you see when a botnet works through a list without tripping lockouts. Every successful login that week came from us. But a real username is half of what an attacker needs, so the question was how they had it at all.

Where WordPress leaks your login

WordPress gives every user an author address, /author/your-name/, and unless you change it, the name in that address is the login. Then it puts that address in several public places:

• The users sitemap. Since WordPress 5.5, core builds a sitemap at /wp-sitemap-users-1.xml that lists every author who has published something. That’s where ours leaked. It’s made for search engines, but any scanner can read it.
• Author pages and bylines. Themes link post bylines to the author address, and /?author=1 redirects to it.
• The REST API. /wp-json/wp/v2/users lists authors and their slugs unless something removes it.
• Login and password-reset messages. By default WordPress tells you whether a username exists (“the password you entered for the username … is incorrect”, or “there is no account with that username”). That turns the login form into a way to confirm guesses.
• Feeds and embeds, if your display name is the same as your login.

Why “Admin username: OK” checks miss it

Most security checklists, including the audit we shipped ourselves, only ask one question: is there a user called “admin”? If not, they report the admin username as fine. That’s what ours said too, while bots were working through our real login. Not being called “admin” doesn’t help much if the real name is in a sitemap.

What we built

We used the leak on our own site to build the fix into PressBot, and shipped it in version 1.20. Everything below is in the free plugin unless it says Pro.

• Site Check shows where each admin login is public. It lists every place an administrator’s or editor’s login can be read from outside: the users sitemap, author pages and bylines, the REST API, embeds, and login messages that confirm a name.
• Hide usernames. One switch closes those leaks for visitors: it removes the users sitemap, hides the users list from logged-out requests, sends login-named author pages to the home page, and makes login and password-reset messages generic.
• Turn off XML-RPC. An old interface that lets bots try many passwords in a single request. Most sites don’t need it.
• Change my username. WordPress can’t rename a login, which is why most people never do it. PressBot renames your own account in place: it asks for your current password, refuses names that are easy to guess, gives your author pages an address that isn’t your login, signs out your other devices, and emails you a confirmation. Your posts and settings stay exactly where they are.
• Pro: know when the public name is the one under attack. Shield compares the usernames bots try with your real accounts and tells you when a real, public login is being targeted, and where it leaks. That’s the alert that started this.

A five-minute check for any WordPress site

You don’t need PressBot for this part:

1. Open yoursite.com/wp-sitemap-users-1.xml. If it lists /author/something/, that something is probably a login.
2. Open yoursite.com/?author=1 while logged out. If it lands on /author/your-login/, your login is public.
3. Try logging in with a made-up username. If the error says that username doesn’t exist, your login form confirms real ones.
4. If your login turned up anywhere, make sure the password is long, random and used nowhere else, and turn on two-factor sign-in if you can.
5. Then close the leaks and, if the name is already known, change it. A login that bots already have stays on their lists.

What happened next

We turned on Hide usernames, switched off XML-RPC and changed the login with the new form. The bots are still trying the old name every few hours. It just doesn’t exist anymore, and Shield now shows no attempts against a real account.

If you run PressBot, update to the latest version and open Security → Site Check (or Shield in Pro). If you don’t, the free plugin is on WordPress.org as GreenScript PressBot.