How Do Hackers Mine WordPress for Admin Email Addresses? 7 Leaks Tested

How do hackers mine WordPress for admin email addresses? Mostly through features that ship turned on, like login error messages, avatar hashes and order emails. None of these needs a break-in, and a default site gives the address away in seconds.

I tested every method in this guide in October 2026 on a local WordPress 7.1.3 and WooCommerce 11.2 site, never on anyone else’s site. Each check was a logged-out request with curl or a browser, and the outputs below are the real responses. The admin account used the email owner@shop.test.

You get the seven leak points with proof of each, plus where WordPress stores the admin email and how to read it. You also get five fixes, each tested on the same site, and a short routine for checking your own install.

Why Hackers Want Your WordPress Admin Email

Hackers want your WordPress admin email because it is half of a login and the target of every password reset. With the address, a bot can try passwords on the right account. A scammer can also send a fake “your site was suspended” email.

The address is also easy to reuse. One confirmed email feeds every later attack, and it rarely changes once a site is set up.

Three attacks start from it:

• Password guessing: WordPress accepts the email in the login field. A confirmed address saves the attacker from guessing a username first.
• Phishing: A fake hosting or plugin notice sent to the real admin inbox looks far more convincing than a random blast.
• Account takeover elsewhere: People reuse addresses. One known email lets an attacker check breach lists for passwords used on other sites.

OWASP lists this class of weakness in its account enumeration testing guide. The guide treats any response that differs for valid and invalid accounts as a finding worth fixing.

Most of these leaks are not bugs. They are features that help real users, such as a friendly login message or a comment avatar. Attackers simply read them at scale.

That framing matters for the fixes. You are not patching broken code, you are deciding which friendly answers a stranger should no longer get.

Here is every leak point I confirmed on the test site, on one screen:

How Do Hackers Mine WordPress for Admin Email Addresses?

How do hackers mine WordPress for admin email addresses? They ask the site questions it answers too honestly, and two forms confirm whether an email exists. Avatar URLs carry a hash of it, WooCommerce mails it to buyers, and four endpoints reveal the login name.

None of the requests below needed a login. Each one is a single URL or form submission that any visitor, or any bot, can send.

1. Login Error Messages

The WordPress login form tells you whether an email belongs to an account. I typed owner@shop.test with a wrong password, and WordPress 7.1.3 replied that the password for that email address was incorrect. That one line confirms the address is registered.

A made-up name got a different reply: “The username nosuchuser is not registered on this site.” So an attacker can feed a list of guesses, such as admin@, info@ and owner@ at your domain, and sort them by the reply.

The WooCommerce My Account form behaved the same way on my store. It printed the same two messages, word for word, inside a WooCommerce notice.

2. The Lost Password Form

The lost password form is a second oracle. On my test site, an unknown address returned “There is no account with that username or email address.” A real address sent the visitor on to the “check your email” screen instead.

This one is quiet, because nothing gets logged as a failed login. It also sends the real owner a reset email, which some site owners ignore as spam, and that is exactly what a phishing follow-up wants.

To restyle that screen and reword its notice while core keeps handling the keys, customize the WordPress reset password page with hooks.

3. Gravatar Hashes in Comments and the REST API

WordPress turns the admin email into a Gravatar URL, and that URL holds a hash of the address. Gravatar’s own image request docs say the URL is built from a SHA256 hash of the user’s email. A hash cannot be reversed directly, but a guess can be hashed and compared.

That is what I did. The public REST API returned an avatar URL for user 1, and hashing my guess with shasum -a 256 produced the same 64 characters:

The same hash showed up on the front end. I left one comment as the admin on “Hello world!”, and the page source carried the same avatar hash next to it:

So a bot only needs your domain and a short list of common mailbox names. Each guess costs one hash, and a match confirms the address without a single login attempt.

4. Author Archives and ?author=1

Visiting /?author=1 on a default site redirects to the author archive of user 1. On my test site the redirect went to /author/admin/, which handed over the login name. WordPress builds the archive slug from the login unless someone changes it.

The user sitemap at /wp-sitemap-users-1.xml listed the same archive URL. A login name is not the email, but it pairs with the login error above, and it often matches the mailbox name too.

Author archives are rendered by your theme’s template files, with index.php in WordPress as the final fallback. Blocking the redirect therefore has to happen before the theme loads, which is what the plugin fix later does.

5. The REST API Users Endpoint

The REST API lists every user who has published a post, to anyone who asks. My logged-out request to /wp-json/wp/v2/users returned the ID, the display name “Sam Owner” and the slug admin. The REST API users reference documents these public fields.

The endpoint did not return the email itself. I also tried ?search=owner@shop.test and ?search=shop.test, and both came back empty. Core does not let guests search by email.

A search for “owner” did return the admin, because it matched the display name. That is a hint and not a leak, but it narrows the guessing.

6. oEmbed and RSS Feeds

The oEmbed endpoint and the RSS feed both name the author of each post. My request to /wp-json/oembed/1.0/embed for “Hello world!” returned the author name and the author archive URL. The feed carried the same display name in its dc:creator tag.

A display name that matches the login, or the first part of the email, makes this worse. WordPress also sets the display name to the login name on new accounts, as a test user I created showed.

7. WooCommerce Order Emails

WooCommerce sends every order email from the admin email unless you change it. Its settings code uses get_option( 'admin_email' ) as the default for the “From” address, and my test store’s customer email went out from owner@shop.test.

So anyone who places a cheap order gets the admin address in the From and Reply-To lines. No probing is needed at all.

WordPress Get Admin Email: Where It Is Stored

WordPress stores the admin email as the admin_email row in the wp_options table, and you read it with get_option( 'admin_email' ). You can also see and change it under Settings > General in the Administration Email Address field. The account email of each user is a separate value in wp_users.

The get_option() function returns any stored option, and get_bloginfo( 'admin_email' ) returns the same value. I checked both with WP-CLI on the test site, along with the WooCommerce sender setting:

If you search for how to get admin email WordPress values in code, these two calls are the answer.

These calls only work for code running inside WordPress or for someone with server access. That is why attackers use the outside routes above instead of trying to read the option.

Developers often need the admin email for alerts and contact forms. Use get_option( 'admin_email' ) in code that runs on the server, and never print it into a page, a JavaScript variable or a public API response.

The admin email also receives core notices. WordPress sends new user alerts, update results and the periodic admin email check to this address. It needs to be an inbox you read.

That is one more reason to keep it private. An address that gets real security notices is the one a phisher most wants to copy.

Note: Changing the Administration Email Address does not take effect right away. WordPress 7.1.3 sends a confirmation link to the new address, and the old one stays active until you click it.

How to Secure Your WordPress Admin Email

You secure your WordPress admin email by keeping it private, splitting it from public addresses and closing the leaks that confirm it. Five changes covered every leak in my test, and none needed custom code beyond one short filter. Each step below was applied to the same local site and checked again with logged-out requests.

Step 1: Use an Admin Email That Is Not on Your Site

Pick an admin address that appears nowhere public. Keep it off the contact page, out of order emails and away from your social profiles. Change it under Settings > General and confirm the link WordPress sends.

A random mailbox name also defeats the hash guessing in method 3.

Your own user account has a separate email under Users > Profile. Change that one too. The login form and the avatar hash both use the account email instead of the site setting.

Step 2: Give WooCommerce Its Own From Address

Set a store address such as orders@ your domain in WooCommerce > Settings > Emails under Email sender options. That one change took the admin email out of every order email in my test. The new address can forward to you. You still read customer replies.

Use the same field shown under method 7 above. After saving orders@shop.test, I placed a new test order. The From and Reply-To lines showed the store address, and the admin email appeared 0 times in the message.

Step 3: Block User Enumeration With a Plugin

The free Stop User Enumeration plugin closed three of the seven leaks in my test. Version 1.7.9 turned on its main options at activation. I changed no settings.

With it active, /?author=1 returned a 403, the REST users endpoint returned rest_cannot_access and the user sitemap listed no authors. The oEmbed reply kept the display name but dropped the author URL.

Test it from a logged-out window instead of the dashboard. The plugin’s own information panel says it does nothing while you view an admin page, because it assumes a logged-in admin may see users.

It did not touch the login error, the lost password message or the Gravatar hash on comments. That is why the next two steps still matter.

Step 4: Replace the Login Error Messages

WordPress runs every login error through the login_errors filter. One short function can swap them for a single generic message. Put it in a small custom plugin or your child theme’s functions.php file:

add_filter( 'login_errors', function () {
	return 'Login failed. Check your details and try again.';
} );

On my test site this one filter changed all three oracles. The login form, the lost password form and the WooCommerce My Account form all showed the same generic text for real and fake addresses.

The lost password page still moved real addresses to the “check your email” screen, though. Generic text hides the reply, but a careful attacker can still compare where each request lands.

Step 5: Turn Off Avatars or Use a Private Account Email

Avatars leak a hash of the account email. Either switch them off or make sure the email behind them is private. The switch is under Settings > Discussion in Avatar Display. With Show Avatars unticked, my test post rendered 0 Gravatar URLs.

If you want avatars for readers, keep them on and give your admin account the private address from step 1. A hash of a random mailbox name tells a bot nothing useful.

How to Check Your Own Site in Five Minutes

You can check your own site in about five minutes with a private browser window and a terminal. Run each test logged out, against your own domain only, and write down what comes back. Repeat the same checks after every security change to confirm the fix held.

1. Try the login form: Enter your admin email with a wrong password and read the error message.
2. Try the lost password form: Enter an address that has no account and see whether the reply differs.
3. Open the author scan: Visit /?author=1 and note where it redirects.
4. Query the REST API: Open /wp-json/wp/v2/users and check the slugs it lists.
5. Read one order email: Place a test order and check the From line in your inbox.

Keep the results in a small text file with the date. When a plugin update or a new theme reopens a leak, the change shows up the next time you compare.

A staging copy is the safest place to test fixes first. Changing login messages or blocking the REST API can break an app or a form that depends on it. Check those before going live.

If any step returns your admin email or login name, go back to the matching fix above. Run these against your own site only, since probing someone else’s site can break their terms and your local laws.

A login limit adds a useful layer on top. The DevDiggers guide on limiting login attempts in WordPress covers how to slow down a bot that already knows the address.

Two-factor login closes the door behind it. For stores, the roundup of WooCommerce two-factor authentication plugins compares the main options.

Common Mistakes That Keep Leaking the Admin Email

Most sites that still leak the admin email made one of a few small mistakes after a fix. They changed the site setting but not the account email, or they blocked the REST API but left the login message alone. Each one keeps a single leak open, and one is all a bot needs.

• Changing only the site setting: The Administration Email Address and your account email are separate. The login oracle and the avatar hash use the account email.
• Trusting a firewall alone: A firewall may block heavy scans, yet a single login attempt still returns the honest error.
• Forgetting WooCommerce: The From address stays on the old admin email unless you change it in the WooCommerce settings.
• Leaving the display name as the login: Feeds and oEmbed print the display name. A default name repeats your login on every post.
• Reusing the admin email for the newsletter: A sender address on every campaign spreads the admin email to thousands of inboxes. Use a separate marketing address.
• Skipping the retest after updates: A theme or plugin update can add a new author box or API field. Rerun the logged-out checks after big updates.
• Publishing posts as the admin: Use an editor account for posts. That way the archive and API point at a user with fewer rights.

Each of these takes a minute to fix once you know about it. The hard part is remembering them all, which is why a written checklist beats memory here.

Contact forms and WordPress chatbot plugins that collect visitor emails deserve the same care. Send their notifications to a shared inbox instead of the admin address.

The WordPress hardening guide covers the wider setup, from file permissions to database users. A WordPress care plan bundles these checks with updates and backups if you would rather not run them yourself.

Conclusion

How do hackers mine WordPress for admin email addresses? On my October 2026 test site the answer was seven default behaviors. The worst were the login error, the lost password form, the avatar hash and the WooCommerce From address.

The fixes are small. Use a private admin address, give WooCommerce its own sender, add Stop User Enumeration, replace the login errors with the login_errors filter and check your avatars.

Then rerun the five-minute check from a logged-out window. If none of the replies names your admin, a bot has to guess blind.

Frequently Asked Questions (FAQs)