Understanding How Do Hackers Mine WordPress for Admin Emails
A WordPress site’s actual admin email address, the one tied to the wp_options table and shown in your own dashboard, is not something WordPress publishes anywhere on the public-facing site by default. That’s worth stating plainly because a lot of security advice on this topic implies WordPress leaks it directly, and that’s not quite accurate. What attackers actually get from a typical WordPress site is your admin username, and from there, a set of educated guesses, pattern matching, and outside data sources to arrive at a working email address, or a password, without ever needing the email at all.
This covers the real methods attackers use, why the popular “?author=1 reveals your email” claim is more myth than mechanism, and what actually closes these gaps.
Why This Gets Framed as an “Email Mining” Problem in the First Place
The framing itself is worth a second look. Older WordPress security writing latched onto “?author=1 reveals your admin email” as a shorthand for a real and legitimate concern, username enumeration, and the claim has been repeated widely enough since that it’s treated as settled fact rather than checked against what a default install actually does. This matters beyond pedantry: a site owner who reads that claim, disables author archives, and stops there believes the problem is solved when the actual exposure paths (WHOIS, breach reuse, pattern guessing, contact page scraping) are all still wide open. Getting the mechanism right changes what “done” actually looks like for securing this specific attack surface.
What WordPress Actually Exposes by Default
Before getting into attack methods, it helps to separate what WordPress genuinely reveals from what a lot of security content assumes it reveals. By default, a standard WordPress install does not display any user’s email address on the public site, not in author archives, not in the REST API, not in comments unless you’ve configured comments to show commenter emails publicly (most themes don’t). What it can expose is usernames and display names, which is a real problem, just a different one than “your email is public.”
Username Enumeration via Author Archives
Appending ?author=1, ?author=2, and so on to your site’s URL causes WordPress to redirect to that user’s author archive page, and the resulting URL typically contains their username as a slug, something like yoursite.com/author/admin/. This confirms which numeric user IDs exist and what username each one maps to. It does not reveal an email address directly. The risk is real but one step removed: once an attacker has a confirmed valid username, they can combine it with a guessed or purchased email pattern, or use it directly against the login form in a brute-force or credential-stuffing attempt.
The REST API’s User Endpoint
WordPress’s built-in REST API exposes a /wp-json/wp/v2/users endpoint that, on an unmodified install, lists registered users by display name and username (technically the slug). Like author archive enumeration, this reveals identity information, not email addresses, but it’s a faster, more machine-readable way for an automated scanner to collect the same data at scale across thousands of sites in one pass.
Where an Actual Email Gets Found
Since WordPress itself doesn’t hand over the address, attackers typically get it one of these ways instead:
- Pattern guessing. [email protected], [email protected], and [email protected] are common enough patterns that automated tools simply try the obvious combinations against a known domain.
- WHOIS records for the domain itself, if WHOIS privacy protection was never enabled on the registrar side, a completely separate issue from anything WordPress controls.
- Data breach dumps. If the site owner reused the same email on a different service that was later breached, that email (sometimes with a plaintext or crackable password attached) may already be circulating in credential-stuffing lists.
- Publicly listed contact information on the site itself: a Contact Us page, a footer, a WHOIS-style team page, all legitimate content that simply wasn’t meant to double as an attack surface.
- Direct database access through an unpatched SQL injection vulnerability, which pulls the real stored email straight from the wp_users table rather than guessing at all.
Understanding this distinction matters because it changes what actually needs fixing. Hiding author archives helps close the username enumeration gap, but it does nothing to stop WHOIS scraping or a reused password from a different breach, both of which are far more common ways real WordPress accounts actually get compromised.
XML-RPC: A Brute-Force Amplifier, Not an Email Leak
The XML-RPC protocol, used historically for remote publishing tools and the Jetpack/mobile app connection, has a well-documented weakness: its system.multicall method lets an attacker bundle hundreds of login attempts into a single HTTP request, making brute-force attacks dramatically faster and harder for basic rate-limiting to catch. It’s a genuine risk, but as a brute-force accelerator working against usernames already gathered elsewhere, not as a way to directly extract email addresses. If your site doesn’t use Jetpack, a mobile publishing app, or another tool that depends on XML-RPC, disabling it removes this attack surface entirely with no functional downside.
SQL Injection: The One Method That Genuinely Extracts Email Addresses
Unlike enumeration or XML-RPC abuse, a successful SQL injection attack against an unpatched plugin or theme can pull real data straight from the database, including the actual admin email, hashed passwords, and any other user table contents. This is also the least common of the methods discussed here on a well-maintained site, because it requires an actual code vulnerability to exploit, not just default WordPress behavior. Keeping plugins and themes updated closes the door on the overwhelming majority of known SQL injection vulnerabilities, since most get exploited only after a public disclosure and patch, against sites that haven’t updated yet.
Why Any of This Matters Even Without a Directly Exposed Email
- Phishing gets more convincing once an attacker has a confirmed valid username and a guessed or found email, since they can address the target by name and reference real site details.
- Credential stuffing succeeds more often against a known-valid email tied to a specific site, since attackers can test that address against massive lists of previously breached email-password pairs.
- Password reset flows become a target once an attacker has a working email, since a weak or predictable password recovery process can sometimes be abused to gain account access without ever needing the original password.
What This Looks Like on a Real Access Log
For anyone who’s never actually looked at raw server logs during a scan, it’s worth knowing what to search for. Automated enumeration attempts tend to show up as a burst of nearly identical requests in a short window, dozens of hits to /?author=1, /?author=2, and so on within seconds of each other, from a single IP address or a small rotating pool of IPs. A brute-force attempt against wp-login.php looks similar: repeated POST requests to the same endpoint, often with a consistent user agent string that doesn’t match a normal browser. XML-RPC abuse shows up as repeated POST requests to /xmlrpc.php, frequently with a much higher request volume per minute than any legitimate use case would generate, since the entire point of exploiting system.multicall is testing many credential pairs in as few requests as possible.
None of this requires specialized tools to spot manually if you’re comfortable reading raw logs, though a security plugin doing this automatically and alerting on it is a far more practical approach for most site owners than manually reviewing access logs on a regular basis.
How an Attack Actually Chains Together
It helps to see the realistic sequence rather than treating each method as an isolated risk. A typical automated attack against a WordPress site doesn’t rely on one clever trick, it chains several weak points together:
- A scanner hits the site’s REST API or tries ?author=1 through ?author=10, confirming which usernames exist and how many user accounts the site has.
- The scanner cross-references the confirmed usernames against the domain name to generate a short list of likely email patterns, and separately checks whether the domain’s WHOIS data is exposed.
- Those email guesses get checked against public breach databases to see if any of them appear in a previous leak, often alongside a plaintext or crackable password.
- If a plausible email-password pair turns up, the attacker tries it directly against wp-login.php. If not, they fall back to a brute-force or dictionary attack against the confirmed username, often accelerated through XML-RPC’s system.multicall if it’s still enabled.
None of these individual steps requires much sophistication, which is exactly why they’re run at scale by bots against thousands of sites simultaneously rather than targeted at any one site specifically. Closing even one link in that chain, disabling XML-RPC, hiding usernames, or simply not reusing a breached password, is often enough to make an automated attacker move on to an easier target instead.
Closing These Gaps in Practice
1. Stop Username Enumeration
Plugins like Stop User Enumeration or a security suite’s built-in enumeration protection block the ?author=N redirect behavior and restrict the REST API’s user endpoint to authenticated requests only. This is also achievable with a few lines of code in a custom plugin or your theme’s functions.php if you’d rather not add another plugin just for this.
2. Never Use “admin” as Your Actual Username
If your login username is literally “admin,” an attacker doesn’t need to enumerate anything, they’ve already got half of what they need. Renaming the primary admin account to something non-obvious removes an entire category of guesswork instantly and costs nothing.
3. Keep Contact Forms From Leaking Data
Use a form plugin like Contact Form 7 or WPForms that processes submissions server-side without printing raw email addresses into the page’s HTML source, and add CAPTCHA (Google reCAPTCHA or a privacy-friendlier alternative like Cloudflare Turnstile) to block automated scraping bots specifically.
4. Disable XML-RPC if You Don’t Need It
Confirm first that nothing on your site depends on it (check for Jetpack, mobile publishing apps, or a headless setup using XML-RPC specifically) before disabling it through a plugin like Disable XML-RPC, or by blocking access to xmlrpc.php directly in .htaccess.
5. Run a Real Security Plugin
Wordfence, iThemes Security (now Solid Security), and Sucuri all cover multiple layers at once: enumeration blocking, brute-force rate limiting, and malware scanning, which is more effective than trying to patch each gap individually with separate single-purpose plugins.
6. Keep Everything Updated, Without Exception
The SQL injection vector above only works against unpatched vulnerabilities. A site running current versions of WordPress core, its theme, and every active plugin has already closed the door on the overwhelming majority of publicly known exploits in this category.
7. Use Unique, Strong Passwords and a Password Manager
Even a found or guessed email is far less useful to an attacker if the password behind it isn’t reused anywhere else and isn’t guessable. A password manager like Bitwarden or 1Password removes the temptation to reuse a password across multiple accounts, which is the single biggest reason credential-stuffing attacks succeed in the first place.
8. Turn On Two-Factor Authentication
2FA means a correctly guessed or found email-and-password combination still isn’t enough to log in. Wordfence Login Security, or a dedicated plugin like Two-Factor, both add this layer without much setup friction.
9. Protect the Domain-Level Data Too
Since WHOIS records are a real source of exposure entirely outside WordPress’s control, confirm WHOIS privacy protection is actually enabled at your domain registrar. It’s frequently free and takes under a minute to turn on, closing off one of the more overlooked paths covered above.
10. Audit Publicly Listed Contact Information Deliberately
A business site usually needs some public contact path, and that’s fine; the goal isn’t to hide entirely but to make sure it’s the right address doing the exposing. Using a dedicated inquiries@ or hello@ address for public-facing contact forms and footers, kept separate from whatever email is tied to the WordPress admin account itself, means even a fully successful scrape of your public contact info doesn’t hand an attacker anything useful against the actual login. This is a small structural change, but it decouples two things that a lot of small business sites accidentally combine into one address by default.
If You Manage Several WordPress Sites
Agencies and freelancers running multiple client sites face a version of this problem that’s easy to underestimate: a username-and-password combination reused across two or more client sites means one compromised account potentially opens every site sharing that login, not just the one that got breached. A password manager with unique, generated credentials per site, combined with 2FA on every admin account without exception, closes most of that risk. It’s also worth standardizing enumeration protection and XML-RPC handling as part of a shared client-site checklist rather than remembering to configure it individually on each new build, the same way a directory-indexing check or SSL verification would be a standard step before a site goes live.
Common Questions
Does hiding author archives fully solve this problem?
No, it closes one specific enumeration path, but WHOIS exposure, breach data, and pattern guessing all exist entirely outside WordPress’s control. Treat it as one item in a layered approach, not a complete fix on its own.
Is XML-RPC still relevant to disable in 2026?
For most sites, yes, unless you’re actively using Jetpack or a mobile app that depends on it. The protocol is old, rarely necessary for a typical site, and the brute-force amplification risk hasn’t gone away just because the technology has aged.
Should I change my admin email address if I suspect it’s been exposed?
It’s a reasonable precaution, paired with a password change and enabling 2FA if it isn’t already on. Changing the email alone without addressing the password and enumeration gaps that led to the exposure just delays the same problem rather than fixing it.
How would I know if my site is already being targeted this way?
A security plugin’s activity log is the most direct signal: a sudden spike in failed login attempts, repeated requests to xmlrpc.php, or a pattern of sequential ?author= requests in your server’s access logs are all telltale signs of automated enumeration or brute-force activity already in progress. Most managed hosts also flag unusual login traffic automatically and will notify the account owner if a site is under active attack, though relying solely on the host to catch it isn’t a substitute for a security plugin’s own monitoring.
Does using two-factor authentication make the other fixes unnecessary?
No. 2FA is a strong last line of defense, but it doesn’t stop the enumeration and reconnaissance steps that happen before a login attempt, and it doesn’t protect against a SQL injection vulnerability pulling data directly from the database, bypassing the login form entirely. Treat 2FA as one layer in the sequence, not a replacement for the others.
Is a free security plugin good enough, or do I need a paid tier?
The free tiers of Wordfence, Sucuri, and Solid Security all cover the core protections discussed here: enumeration blocking, login rate limiting, and basic firewall rules. Paid tiers generally add faster malware-definition updates, premium support, and more advanced firewall rule sets, which matter more for a high-traffic or high-value site than for a small business brochure site. Starting with the free tier and upgrading only if the site’s risk profile actually justifies it is a reasonable default for most small WordPress sites.
Interesting Reads:
Can You Undelete a WordPress Category? Here’s the Answer!
Learn How to Add Coupons on WordPress Products Easily
Can Directory Indexing Be Turned Off on WordPress? Find Out!
