How Do Hackers Mine WordPress for Admin Email Addresses?

The admin email on a WordPress site is worth more to an attacker than most owners realise. It is the address password resets go to, the address that receives “a new plugin update is available” notices that can be spoofed, and very often the same address the owner uses to log in. Attackers do not need a vulnerability to find it; WordPress, the web around it, and ordinary human habits leak it in half a dozen ways.

This guide lists the techniques attackers use to harvest admin emails and usernames from WordPress sites, shows you how to check whether your own site leaks them, and gives the fixes we apply on client sites. None of it requires a paid tool, and most of it takes under an hour.

Why the admin email matters to an attacker

An email address on its own is not a breach. Combined with a username and a list of passwords from old data breaches, it becomes credential stuffing. Combined with a convincing “your site has a security problem, log in here” message, it becomes phishing. Combined with the password reset form, it becomes an account takeover if the mailbox itself is weak.

Patchstack’s 2026 reporting puts user enumeration at the start of roughly 40% of brute force incidents against WordPress sites. The pattern is always the same: find the username or email, then throw passwords at wp-login.php or xmlrpc.php until one works. Cutting off the first step makes the second much harder, because the attacker has to guess both halves.

One clarification before the list. WordPress does not expose the admin email through any default front-end page or public API. The email leaks come from other places: feeds, comments, domain records, plugins, and the owner’s own habits. The username leaks, on the other hand, are partly WordPress defaults.

Technique 1: username enumeration through author archives

Every WordPress user who has published a post gets an author archive. Requesting https://example.com/?author=1 redirects to https://example.com/author/username/, and the slug in that URL is, by default, the login name. An attacker’s script walks IDs 1 through 50 in a few seconds and collects every author slug, which on most sites means every administrator and editor.

Check your own site: open a private browser window and visit /?author=1. If you land on an author page whose URL contains your login name, you are leaking it.

Fixes

• Change the user_nicename so the archive slug differs from the login. WordPress has no UI for this; use WP-CLI: wp user update 1 --user_nicename=editorial-team. The display name (Users → Profile → Display name publicly as) should also be something other than the username.
• Block the numeric redirect. Add this to a small must-use plugin or your theme’s functions file:

add_action( 'template_redirect', function () {
    if ( is_author() && ! empty( $_GET['author'] ) && ! is_user_logged_in() ) {
        wp_safe_redirect( home_url(), 301 );
        exit;
    }
} );

• If you do not use author archives at all (many business sites do not), disable them entirely. Yoast SEO has a switch for this under Yoast SEO → Settings → Advanced → Author archives; Rank Math has the same under Titles & Meta → Authors.

Technique 2: the REST API users endpoint

Since WordPress 4.7 the REST API has shipped a public users endpoint. An unauthenticated request to /wp-json/wp/v2/users returns every user who has authored a public post, with their ID, display name, slug and avatar URL. The REST API handbook is explicit that the email field is only returned in the edit context, which requires authentication, so this endpoint does not leak emails. It does leak usernames via the slug, which is what the attacker is after.

The avatar URL is a more subtle leak. Gravatar avatars are served from a URL containing an MD5 or SHA-256 hash of the user’s email. Given a hash and a list of candidate emails (first.last@domain, admin@domain, info@domain and so on), an attacker can confirm which one matches offline, with no further requests to your site. The hash is also in the page source next to every comment the user has left.

Fixes

Restrict the users endpoint to logged-in users. Do not disable the whole REST API; the block editor, WooCommerce, Jetpack and many plugins depend on it. This filter is enough:

add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( is_user_logged_in() ) {
        return $endpoints;
    }
    unset( $endpoints['/wp/v2/users'] );
    unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    return $endpoints;
} );

For the Gravatar hash problem, either switch off Gravatar (Settings → Discussion → Avatar Display) in favour of locally uploaded avatars, or make sure the admin account’s email is not one anyone would guess. A dedicated address such as a random-word alias at your domain defeats the offline matching attack.

Technique 3: feeds, oEmbed and page source

The RSS feed at /feed/ includes a dc:creator element for every post carrying the author’s display name. Comment feeds do the same for commenters. The oEmbed endpoint at /wp-json/oembed/1.0/embed?url=... returns author_name and author_url, and the latter is the author archive URL with the slug in it. Neither exposes the email directly, but both reinforce the username leak and tell an attacker which account does the publishing.

Page source is where actual email addresses show up. We regularly find them in theme footers (“Contact: admin@…”), in author bios, in schema markup generated by SEO plugins (the Organization or Person schema often includes an email field the owner filled in years ago), and in mailto: links. Modern scrapers read JavaScript-obfuscated addresses without difficulty, so “at” and “dot” tricks do not help.

Fixes

• Search your own site the way an attacker would: site:example.com "@example.com" in Google, then view source on any page that matches.
• Review the schema your SEO plugin outputs. In Yoast it lives under Yoast SEO → Settings → Site representation; remove the email if it is the admin address.
• Replace mailto: links with a contact form. If you must publish an address, publish a role address (hello@, support@) that is not tied to a WordPress account.
• Strip author data from oEmbed responses with the oembed_response_data filter, and remove the discovery links with remove_action( 'wp_head', 'wp_oembed_add_discovery_links' ) if you do not need other sites embedding your posts.

Technique 4: login and password-reset error messages

Older WordPress versions told you whether a username existed (“Invalid username” versus “The password you entered is incorrect”). Modern versions have improved the login form, but the password reset form at /wp-login.php?action=lostpassword still behaves differently for a valid and an invalid username or email, which is enough for a script to confirm an account. XML-RPC’s wp.getUsersBlogs method does the same thing and is faster, because system.multicall lets an attacker test hundreds of credentials in one HTTP request.

Fixes

• Make login errors generic with the login_errors filter: add_filter( 'login_errors', fn() => 'Login failed.' );
• Disable XML-RPC unless you use the mobile app or Jetpack: add_filter( 'xmlrpc_enabled', '__return_false' );. If you need it, at least block system.multicall through the xmlrpc_methods filter.
• Rate-limit wp-login.php and xmlrpc.php at the server or CDN level. Cloudflare’s free tier rate limiting rules handle this well; Limit Login Attempts Reloaded or Wordfence do it at the application layer.
• Turn on two-factor authentication for every administrator. The free Two Factor plugin (maintained by WordPress core contributors) or the 2FA module in your security plugin both work. 2FA makes a harvested email and password insufficient on their own.

Technique 5: sources outside WordPress

Some of the most productive sources are not on your site at all.

• WHOIS and historical WHOIS. If the domain was registered before privacy protection became standard, the original registrant email is archived in historical WHOIS services. Owners frequently used the same address as the WordPress admin email.
• Data breach dumps. The admin email has probably been used to sign up for other services, some of which have been breached. Attackers search breach corpora for your domain and get addresses plus the passwords people reused. Check your domain at Have I Been Pwned; the domain search is free for verified domain owners.
• Certificate transparency logs. These reveal staging and dev subdomains (staging.example.com, dev.example.com), which are often forgotten installs with weaker protection and the same admin account.
• Plugin and theme bugs. A broken-access-control bug in a plugin can expose user data through an unauthenticated endpoint. Patchstack and Wordfence publish dozens of these each month. The only defence is updating promptly and removing plugins you do not use.
• The Wayback Machine. A footer or contact page you cleaned up in 2021 is still there in the archive.

A quick audit you can run in fifteen minutes

Check	How	Leaking if
Author ID redirect	Visit /?author=1 logged out	URL contains your login name
REST users endpoint	Visit /wp-json/wp/v2/users logged out	Returns a JSON list instead of a 404 or 401
Gravatar hash	View source on a post with your comment or author box	A gravatar.com URL with a hash is present and your email is guessable
Email in page source	curl -s https://example.com | grep -i "@"	Any real address appears
Login error detail	Try a wrong password for a real and a fake username	Messages differ
XML-RPC	curl -d "<methodCall><methodName>system.listMethods</methodName></methodCall>" https://example.com/xmlrpc.php	Returns a method list
Breach exposure	Domain search on Have I Been Pwned	Admin address appears in any breach

Security plugins such as All-In-One Security (AIOS), Wordfence and Solid Security bundle most of these mitigations behind checkboxes. AIOS, for example, has User Security → Prevent User Enumeration and Firewall → WP REST API switches that cover techniques 1 and 2. If you already run one, turn those on before writing any code. If you run none and the site handles customer data, pick one.

Separate the admin email from the admin login

The single most effective change is structural rather than technical. On most sites the admin email, the account email of user ID 1, and the owner’s everyday mailbox are all the same address. Split them:

1. Create a new administrator account with a non-obvious username and a dedicated email alias that is never published anywhere.
2. Log in as the new account, demote the old “admin” account to Subscriber (or delete it, reassigning its content).
3. Set Settings → General → Administration Email Address to a monitored role mailbox (site-alerts@yourdomain) rather than a personal address. WordPress sends a confirmation link to the new address before the change takes effect.
4. Give day-to-day authors Editor or Author roles with their own accounts. Administrators should not be publishing posts, which keeps them out of author archives and the REST users list entirely.
5. Put two-factor authentication on every remaining administrator.

After this, a harvested author slug points at an Editor account with limited capabilities, and the address that receives password resets is one no scraper has ever seen.

FAQ

Does hiding the login URL stop email harvesting?

No. Renaming wp-login.php stops some automated brute force traffic, but it does nothing about author archives, the REST endpoint, feeds or external sources. It is a reasonable extra layer, not a fix.

Will blocking the REST users endpoint break anything?

Rarely. The block editor’s author dropdown uses the endpoint, but it does so as a logged-in user, which the filter above allows. A few front-end plugins (author directories, some membership plugins) query it anonymously; test on staging if you run those.

Is the admin email ever exposed by WordPress core itself?

Not through any public endpoint. The leaks come from the Gravatar hash, from content, from plugins, and from the wider internet. Core’s default exposure is the username via author slugs and the REST users list, which is why those two fixes come first.

How do I know if someone is already trying?

Look at your server access log for bursts of requests to /?author= with sequential numbers, to /wp-json/wp/v2/users, and POSTs to xmlrpc.php. Any site that has been online for a month will have some; a spike means you are on a list.

What we’d do

Run the fifteen-minute audit, apply the author archive and REST endpoint fixes, disable XML-RPC if nothing needs it, and separate the admin email from the admin account. Then turn on two-factor for administrators and set a reminder to re-run the audit after major plugin changes. If you would rather have someone do this properly, with server-level rate limiting and monitoring, our WordPress security hardening service covers all of the above, and a care plan keeps the plugin updates that close the next vulnerability flowing.