Don't reveal and show admin email address in "changed email address" template to low permission user roles - Privacy issue

[ReneHermi]

## Description

When a WordPress user changes their password or email address, Core sends a notification informing them of the change. The default password-change and email-change notification templates currently include the site’s Administration Email Address through the ###ADMIN_EMAIL### placeholder.

This value is taken from Settings → General → Administration Email Address. It is a site-level configuration value and is not necessarily associated with a WordPress administrator user account.

However, the address may still belong to an identifiable site owner, employee, developer, agency, or hosting administrator. It may also be the same address used by an administrator account. WordPress administrators are not clearly informed that this address can be included in notifications sent to ordinary account holders.

The recipient may be a Subscriber, customer, member, student, forum participant, or another low-privilege user. On sites that permit public registration, an unknown visitor can create such an account directly. E-commerce, membership, LMS, forum, and similar plugins may also provide customer-facing account registration even when the Core “Anyone can register” setting is disabled.

Consequently, the Administration Email Address may be disclosed to users who have no administrative relationship with the website and no need to receive its operational contact address.

## Why This Is Problematic

The original purpose of these notifications is valid: users should be informed when account credentials or contact details are changed so that an unauthorized change does not remain unnoticed.

The Administration Email Address is not required to achieve that purpose.

The notification already identifies the website and includes its URL. Users can return to the website and use its published contact form, support page, customer-support process, or another intentionally designated communication channel.

The Administration Email Address may not be an appropriate support contact. For example, it may belong to a technical administrator, hosting provider, freelance developer, or agency that is not responsible for end-user support.

The current default therefore creates an unnecessary disclosure of a potentially personal or operational email address. It may also make targeted spam, phishing, password spraying, credential stuffing, or social-engineering attempts easier when the disclosed address is associated with an administrator account.

Disclosure of the address alone does not grant access to the website and should not be described as direct account compromise, authentication bypass, or privilege escalation. This issue is more appropriately classified as a privacy-by-default problem and a limited information disclosure.

## Steps to Reproduce Using WordPress Core

1. Navigate to Settings → General.
2. Enable “Anyone can register.”
3. Ensure that the default role is Subscriber.
4. Register a Subscriber account.
5. Log in using that account.
6. Change the account’s password or email address.
7. Inspect the notification email sent by WordPress.

### Actual Result

The notification includes the site’s Administration Email Address in wording similar to:

If you did not make this change, please contact the Site Administrator at [admin@…](mailto:admin@…).

### Expected Result

The notification should inform the user about the account change and identify the affected website without disclosing the site’s Administration Email Address.

For example:

If you did not make this change, please visit ###SITEURL### and contact the site through its official support channel.

## Alternative Reproduction Through Customer Registration

1. Install a plugin that provides customer or member accounts, such as an e-commerce, membership, LMS, or forum plugin.
2. Create an account through its normal public registration or checkout process.
3. Log in using the resulting low-privilege account.
4. Change the account’s password or email address.
5. Inspect the notification sent by WordPress Core.

The notification may disclose the same Administration Email Address even though the user registered only as a customer or member.

## Recommended Implementation

Remove ###ADMIN_EMAIL### from the default password_change_email and email_change_email notification messages.

The existing placeholder substitution should initially remain available for backward compatibility. Plugins and site-specific code can customize these messages through filters and may deliberately use ###ADMIN_EMAIL###. Removing the substitution immediately could cause customized templates to send the literal placeholder text.

The recommended approach is therefore:

1. Remove ###ADMIN_EMAIL### from the two Core default templates.
2. Retain its substitution temporarily for customized and filtered templates.
3. Document the placeholder as deprecated.
4. Remove the substitution only after an appropriate backward-compatibility period.
5. Add tests confirming that Core’s default notifications do not contain the admin_email value.

A future enhancement could introduce an explicitly configured public support URL or support email address. The site’s operational Administration Email Address and its public end-user support contact serve different purposes and should not be treated as interchangeable.

## Historical Context

The password-change and email-change notifications were introduced in WordPress 4.3 to prevent account changes from occurring silently. This ticket does not propose removing or weakening those notifications.

It proposes removing information that is not required for the notifications to fulfil their security purpose while preserving the account-change warning itself.

July 13, 2026: I have updated the ticket description to incorporate the points raised in the discussion and to describe the issue more accurately.

In particular, the revised description now clarifies that the disclosed value is the site-level Administration Email Address and not necessarily the email address of an administrator user account. It also reframes the issue primarily as an unnecessary information disclosure and privacy-by-default concern rather than a direct account-compromise vulnerability.

The updated description preserves the original reproduction scenario and proposed outcome while adding the security rationale behind the existing notifications, the practical impact, and the backward-compatibility considerations discussed above.

[swissspidy]

#57640 was marked as a duplicate.

[swissspidy]

The email address shown in these emails is not a specific user's email address, but the one you set under Settings -> General as "Administration Email Address".

[ReneHermi]

I know, you know but I claim the "administration email address" has often an existing admin user account because the average small website owner adds there the same email address that he uses for maintaining his website.

I experienced this often on client websites and even on personal websites of mine.

But you can put the security factor aside and take the privacy one.

This was never an issue for me as I had the assumption this mail address would be private.
When I happened to notice that this email address is sent to all my subscribers who want to change their mailing address, this became a problem because this email address was never intended for the public and there is no clear warning in admin dashboard that the administrator email address is visible to other people.

When we don't remove the mail address we should at least mention that this mail address is no private one and could be visible to subscribers.

[masteradhoc]

@ReneHermi Thanks for the ticket! I agree this is definitely not optimal.

The intent behind including the admin email is understandable — giving users a way to report unauthorized password changes — but it is unnecessary. ###SITENAME### and ###SITEURL### are already present in the same template, so users can simply visit the site and use the official contact channel. We also can't assume the admin email belongs to someone who can handle end-user support; it could be a technical administrator, an agency, or another party who may not be the right point of contact.

Proposed fix: remove ###ADMIN_EMAIL### from the email template string and its corresponding substitution in wp_update_user(). The line would simply read "please contact the Site Administrator" — no email exposed, no functional information lost. This is a minimal, low-risk change.

I'll provide a patch soon.

When a user's password or email address is changed, WordPress sends them a notification email. Both of these emails currently include the site's Administration Email Address via the ###ADMIN_EMAIL### placeholder, with the message:

"If you did not change your password, please contact the Site Administrator at [admin@…]"

This exposes the Administration Email Address to any user who triggers these notifications — subscribers, WooCommerce customers, newsletter subscribers, etc. The address is often a personal email belonging to the site owner, and was never intended to be public-facing. It can also belong to a technical administrator or agency who is not the right contact for end-user support.

The ###SITENAME### and ###SITEURL### placeholders are already present in both email templates, giving users sufficient context to find the site and reach out through the appropriate channel.

Trac ticket: https://core.trac.wordpress.org/ticket/57639

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): claude-sonnet-4-6
Used for: PR description drafting

[masteradhoc]

Waiting for review of a committer, happy to work on the PR if necessary.

[wildworks]

We cannot change the milestone due to an issue with Trac itself, but since 7.1 Beta1 is imminent, I would like to mark this ticket to be punted to 7.2 at least.

As far as I can see, opinions have not yet converged, and it seems that more careful discussion is required.

[ReneHermi]

Thanks for taking a look @wildworks

I'd like to clarify one point that I think is important for evaluating the impact of this issue.

Although this technically requires a Subscriber account, these accounts are often not trusted accounts in practice. On many WordPress sites anyone can create one through public registration, and even when that option is disabled, plugins such as WooCommerce, Easy Digital Downloads, membership, LMS, forum, or newsletter plugins routinely create low-privilege user accounts through normal customer registration or checkout flows.

This means the Administration Email Address can often be obtained by any visitor with very little effort, making the disclosure both easy to automate and applicable to a large number of sites.

Regardless of whether the Administration Email Address belongs to a specific administrator account, it is still information that administrators may reasonably expect to remain private. I also don't see a functional requirement for exposing it in these notification emails, especially since users already receive the site name and URL and can use the site's normal support or contact channels.

For me, the question is therefore less whether this is a security issue and more whether there is any benefit that justifies disclosing the Administration Email Address to low-privilege users. If there isn't, removing the placeholder seems like the most privacy-friendly and lowest-risk solution.

[vikingtechguy]

I have reviewed this from both a privacy-engineering and security perspective.

I agree that the Administration Email Address is not necessarily the email address of a WordPress administrator user account. WordPress treats the site-level admin_email option and individual user-account email addresses as separate values.

That distinction, however, does not resolve the underlying privacy issue.

The Administration Email Address may still belong to an identifiable natural person, including a site owner, employee, freelance developer, hosting administrator, or agency contact. It may also happen to be the same address used by an administrator account. WordPress cannot assume that it is a public or role-based mailbox.

The relevant question is whether a subscriber, customer, member, or other low-privilege user needs this address in order to understand or respond to their own password or email change. In the ordinary case, they do not.

The notification already contains the site name and site URL. A user can return to the website and use its official support or contact channel. Furthermore, the Administration Email Address may belong to a technical operator who is not the appropriate person to handle end-user support.

From a privacy perspective, the existing default conflicts with the principles of data minimisation and privacy by default. It reveals information that is not necessary for the notification’s purpose and does so without clearly informing the administrator that the address will be distributed to ordinary account holders.

From a security perspective, disclosure of an email address does not by itself compromise an administrator account, so this should not be treated as an authentication bypass or high-severity account takeover vulnerability. It nevertheless creates a useful information-disclosure primitive. The address can support targeted phishing, password spraying, credential stuffing, administrator enumeration, spam, or social engineering. The risk increases because low-privilege accounts are commonly available through public registration, checkout, membership, LMS, forum, newsletter, and similar workflows.

I therefore support removing the Administration Email Address from the default password-change and email-change notification templates.

I would recommend one adjustment to the current patch for backward compatibility. The default templates should stop using ###ADMIN_EMAIL###, but the placeholder replacement should initially remain available for plugins or site owners that deliberately add it through the password_change_email or email_change_email filters. Removing the replacement immediately could cause customized templates to send the literal text ###ADMIN_EMAIL###. The placeholder could instead be formally deprecated and removed after an appropriate compatibility period.

A future improvement would be to introduce a dedicated, explicitly configured public support URL or support email. The site’s operational Administration Email Address and its public customer-support contact serve different purposes and should not be treated as interchangeable.

My recommended resolution is therefore:

1. Remove ###ADMIN_EMAIL### from both Core default notification messages.
2. Retain its substitution temporarily for filtered legacy templates.
3. Deprecate the placeholder in developer documentation.
4. Add tests confirming that default notifications never disclose admin_email.
5. Consider a separate ###SUPPORT_URL### or configurable account-support contact in a future release.

This is a small, low-risk Core change that materially improves privacy defaults without removing any information required for the notification to function.

[vikingtechguy]

Privacy and security assessment - WordPress Core #57639

This is a valid privacy-by-default defect and a low-to-moderate information-disclosure weakness.

It is not equivalent to authentication bypass, privilege escalation, or direct account compromise. However, WordPress unnecessarily discloses the site’s Administration Email Address to any low-privilege user who can trigger the password-change or email-change notification. The current pull request correctly removes the address from the default templates, but its implementation should be adjusted to avoid breaking plugins that use the existing ###ADMIN_EMAIL### placeholder.

1. Nature of the disclosed information

The disclosed value is the site-level admin_email option, not necessarily the email address of a WordPress administrator account. WordPress documentation expressly distinguishes the Administration Email Address from user-account email addresses and explains that changing the setting does not change the email used to log in.

That distinction does not eliminate the privacy problem:

• The value may identify the website owner, an employee, a freelance developer, or an agency contact.
• It may be the same address used by an administrator account, even though WordPress does not require that.
• It may expose a technical or operational contact who is not responsible for customer support.
• Administrators are not clearly warned that this address will be disclosed to subscribers and customers.
• A role-based address such as admin@… may not be personal data, but WordPress cannot safely assume that all installations use a non-personal shared mailbox.

Under the GDPR, an email address is personal data where it relates to an identified or identifiable natural person. Disclosure by transmission is itself a form of processing.

2. Recipient and authorization problem

The recipient is not another administrator. It is the user whose password or email has been changed.

That user may be:

• A normal subscriber.
• A customer created through an e-commerce checkout.
• A member of an LMS, forum, newsletter, or membership site.
• A publicly registered account controlled by an unknown visitor.
• An automated account created specifically to retrieve the address.

The fact that the recipient is authenticated does not make the disclosure appropriate. Authentication proves control of the subscriber account; it does not establish a need or authorization to access administrative contact information.

The current WordPress implementation inserts get_option( 'admin_email' ) into both the password-change and email-change notification after applying the relevant email filters. The proposed PR removes the address from both default messages.

3. Necessity and proportionality

The notification has two legitimate purposes:

• Inform the user that an account attribute changed.
• Give the user a way to respond if the change was unauthorized.

The Administration Email Address is not necessary to accomplish either purpose.

The notification already identifies the site and includes the site URL. The user can return to the website, use its published support channel, initiate password recovery, or contact the business through its normal customer-facing process. The PR itself identifies ###SITENAME### and ###SITEURL### as sufficient context.

The disclosure therefore fails a straightforward necessity test:

Does the recipient need this particular administrative address to understand or respond to the account change?

In the ordinary case, the answer is no.

A support contact should also be selected intentionally for customer support. WordPress should not silently repurpose a technical administration address for a separate end-user support function.

4. GDPR assessment

Data minimisation - Article 5(1)(c)

Personal data must be adequate, relevant, and limited to what is necessary for the processing purpose. Including the administrative address where the site URL or a dedicated support channel is sufficient is difficult to justify under this principle.

Data protection by design and by default - Article 25

Controllers must implement safeguards that effectively apply principles such as data minimisation when selecting and configuring processing systems. A platform default that reveals an unrelated person’s email address to every account holder is inconsistent with a privacy-preserving default.

This does not necessarily mean that the WordPress open-source project is itself the GDPR controller. The website operator normally determines the purposes and means of the website’s processing. Nevertheless, WordPress Core should provide defaults that enable operators to comply rather than expose information unexpectedly.

Integrity and confidentiality - Articles 5(1)(f) and 32

Controllers must protect personal data against unauthorized or unlawful disclosure and apply security appropriate to the risk. The relevant question is not whether an email address is highly sensitive; it is whether the recipient was supposed to receive it and whether disclosure was necessary.

Potential personal data breach

Where the address identifies a natural person and the recipient was not authorized to receive it, an actual disclosure may meet the GDPR definition of a personal data breach: a security breach resulting in unauthorized disclosure of personal data.

That does not mean every notification requires reporting to a supervisory authority. For an isolated disclosure of one ordinary email address, the risk may often be sufficiently low that notification under Article 33 is not required. The site operator should nevertheless document the assessment. Notification becomes more plausible where the address:

• Reveals a protected or vulnerable individual.
• Is connected to a high-risk service.
• Is used for administrator authentication.
• Leads to targeted attacks or harassment.
• Is disclosed repeatedly or systematically.
• Reveals an otherwise confidential client–agency or employment relationship.

Article 33 requires notification only where the personal data breach is not unlikely to create risk, while Article 34 uses the higher threshold of likely high risk for direct communication to the affected person.

5. Security assessment

The conclusion that this is not a conventional high-impact security vulnerability is understandable. Knowledge of an email address alone does not grant access to WordPress.

However, it still creates a meaningful security-enabling disclosure.

Plausible attack chain

• The attacker creates or purchases a low-privilege account.
• The attacker changes that account’s password or email address.
• WordPress sends a notification containing the Administration Email Address.
• The attacker associates the address with the target website.

The address is used for:

• Administrator-account discovery.
• Password spraying or credential stuffing.
• Targeted phishing.
• Fake hosting, domain-renewal, or WordPress security notices.
• Impersonation of customers or staff.
• Spam, harassment, or data brokerage.

The process is repeated across multiple websites.

The security impact is conditional because the Administration Email Address may not be a valid administrator login and may be a public mailbox. That reduces severity but does not remove the unnecessary exposure.

6. Scale and likelihood

The important issue is not the disclosure of a single address in isolation. It is the combination of:

• A predictable core behavior.
• Public or customer-facing account registration.
• No administrative warning.
• A notification sent directly to an address controlled by the account holder.
• A repeatable flow that can be automated across websites.

Public registration is a standard WordPress capability, and self-registration creates users with the configured default role.

Plugins can make account creation available through checkout, membership, or subscription flows even where WordPress’s general “Anyone can register” option is disabled. The precise exposure therefore depends on each installation, its plugins, registration controls, email verification, CAPTCHA, and rate limiting.

7. Review of PR #12027

The PR is directionally correct. It currently:

• Removes the email address from both default notification strings.
• Changes the wording to “please contact the Site Administrator.”
• Removes the documented ###ADMIN_EMAIL### placeholder.
• Removes the str_replace() operation that populated the placeholder.
• Changes one PHP file with four additions and ten deletions.

Privacy outcome

Removing the address from the default templates is the correct default behavior. It eliminates unnecessary disclosure without weakening the confirmation that a change occurred.

Backward-compatibility concern

The PR currently removes not only the default use of ###ADMIN_EMAIL###, but also the placeholder substitution itself.

Because the password_change_email and email_change_email filters run before placeholder replacement, plugins or custom code may intentionally insert ###ADMIN_EMAIL### into a customized notification. After the proposed change, those installations could send the literal string ###ADMIN_EMAIL### to users.

That is an avoidable compatibility regression.

8. Recommended implementation

Preferred immediate change

• Remove ###ADMIN_EMAIL### from the two default email templates.
• Retain the existing placeholder substitution temporarily for backward compatibility.
• Mark the placeholder as deprecated in developer documentation.
• Add a _deprecated_argument()-style notice only where technically practical and non-disruptive.
• Remove the substitution in a later major release after a documented deprecation period.

This achieves privacy by default without unexpectedly breaking filtered templates.

Better long-term design

WordPress should distinguish between:

• Administration email: operational notifications sent to the site operator.
• Public support contact: the channel users should use for account assistance.

A future implementation could support:

• ###SUPPORT_URL###
• ###SUPPORT_EMAIL###
• A configurable account-support page.
• A filter returning the appropriate support contact.
• A fallback to ###SITEURL### without exposing an email address.

The support address should be optional and explicitly designated as user-facing.

Recommended default wording

If you did not make this change, please visit ###SITEURL### and contact the site through its official support channel.

This gives the user a concrete action while avoiding disclosure.

9. Tests that should accompany the change

The patch should include tests confirming that:

• Default password-change notifications do not contain admin_email.
• Default email-change notifications do not contain admin_email.
• The notifications continue to contain the site name, site URL, username, and relevant user email values.
• A low-privilege user can trigger the normal workflow without receiving administrative contact information.
• A filtered legacy template using ###ADMIN_EMAIL### continues to work during the deprecation period.
• Multisite behavior is tested where the relevant notification path applies.
• Translated templates do not reintroduce the removed address through obsolete translation strings.

10. Final severity position

The ticket’s major severity can be defended from a systemic privacy perspective, particularly because the behavior is a Core default and can affect customer-facing registrations.

From a traditional product-security perspective, I would classify it as:

CWE-200-style information exposure, low-to-medium security severity, with medium-to-high privacy significance.

The distinction matters:

• It should not be overstated as direct administrator-account compromise.
• It should not be dismissed merely because the field is called “Administration Email Address.”
• It is unnecessary exposure of a potentially personal and security-relevant identifier.
• The cost and functional risk of correcting the default are very low.

[ReneHermi]

Very well evaluated @vikingtechguy Thank you for taking the time.

[wildworks]

Thank you everyone for your input.

For me, the question is therefore less whether this is a security issue and more whether there is any benefit that justifies disclosing the Administration Email Address to low-privilege users.

The administrator email address was first introduced in r32430. We might find the reason for its introduction by looking at #32430.

[ReneHermi]

@tobiasbg just noticed you were involved. We need your master brain. Any chance to remember that and the reason? I know its a long time ago:-) https://core.trac.wordpress.org/ticket/32430#comment:25 Thanks

[jorbin]

Removing the site administration email address from this email make it much harder for users to contact the site administer at a time when they might need it the most. For this reason, I see ​https://github.com/WordPress/wordpress-develop/pull/12027 as a not starter.

Also, administrators are prompted every six months to make sure this is the correct address. ​https://make.wordpress.org/core/2019/10/17/wordpress-5-3-admin-email-verification-screen/. If a site has this set to the wrong value, perhaps what's needed is to increase the frequency or to adjust the wording on that screen.

If there are people that want to adjust this so that it goes to a specific support email, I think exploring adding a filter for that purpose here could make sense.

[joedolson]

I think that we should consider adding a separate field to hold an alternate email used for user-facing communications. If that field clearly indicates that this information will be disclosed to users in cases such as password change notifications, then that should resolve the privacy concerns: the admin will have to knowingly choose to set that value, so disclosing that email address will be expected and intentional.

A filter might be viable, but is less user-friendly, and fewer sites would be likely to implement it.

[ReneHermi]

Thanks for the thoughtful suggestions. I agree that it is important for users to have a reliable way to contact the site owner when they need assistance.

However, I do not think a separate user-facing email field would fully address the underlying concern. It would make the disclosure intentional, which is an improvement, but it would still require an email address to be exposed to low-privileged users.

Some site owners may deliberately use a contact form, help desk, support page, or another channel instead of publishing an email address. They should therefore be able to choose not to include any email address in these notifications.

This is also relevant because the disclosure can potentially be automated. As already described above, a bot could create subscriber-level accounts, trigger the relevant workflow, and collect valid email addresses across a large number of WordPress installations. I cannot say whether this is currently happening, but the existing behavior makes automated harvesting possible.

I therefore think the most flexible solution would be to make the user-facing contact information optional. Site owners could configure an email address, a support URL, or another contact method, while also having the option to disclose no direct contact information at all.

If WordPress continues to use the site administration email address by default, the configuration screen should at least state clearly that this address may be disclosed to registered users.

[jorbin]

Some site owners may deliberately use a contact form, help desk, support page, or another channel instead of publishing an email address. They should therefore be able to choose not to include any email address in these notifications.

If someone wants to suggest a contact form, help desk, carrier pigeon service, or any other contact method, the password_change_email and email_change_email filters are available for modifying the content of these emails.

I think that we should consider adding a separate field to hold an alternate email used for user-facing communications. If that field clearly indicates that this information will be disclosed to users in cases such as password change notifications, then that should resolve the privacy concerns: the admin will have to knowingly choose to set that value, so disclosing that email address will be expected and intentional.

Maybe what is actually needed is some better help text so it's clearer that this will be used publicly.

[masteradhoc]

@jorbin Fair point on the filters and on keeping a contact path available. My concern is only about the default value.

Looking at where admin_email is actually used core, it's almost always an admin-facing value: the To: of operational mail (comment moderation, new-user, auto-updates, recovery-mode, privacy requests, multisite signups), an identity check for "is this the admin," and the Settings/verification UI.

The password- and email-change notifications are the one place core injects it into content sent to another user. So this behavior is the outlier, not the norm — at least from what i see.

That's why better help text doesn't fully help here: the admin email address is being used for two completely different purpose - and IMO a purpose it isnt the best suited for.

So my +1 to @joedolson's separate user-facing contact field, with help text making clear it will be disclosed — that makes the exposure intentional and also seperates the two email adresses.

I'd add: doing so would also allow other plugins like E-Commerce, SMTP and others — many of which default to admin_email today — to adopt it for their purposes.

Moving this to 7.2 so we can finalize / agree on the possible solution and i'll update my PR.