WordPress User Enumeration: Why Attackers Do It

WordPress user enumeration is a reconnaissance technique where attackers discover valid usernames by exploiting default behaviors in WordPress URL handling, the REST API, the login form, and the XML-RPC interface. It's not an attack itself. It's the information-gathering step that makes credential attacks dramatically more effective.

Understanding how it works matters because it changes the math for every brute-force attack that follows. Without a valid username, an attacker has to guess both the username and the password. With one, every attempt is a real password guess against a confirmed account. That's an orders-of-magnitude difference in effectiveness.

How WordPress User Enumeration Works

WordPress exposes usernames through several default behaviors. Each one is a separate vector, and most sites have all of them wide open.

Author Archive URLs

This is the oldest and simplest method. WordPress assigns each user an integer ID starting at 1, which is almost always the administrator account. When someone requests /?author=1, WordPress issues a redirect that includes the username in the URL:

Request:  GET https://example.com/?author=1
Response: 301 → https://example.com/author/shane-larrabee/

The attacker now knows the login username for user ID 1. Incrementing the number (?author=2, ?author=3) reveals additional accounts. A 404 means no user exists at that ID.

Tools like WPScan automate this completely, iterating through author IDs and compiling a list of usernames in seconds. No authentication required.

The REST API

The WordPress REST API, enabled by default since version 4.7, provides an even easier path. A single unauthenticated request to /wp-json/wp/v2/users returns a JSON response containing the user ID, username, display name, author archive URL, and Gravatar hash for every user who has published content.

Unlike author archive scanning, which requires testing IDs one at a time, the REST API returns all qualifying users in a single request. WordPress 6.9.1 introduced REST API hardening that reduces enumeration success by roughly 80% when combined with security plugins. The endpoint still returns user data by design, though. The hardening limits abuse, not access.

Login Error Messages

The WordPress login form tells attackers whether a username exists. Enter a username that doesn't exist, and WordPress returns "The username is not registered on this site." Enter a valid username with an incorrect password, and the message changes to "The password you entered for the username is incorrect."

That binary response lets an attacker systematically test usernames without ever needing to guess a password. The password reset form has the same issue: it confirms whether a username or email address exists in the system.

XML-RPC

The XML-RPC interface at /xmlrpc.php provides both enumeration and brute force capabilities. Its most dangerous feature is system.multicall, which allows batching hundreds of credential tests into a single HTTP request. An attacker can test 500+ username-password combinations in one POST request, bypassing rate limiting that counts individual HTTP connections.

Most modern WordPress sites have no legitimate need for XML-RPC. Jetpack and the WordPress mobile apps have moved to the REST API. But XML-RPC remains enabled by default.

Enumeration Vectors at a Glance

Beyond these four primary vectors, WordPress also exposes user information through oEmbed discovery endpoints and XML sitemaps, which may include author URLs. These are lower-risk vectors, but they represent additional default behaviors that leak user data without authentication.

Why This Matters: The Attack Chain

User enumeration by itself doesn't compromise a site. No one has ever been hacked solely because an attacker discovered their username. The danger is what comes next.

"You don't have to be on anyone's threat list. You don't have to be a target. You don't have to be controversial. Your website can fall victim to a security attack even if you've never done anything controversial at all."

Enumeration is step one in a well-documented attack chain:

1. Reconnaissance: Attacker discovers valid usernames through one or more of the methods above
2. Credential attack: Usernames feed into automated brute force or credential stuffing tools
3. Access and persistence: A successful login leads to backdoor installation, malware deployment, or data theft

The scale of what follows is significant. Wordfence blocks roughly 65 million brute force attempts every day across sites using its plugin. In Q4 2025, brute force attacks increased 45% year-over-year, with AI-enhanced botnets nearly doubling automated login attempts since January 2025.

The average WordPress site faces a login attack every 28 minutes. Every one of those attempts is more effective when the attacker already has a confirmed username.

The "admin" Problem

The default WordPress administrator username has been "admin" since the platform launched. Installations created before version 3.0 (2010) always had this username, and many hosting one-click installers still default to it.

In a 2013 mass brute-force campaign, a botnet of over 90,000 servers targeted WordPress sites specifically using "admin" as the username. The campaign generated enough traffic that Cloudflare blocked 60 million requests against its WordPress customers in a single hour.

If your site still has an "admin" account, attackers don't even need to enumerate. They already have the username.

An Honest Risk Assessment

Here's where we differ from most security content on this topic. User enumeration is a real vulnerability, but context matters.

If your site uses strong passwords, two-factor authentication, and brute-force protection, enumeration yields attackers very little. They know a username, but they can't do anything useful with it. The door is locked, and every lock on the building is a deadbolt.

If your site has weak passwords, no 2FA, and no login rate limiting, enumeration is the beginning of a bad day. It's the difference between an attacker guessing randomly and an attacker knowing exactly which account to target.

The fix is straightforward. A few small configuration changes close all the vectors. But most site owners don't know these defaults exist, which is why enumeration keeps appearing as a finding in security audits and penetration test reports.

"Scale matters enormously with this threat. If you have two admin accounts, user enumeration is a minor concern. But membership sites with thousands of members create a massive attack surface."

How to Disable WordPress User Enumeration

Prevention is a layered approach. We're listing these in order of impact, starting with the measures that matter most.

Start With What Makes Enumeration Irrelevant

Before blocking enumeration vectors, make sure that even successful enumeration can't lead to a compromise:

• Strong passwords: Minimum 16 characters for all administrator accounts. A known username paired with a strong password is still a dead end for brute force.
• Two-factor authentication: 2FA on all administrator and editor accounts means a password alone isn't enough. This is the single most effective credential protection available.
• Login rate limiting: Whether through a WAF, a security plugin, or your hosting platform, limit failed login attempts. This turns brute force from a viable attack into a slow, noisy, easily detected one.

These three measures don't prevent enumeration, but they make it largely pointless.

Block the Enumeration Vectors

With the foundation in place, close the information leaks:

Block author archive scanning. For sites that don't use author profile templates, a WordPress function snippet can turn off author profile display entirely. For sites that do display author pages, creating an author slug different from the actual username means that even if someone scrapes all the author pages, they won't have valid login credentials.

Restrict the REST API users endpoint. The goal is to block unauthenticated access to /wp-json/wp/v2/users while leaving the rest of the API functional. Completely disabling the REST API breaks the block editor and many plugins, so a targeted approach is necessary.

Normalize login error messages. A single WordPress filter can make the login form return the same generic "invalid credentials" message regardless of whether the username or password is wrong. This eliminates login form enumeration entirely.

Disable XML-RPC. Unless a specific, documented integration requires it, XML-RPC should be blocked at the server level. A server-level block is more thorough than the PHP filter, which still allows the file to respond to requests.

Change the default "admin" username. If your site still has an "admin" account, create a new administrator with a non-obvious username, transfer content ownership, and delete the original. WordPress doesn't allow direct username changes through the admin interface.

Security Plugins That Handle This

Most established WordPress security plugins include enumeration protection among their hardening features. Wordfence blocks author scanning through its firewall rules and normalizes login errors. Solid Security has a dedicated user enumeration toggle along with REST API restriction and login error masking. All In One WP Security and Shield Security offer similar capabilities.

The advantage of handling enumeration through a security plugin rather than custom code is consistency. The plugin applies the same protections across every vector, and the settings persist through WordPress updates.

How We Handle This Across 200 Sites

When we onboard a new site, enumeration hardening is part of our standard security setup. It's not an add-on, an upsell, or something we do only when a client asks. Every site gets the same checklist:

1. Verify no "admin" username exists, and rename or replace it during onboarding
2. Block author enumeration via security plugin or server-level rule
3. Restrict the REST API users endpoint so unauthenticated requests return a 401
4. Normalize login error messages to a generic response
5. Disable XML-RPC unless a specific integration requires it
6. Enforce strong passwords and two-factor authentication for all admin accounts

With roughly 200 sites under management, the probability that at least one site will be scanned by an enumeration tool on any given day is effectively 100 percent. Roughly 97% of the attacks we see are automated, while only about 3% are targeted. Automated scanners don't single out individual sites. They sweep IP ranges and domain lists.

That means hardening has to be systematic and consistent across the fleet, not something applied ad hoc after a problem surfaces. The same principle applies to spam registration protection, where bots use enumerated account data to bypass anti-spam filters and target specific users.

We also don't rely on security through obscurity, like moving the WordPress login URL to a different location. Bots find the moved location anyway, and clients lose track of their login URL or lock themselves out using the plugins that handle the redirect. With proper protections in place, there's no need to hide the front door.

What to Do If You've Been Enumerated

If a security scan or audit has flagged user enumeration on your site, don't panic. Enumeration alone doesn't mean your site has been compromised. But it does mean you should act:

1. Check for brute force attempts. Review your login logs or security plugin activity. If usernames have been enumerated, brute-force attempts may have already followed.
2. Audit user accounts. Look for any accounts you don't recognize. Backdoor accounts created after a successful brute force attack are common.
3. Enable 2FA immediately. If you don't already have two-factor authentication on admin accounts, enable it now. This is the fastest way to shut down the attack chain.
4. Apply the hardening steps above. Block the enumeration vectors to stop the information leak.
5. Consider a security audit. If you're not sure what else might be exposed, a professional assessment can identify other hardening gaps beyond enumeration.

Enumeration in Context

WordPress user enumeration is a real security gap, but a fixable one. It's not the kind of vulnerability that keeps security professionals up at night. It gets addressed during a proper hardening pass and then stays addressed.

The reason it matters is the attack chain it enables. Blocking enumeration is one link in a layered security approach that includes edge protection, server-level scanning, application hardening, and operational monitoring. No single measure stops everything, but each layer reduces what gets through to the next.

"Anyone who's guaranteeing you 100% security is a fool. What we guarantee is that we have the best tools, practices, and services in place, plus rapid response and recovery when something does happen."

If your organization doesn't have someone handling this kind of hardening systematically, our WordPress security services include enumeration protection as part of the standard security setup across every site we manage. You can also read about how our security approach compares to what typical hosting providers offer.