If someone can find every single username on your WordPress site with nothing more than a browser, that is a problem. Attackers use this information every day to make their login attempts more effective, and most WordPress sites leak it without the owner ever knowing.
This is called user enumeration, and it is one of the most common information disclosure issues on the web. It does not directly break into your site, but it gives attackers the single piece of information they need most: a valid username. Once they have that, password spraying becomes dramatically more effective. Instead of guessing random username and password pairs, they guess the password for one known account. The odds shift from nearly impossible to very possible.
What Is WordPress User Enumeration?
User enumeration happens when a WordPress site reveals its registered usernames through public endpoints. The most common sources are the REST API and author archive pages. Both are enabled by default, and both return username data to anyone who asks, with or without authentication.
The REST API endpoint at /wp-json/wp/v2/users/ returns a list of all users who have published content. This usually includes authors, editors, and administrators. The response contains their display name, avatar, and most importantly, their username (slug field). Even if you hide the display name, the slug often reveals the real login name.
Author archives work differently but achieve the same result. When you visit /?author=1, WordPress redirects to the author archive page and shows the author’s username in the URL structure, such as /author/admin/. By incrementing the ID number (1, 2, 3, 4), an attacker can map out every user on your site in seconds.
Why Attackers Care About Usernames
Brute force attacks work by trying many password combinations against a known or unknown username. Without knowing the username, the attacker has a much harder time. With a list of valid usernames, the attack becomes a password cracking problem, not a guessing problem.
Botnets like CrawlerX, which gained attention in early 2026 for using hundreds of thousands of residential IPs, rely heavily on user enumeration. First, the bot scans the target site for valid usernames. Then, it runs password spraying against those usernames using common passwords and credentials leaked from other breaches. This two-step approach is far more effective than random guessing.
Targeted attacks also benefit from enumeration. If an attacker knows who writes for your site and finds that person’s username through enumeration, they can research that person for password reuse on other services. This is how many targeted WordPress compromises start, not with a vulnerability in the site itself, but with a leaked password from a completely unrelated service.
How to Test If Your Site Leaks Usernames
Run these two commands from your terminal. They do not require authentication and work on any WordPress site.
First, test the REST API endpoint:
curl -s "https://yoursite.com/wp-json/wp/v2/users/" | python3 -m json.toolIf the response contains a list of user objects with slug and name fields, your site leaks usernames through the REST API.
Second, test the author ID endpoint:
curl -sI "https://yoursite.com/?author=1" | grep -i "^location"If this returns a 301 redirect to /author/username/, your site also leaks usernames through author archives.
Most sites will fail both tests. The good news is that fixing both is straightforward.
Method 1: Block the REST API User Endpoint
The cleanest fix for REST API user enumeration is to disable the users endpoint for unauthenticated requests. Add this code to your theme’s functions.php file or, better yet, to a site-specific plugin.
add_filter('rest_endpoints', function($endpoints) {
if (!is_user_logged_in()) {
if (isset($endpoints['/wp/v2/users'])) {
unset($endpoints['/wp/v2/users']);
}
if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
}
}
return $endpoints;
});This removes both the list endpoint and the individual user endpoint for anyone not logged into WordPress. Authenticated users (editors and administrators working in the admin panel) can still access the REST API normally since their requests include authentication cookies.
After adding this code, test the REST API endpoint again. An unauthenticated request should now return an empty array or an error, depending on your WordPress version.
Method 2: Disable Author Archive Redirects
The author archive URL pattern is harder to disable because WordPress core handles the redirect before most plugins can intercept it. The most reliable approach is to return a 404 page instead of redirecting to the author archive.
Add this to your functions.php or site plugin:
add_action('template_redirect', function() {
if (is_author()) {
global $wp_query;
$wp_query->set_404();
status_header(404);
get_template_part('404');
exit;
}
});This intercepts the author template request and returns a 404 page instead. The attacker sees nothing useful. The site stays functional for everyone else because author pages were never important for visitors anyway.
Method 3: Block Enumeration Through .htaccess
For Apache servers, you can block the REST API users endpoint at the web server level. This adds a layer of protection even if a plugin or code modification fails.
# Block REST API user enumeration
RewriteEngine On
RewriteCond %{QUERY_STRING} rest_route=/wp/v2/users [OR]
RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users
RewriteRule ^ - [R=403,L]Place this in your site’s root .htaccess file before the WordPress section. Keep in mind that this blocks the endpoint for everyone, including legitimate REST API consumers. If your site uses a headless front-end or integrates with a third-party service that needs the users endpoint, skip this method and use the PHP approach instead.
Method 4: Return a Login Page Instead
Some site owners prefer not to block the user endpoint entirely but instead require authentication before showing user data. This approach keeps the REST API functional for logged-in users while hiding usernames from everyone else.
The earlier PHP snippet in Method 1 already achieves this by checking is_user_logged_in(). When a logged-out visitor hits the users endpoint, WordPress returns an empty response instead of a list of users. When an admin hits the same endpoint from the dashboard, the list appears normally.
This is the most balanced approach because it does not break any functionality. The REST API continues working for plugins and themes that rely on it, but attackers cannot extract usernames from it.
Can You Use a Plugin Instead of Code?
Several security plugins offer user enumeration protection as part of their feature set. They typically apply one of the four methods described above automatically, which saves you from editing files manually.
When choosing a security plugin, look for one that combines user enumeration prevention with broader login security features. Blocking user enumeration is only one piece of a larger puzzle. You still need brute force protection, two-factor authentication, and login monitoring to keep your site secure.
Do It All With One Plugin
Trusti Security prevents user enumeration as part of its login protection suite. It blocks REST API user listing for unauthenticated visitors, hides author archive redirects, and integrates this protection with its brute force, 2FA, and login monitoring modules. Instead of patching four separate things, you get one plugin that handles the full login security picture.
The Bottom Line
User enumeration is not a vulnerability in the traditional sense. It does not allow an attacker to take over your site directly. But it removes one of the biggest obstacles to a successful brute force attack: not knowing who the users are.
Test your site with the curl commands above. If your REST API or author archives reveal usernames, apply one of the four fixes. The code snippets in this post take less than five minutes to implement, and they remove an information leak that most WordPress sites have been exposing since day one.
Combining user enumeration protection with a strong password policy, two-factor authentication, and brute force limits is the difference between being an easy target and being a hard one. Attackers scan for low-hanging fruit, and a site that does not leak usernames is already a step ahead of most others on the internet.