How attackers collect WordPress usernames and email addresses

Attackers do not always begin a WordPress attack by trying passwords.

Often, the first stage is much quieter: they collect information.

They may try to identify:

• valid WordPress usernames;
• author names;
• email addresses;
• user IDs;
• author slugs;
• public profile information;
• login identifiers.

This process is commonly called user enumeration or account enumeration.

Knowing a username or email address does not compromise a WordPress account by itself. A password, authentication token or another valid authentication factor is still required.

However, identifying valid accounts removes uncertainty for an attacker.

Instead of attempting:

unknown username
+
unknown password

an attacker may reduce the problem to:

known username
+
unknown password

That information can make password attacks, credential stuffing, phishing and social engineering more targeted.

This guide explains how WordPress usernames and email-related identifiers can become publicly discoverable, which exposure points matter, what WordPress actually reveals, why Gravatar hashes require careful interpretation and how to reduce unnecessary account information without mistaking obscurity for real authentication security.

What is WordPress username enumeration?

Username enumeration is the process of determining whether particular WordPress user accounts exist.

The information discovered might include:

• a login username;
• a public author slug;
• a display name;
• a WordPress user ID;
• an author archive URL;
• another identifier that can be correlated with a login account.

The critical word is:

correlated

A public name is not necessarily the login username.

For example, a WordPress account could contain:

Login username:
j.smith-admin

Display name:
John Smith

Author slug:
john-smith

Only the first value is necessarily the actual username used by the authentication system.

Username discovery is not account compromise

This distinction matters.

A username is normally an identifier, not a secret equivalent to a password.

If an attacker discovers:

johnsmith

they have not automatically gained access to the account.

They still need to defeat one or more authentication controls such as:

• the password;
• two-factor authentication;
• rate limiting;
• IP restrictions;
• another authentication mechanism.

Reducing username exposure can still be useful, but it should be treated as one layer in a larger security strategy.

Why attackers collect usernames first

Imagine an automated login attempt where both account name and password are unknown.

The attacker has to guess two variables:

username
+
password

If the username is known, only the authentication secret remains unknown:

known username
+
password

This can make several types of attack more efficient.

Password guessing

The attacker can concentrate attempts against accounts known to exist.

Credential stuffing

Credentials leaked from unrelated services can be tested against known WordPress identities.

Phishing

A known staff name, username or email address can make targeted messages more convincing.

Social engineering

Public account information can reveal which people are likely to have access to the WordPress installation.

WordPress has several different user identifiers

Before discussing exposure, it helps to distinguish the fields WordPress uses.

Login username

The actual WordPress login name is stored as:

user_login

User nicename

WordPress also stores:

user_nicename

This is commonly used as the author URL slug.

Display name

The:

display_name

field is the human-readable name WordPress can display publicly.

Email address

The account email is stored separately as:

user_email

These values can be identical, similar or completely different.

Do not assume the author slug is always the login username

A common WordPress configuration may produce:

username:
johnsmith

user_nicename:
johnsmith

which makes the author slug look exactly like the login identifier.

But this is not a requirement.

A site could instead use:

username:
js-admin-93

author slug:
john-smith

display name:
John Smith

Finding:

/author/john-smith/

would then reveal the author slug, but not necessarily the true login username.

Author archives are one source of user information

WordPress can generate public author archive URLs.

A typical author URL is:

https://example.com/author/john-smith/

WordPress Core uses the user’s nicename when generating author archive URLs.

The official get_author_posts_url() documentation shows that WordPress uses user_nicename when constructing the author URL under normal pretty-permalink configurations.

Why author slugs can matter

Suppose:

user_login
=
editorjohn

user_nicename
=
editorjohn

The public author URL:

/author/editorjohn/

now reveals a value identical to the account username.

This is not always the case, but it is common enough that author URLs should be included in an account-exposure audit.

The author query parameter can reveal valid authors

WordPress also supports author queries involving a numeric user ID.

For example:

?author=1

Depending on the site’s permalink configuration, WordPress can resolve an author request to the corresponding author archive.

This can reveal:

• that a particular author ID exists;
• the resulting public author URL;
• the corresponding author nicename.

It is one of the classic WordPress account-enumeration paths.

Do not confuse user IDs with usernames

Discovering:

user ID 4

does not automatically reveal:

user_login

But identifiers can be correlated.

If ID 4 redirects to:

/author/company-admin/

the attacker has learned something useful about that user even if the true login name remains uncertain.

The REST API is another important source of public user data

WordPress exposes a REST API at URLs below:

/wp-json/

One Core endpoint is:

/wp-json/wp/v2/users

The public representation of a WordPress user can contain fields including:

• user ID;
• display name;
• author link;
• user slug;
• description;
• avatar URLs.

The official WordPress REST API Users reference documents which fields appear in view, embed and restricted edit contexts.

The REST API does not normally expose account email addresses anonymously

This is an important correction to a common misconception.

The WordPress REST user schema includes fields such as:

username
email
roles
capabilities

but these belong to the restricted:

edit

context.

An anonymous request does not simply receive every private user field merely because the REST endpoint exists.

The normal public representation instead exposes selected public information.

Public REST user slugs can still assist enumeration

The:

slug

field is available in public REST contexts.

If that slug is identical or closely related to the login username, it can become useful enumeration data.

This is one reason REST exposure should be considered together with author URLs instead of treating each source independently.

The security model of the REST API is covered in WordPress REST API security basics.

Removing the REST API is not automatically the right solution

The REST API is part of modern WordPress.

It can be used by:

• the Block Editor;
• plugins;
• WooCommerce;
• mobile applications;
• headless sites;
• external integrations.

Disabling it only to hide a username can create much larger compatibility problems than the original exposure justified.

A better approach is to understand:

which data is public
+
whether that public data
matches a login identifier

Display names can help attackers identify real people

A WordPress display name may appear in:

• post bylines;
• author archives;
• REST API responses;
• comments;
• theme templates.

For example:

Written by Sarah Williams

does not necessarily reveal Sarah’s login username.

However, it provides identity information that can be correlated with:

• company staff pages;
• LinkedIn profiles;
• public email patterns;
• other online accounts.

Enumeration is often a correlation problem rather than a single magical endpoint leaking everything at once.

Public staff pages can reveal likely WordPress users

A company website might publicly list:

Sarah Williams
Head of Marketing

Michael Ross
Content Manager

James Lee
Administrator

That information is perfectly legitimate to publish.

But it can also help an attacker infer which people are likely to:

• publish content;
• manage the site;
• receive WordPress notifications;
• have privileged accounts.

This does not mean staff pages should be removed. It means account security should not depend on employees’ identities being secret.

Email addresses can be collected from normal public content

Email exposure is not uniquely a WordPress problem.

A site may intentionally publish addresses such as:

info@example.com

sales@example.com

john.smith@example.com

inside:

• contact pages;
• team pages;
• footer content;
• press pages;
• PDF documents;
• privacy notices;
• job advertisements.

If an address is publicly visible in HTML, automated systems can potentially collect it.

mailto links make email addresses machine-readable

This markup:

<a href="mailto:john@example.com">
    Contact John
</a>

contains the email address directly in the document source.

Changing the visible anchor text from:

john@example.com

to:

Contact John

does not hide the address from software inspecting the HTML.

Obfuscation can reduce simple harvesting

TheOneWP Cover Email Address provides a way to make publicly displayed email addresses less straightforward for basic automated harvesting.

This type of technique can reduce simple scraping, but it should not be treated as cryptographic secrecy.

If a visitor must ultimately be able to obtain and use the email address, determined software may also be able to recover it.

Gravatar creates a different kind of email exposure

WordPress commonly uses Gravatar to retrieve user avatars.

The Gravatar URL is derived from the user’s email address.

Current WordPress versions do not place the plaintext account email directly into that URL.

Instead, WordPress normalizes the email and generates a cryptographic hash.

WordPress now uses SHA-256 for Gravatar hashes

Since WordPress 6.8, Core uses:

SHA-256

for Gravatar email hashes.

Conceptually:

email
↓
trim
↓
lowercase
↓
SHA-256
↓
Gravatar identifier

The current get_avatar_data() documentation confirms both the SHA-256 behavior and that WordPress derives the hash from the normalized email address.

A Gravatar hash is not the plaintext email address

This distinction is essential.

If a page exposes something like:

8b1a9953...

that is not equivalent to publishing:

john@example.com

directly.

Cryptographic hashes are one-way transformations.

You cannot simply “decode” SHA-256 back into the original address.

But deterministic hashes can confirm candidate emails

The important privacy issue is that the process is deterministic.

The same normalized email generates the same hash.

Therefore, if somebody already suspects that an account uses:

john.smith@example.com

they can hash that candidate using the same normalization rules and compare the result with the public Gravatar identifier.

If they match, the candidate has effectively been confirmed.

This is very different from magically reversing SHA-256.

Email pattern guessing makes correlation easier

Many organizations use predictable email patterns such as:

firstname.lastname@example.com

firstinitiallastname@example.com

firstname@example.com

If the staff member’s name is public and a Gravatar hash is available, a small number of plausible addresses may exist.

The problem becomes:

generate plausible candidate
↓
normalize candidate
↓
hash candidate
↓
compare

rather than trying to reverse an arbitrary cryptographic hash.

This issue is examined in detail in How Gravatar exposes WordPress user emails.

Gravatar can also enable cross-site correlation

If the same email identity is used with Gravatar across multiple websites, the deterministic identifier can make it possible to associate apparently separate activity with the same account identity.

This is a privacy consideration rather than proof that the person’s email has been directly disclosed.

The distinction matters:

correlation risk
≠
plaintext disclosure

Local avatars avoid the Gravatar request path

TheOneWP Local Avatar allows WordPress users to use locally managed avatar images.

When the site is configured so Gravatar is not used as the fallback, this can remove the need to construct an external Gravatar request from the user’s email-derived identifier.

That can improve privacy while also keeping avatar assets under the site’s own control.

Comments deserve separate attention

WordPress collects an email address from commenters in many standard configurations.

That email is not normally rendered as public comment content by WordPress Core.

However, comment avatars can involve the same Gravatar mechanism discussed above.

Custom themes or plugins can also choose to expose additional comment fields, so do not assume every site’s comment output is identical to Core defaults.

Custom themes can accidentally expose email addresses

A developer could output:

$user->user_email

inside a public template.

WordPress will not stop the developer from intentionally rendering that value.

Likewise, custom REST endpoints can expose sensitive account information if permissions and response schemas are poorly designed.

An audit therefore needs to inspect custom code rather than merely check WordPress Core behavior.

Plugins can introduce additional user endpoints

Plugins can register custom REST routes and frontend interfaces.

Examples might include:

• membership directories;
• community profiles;
• marketplace sellers;
• learning-management profiles;
• support agents;
• CRM integrations.

Those features may intentionally expose user information that WordPress Core would not publish on its own.

User directories can provide rich enumeration data

A membership site might intentionally expose:

Name:
Sarah Williams

Profile:
sarah-williams

Company:
Example Ltd

Avatar:
...

Public contact:
...

Nothing about that data is necessarily a vulnerability.

But administrators should understand that public member directories provide attackers with an account-identification dataset if those identities overlap with authentication accounts.

Login forms can reveal whether an account exists

Authentication error messages deserve attention because different responses can sometimes reveal whether an identifier is valid.

Conceptually:

Unknown username
→
one error

Valid username + wrong password
→
different error

When responses differ, an observer may be able to infer whether the submitted identifier exists.

This is known as:

authentication enumeration

Password reset forms can also become an enumeration signal

Any account-recovery workflow that responds differently for:

known account

and:

unknown account

can potentially disclose account existence.

This does not necessarily expose the password or email address itself.

It can simply confirm:

this identifier belongs
to a real account

Do not expose more login information than necessary

For security-sensitive authentication interfaces, administrators should consider whether error messages need to distinguish between:

invalid username

and:

incorrect password

Generic authentication failures can reduce this source of information.

However, error wording is still only one layer of protection.

Email login changes what an attacker may target

Modern WordPress supports authentication using:

• username;
• email address.

This means an exposed email address can potentially be an authentication identifier even when the site’s visible author slug is unrelated to the username.

See WordPress login: username vs. email, which is more secure? for the trade-offs between the two identifier types.

Restricting the accepted login identifier can reduce the attack surface

TheOneWP Restrict Login Identifier lets the site narrow which identifier type WordPress accepts during login.

For example, a site may decide to accept:

username only

instead of allowing multiple equivalent login identifiers.

This does not make the accepted username a secret.

It reduces the set of identifiers that the login system considers valid.

Public email addresses should not automatically equal administrator accounts

An organization can reduce unnecessary risk by separating:

public contact identities

from:

privileged WordPress identities

For example:

public:
marketing@example.com

WordPress administrator:
different internal account identity

This is not mandatory, but it can reduce correlation between public contact information and privileged authentication accounts.

Generic role accounts can create their own problems

Using:

admin

administrator

editor

webmaster

as login usernames makes the identifier highly predictable even without enumeration.

Changing those names does not make the password irrelevant, but avoiding obvious high-value usernames removes an unnecessary convenience for attackers.

Changing the username alone is not sufficient hardening

A site with:

username:
x9f3-admin-secret

password:
password123

is not secure.

The password remains catastrophically weak.

Username obscurity should never replace:

• strong unique passwords;
• two-factor authentication;
• login rate limiting;
• least privilege;
• account monitoring.

Two-factor authentication reduces the value of a discovered username

If an attacker knows:

username
+
password

but the account also requires a valid second factor, the stolen or guessed password may still be insufficient for interactive login.

TheOneWP Two-Factor Authentication adds another authentication layer to supported WordPress login flows.

That provides a much stronger defense than relying on the username remaining hidden forever.

Rate limiting reduces repeated login attempts

Knowing a valid username becomes more valuable when an attacker can test unlimited passwords against it.

Rate limiting changes that equation by restricting repeated authentication attempts.

See How to limit login attempts in WordPress for the broader defensive strategy.

Hiding author slugs can reduce one enumeration path

TheOneWP Hide Author Slug replaces the username-derived author slug with a random token while leaving the underlying login name unchanged.

Its coverage includes:

• author URLs;
• author-query redirects;
• the relevant REST API user representation.

This means the publicly visible author identifier does not need to mirror the actual account username.

Disabling author archives is another option

Some WordPress sites do not need author archives at all.

For example, a business website where every article is published under one corporate editorial identity may gain little from individual author archive pages.

TheOneWP Disable Author Archive can remove that public archive workflow when it serves no useful purpose.

That is different from merely changing the author slug.

Hide Author Slug

author archive remains
+
public identifier changes

Disable Author Archive

author archive itself
is removed from the public workflow

Neither option guarantees usernames are hidden everywhere

A username may still appear through:

• custom templates;
• plugin output;
• authentication responses;
• custom REST endpoints;
• logs accidentally made public;
• third-party integrations.

Account exposure needs to be audited across the complete application.

Search-engine indexing can preserve exposed identifiers

If an author URL has been public for years, changing it today does not mean every historical reference disappears immediately.

Old identifiers may remain in:

• search-engine indexes;
• web archives;
• external links;
• cached pages;
• old social posts.

This is another reason not to treat username secrecy as the site’s primary authentication control.

Email addresses may remain in downloaded documents

Removing an email address from a web page does not necessarily remove it from:

• old PDFs;
• media attachments;
• press kits;
• downloadable brochures;
• archived documents.

A proper exposure audit should include downloadable content as well as HTML pages.

Public repositories and code can leak operational emails

Development workflows may expose addresses through:

• Git commit metadata;
• public repositories;
• sample configuration files;
• issue trackers;
• package metadata.

This is not specific to WordPress, but those addresses can still be correlated with WordPress users.

Data breaches outside WordPress can complete the picture

Suppose an attacker discovers:

John Smith
+
john.smith@example.com

from public information.

If the same email appears in credential data leaked from another unrelated service, the attacker may try those credentials against WordPress.

This is why password reuse is dangerous.

WordPress itself may be perfectly patched while an account is compromised because its owner reused credentials elsewhere.

Unique passwords are essential

Every WordPress account should use a password that is not reused on:

• email accounts;
• social networks;
• hosting panels;
• other WordPress sites;
• SaaS platforms.

If a credential leak from another website contains the same password, reuse turns an unrelated breach into a WordPress problem.

Least privilege limits the value of discovered accounts

Not every user should be an Administrator.

If an attacker targets a known content author, the damage possible from that account should reflect what the person actually needs to do.

For example:

Writer
→
Author or Contributor capabilities

Site administrator
→
Administrator capabilities

Do not hand every employee maximum privileges because configuring roles looked mildly inconvenient on Tuesday afternoon.

Audit WordPress user roles periodically

Check for:

• unnecessary Administrators;
• former employees;
• unused service accounts;
• shared accounts;
• unexpected role changes.

The broader permission model is explained in WordPress user roles and capabilities, explained.

How to audit your own site for username exposure

Perform the audit on a site you own or are authorized to test.

Check author URLs

Inspect published posts and determine what appears in author links.

Compare:

display name

author slug

actual login username

Check public REST responses

Review the site’s public REST user representation and identify which user information is intentionally exposed.

Check post bylines

Determine whether templates reveal:

• full names;
• slugs;
• profile URLs.

Check Gravatar URLs

Determine whether external avatar URLs expose deterministic email-derived hashes.

Check public contact information

Search the site for:

@example.com

and inspect whether personal addresses need to be publicly exposed.

Check login responses

Determine whether the authentication interface unnecessarily confirms valid account identifiers.

Check plugins and custom REST endpoints

Inspect any public user directories or custom account APIs.

How to audit email exposure

Search more than visible page text.

Review:

• HTML source;
• mailto: links;
• structured data;
• REST responses;
• downloadable documents;
• author profiles;
• comment output;
• custom API responses;
• Gravatar URLs.

The objective is not necessarily to eliminate every public address.

Some addresses need to be public.

The objective is to understand which identities are exposed and whether they correspond to privileged accounts.

Do not try to make public information magically private

If customers need to send email to:

sales@example.com

then that address cannot simultaneously function as perfectly secret information.

Security architecture should acknowledge this.

Protect the associated systems rather than pretending the public address will never be discovered.

Separate privacy goals from authentication goals

Several controls in this area solve different problems.

Hide Author Slug

Reduces exposure of the account’s username-derived public author identifier.

Disable Author Archive

Removes author archive pages when they are unnecessary.

Cover Email Address

Reduces straightforward harvesting of publicly displayed email addresses.

Local Avatar

Can avoid external Gravatar requests and their email-derived identifiers when configured without the Gravatar fallback.

Restrict Login Identifier

Controls which identifier type WordPress accepts for authentication.

Two-Factor Authentication

Strengthens actual account authentication.

None of these controls should be described as interchangeable.

Common username and email exposure mistakes

Assuming the display name is the login username

They are separate WordPress fields.

Assuming every author slug is the login username

The values may match, but they do not have to.

Assuming the REST API exposes private account emails to everyone

Core restricts sensitive user fields according to context and permissions.

Assuming Gravatar publishes plaintext email addresses

Modern WordPress sends a deterministic SHA-256-derived identifier, not the plaintext address.

Calling SHA-256 “encrypted email”

A hash and encryption are different mechanisms.

Claiming a Gravatar hash can simply be decoded

The practical risk is candidate verification and correlation, not ordinary reversal of SHA-256.

Disabling the REST API just to hide usernames

This can break legitimate WordPress functionality while avoiding the real authentication problem.

Removing author archives and assuming the job is finished

Account identifiers can appear through multiple independent paths.

Publishing personal email addresses unnecessarily

Use role addresses when they better fit the business purpose.

Using public contact emails as highly privileged login accounts

This creates unnecessary correlation between public identity and privileged authentication.

Using predictable usernames such as admin

No enumeration is needed when the identifier is obvious from the beginning.

Relying on username secrecy instead of strong authentication

Identifiers eventually leak. Security should remain strong when they do.

WordPress username and email security checklist

• Identify every privileged WordPress account.
• Check whether login usernames match public author slugs.
• Check whether login usernames match display names unnecessarily.
• Review author archive URLs.
• Review numeric author-query behavior.
• Inspect public REST API user responses.
• Review custom REST endpoints.
• Review membership and user-directory plugins.
• Search public pages for personal email addresses.
• Inspect mailto: links.
• Review downloadable documents for addresses.
• Inspect Gravatar usage.
• Understand that Gravatar hashes are deterministic but not plaintext emails.
• Consider local avatars where third-party Gravatar requests are unnecessary.
• Review login error messages.
• Review account-recovery responses.
• Avoid predictable administrative usernames.
• Use strong, unique passwords.
• Enable two-factor authentication for important accounts.
• Rate-limit repeated authentication attempts.
• Use least privilege.
• Remove dormant or unnecessary accounts.
• Separate public contact identities from privileged accounts where practical.
• Do not disable required WordPress functionality merely for obscurity.
• Treat username hiding as defense in depth, not the primary authentication control.

Related WordPress security guides

Continue with these related guides and tools:

• WordPress REST API security basics
• How Gravatar exposes WordPress user emails
• WordPress login: username vs. email, which is more secure?
• A WordPress login hardening checklist
• How to limit login attempts in WordPress
• WordPress user roles and capabilities, explained
• Auditing dormant WordPress user accounts
• Hide Author Slug
• Disable Author Archive
• Restrict Login Identifier
• Cover Email Address
• Local Avatar
• Two-Factor Authentication

Final thoughts

WordPress usernames and email addresses are rarely exposed through one dramatic vulnerability.

More often, attackers can build a picture from several ordinary public signals:

author archive
+
REST user data
+
display name
+
staff profile
+
public email
+
Gravatar identifier
+
authentication response
=
more complete account profile

That process is why information exposure should be considered as a system rather than a single endpoint.

At the same time, administrators should avoid exaggerating what these discoveries mean.

A public author slug is not a password.

A Gravatar SHA-256 hash is not the plaintext email address.

A display name is not necessarily a login username.

And hiding /author/john/ does not compensate for a reused password and no second factor.

The strongest strategy is therefore layered:

reduce unnecessary identifier exposure
+
use non-obvious account identities where practical
+
strong unique passwords
+
two-factor authentication
+
rate limiting
+
least privilege
+
regular account audits

Use tools such as TheOneWP Hide Author Slug, Cover Email Address and Local Avatar to reduce unnecessary public exposure where those controls fit the site.

Then protect the authentication layer as though the username and email address will eventually become known anyway.

Because on a public website, assuming identifiers will remain secret forever is not a security strategy. It is optimism wearing an administrator badge.