Page MenuHomePhabricator

CVE-2025-6593: "{{SITENAME}} registered email address has been changed" email sent to unverified email addresses
Closed, ResolvedPublicSecurity

Description

Found by @AAlhazwani-WMF:

  1. Ada creates an account, and provides Bob’s email during registration
    1. Bob receives the “Welcome” email
      1. Bob ignores the email
  2. Ada changes their (Bob’s) email in Special:Preferences
    1. Bob receives the “Wikipedia registered email address has been changed” email to their email address. This email includes Ada's IP address, username, and personal email [1]
    2. Ada receives the “Welcome” email to the their email address
  1. A should not happen. It discloses Ada's IP to Bob, and is probably needlessly scary for Bob the way it is phrased.

This bug was introduced 9 years ago (1.27.0) in User.php: Update 'setEmailWithConfirmation' for notification email for T31856: Email notification to old address when verified email address is changed or removed. Notice how the task talks about verified emil addresses, but the change does not introduce a check for that.

Event Timeline

I'm adding a bunch of people from my team, and also TSP for visibility. I'll upload a change shortly, this should thankfully be easy to fix. But I'll be off next week, so someone else has to shepard it to production.

This should work as expected. However, I'm not actually able to test it locally on my machine because I do not have emailing set up locally (yet). This should be kept in mind when reviewing:

sbassett subscribed.

This should work as expected. However, I'm not actually able to test it locally on my machine because I do not have emailing set up locally (yet). This should be kept in mind when reviewing:

CR+1, we should be able to get this deployed during this Monday's security window. Would be nice (but not essential IMO) to get another set of eyes on this for review before then.

This should work as expected. However, I'm not actually able to test it locally on my machine because I do not have emailing set up locally (yet). This should be kept in mind when reviewing:

CR+1, we should be able to get this deployed during this Monday's security window. Would be nice (but not essential IMO) to get another set of eyes on this for review before then.

Deployed

sbassett added a parent task: Restricted Task.
sbassett changed the task status from Open to In Progress.Jun 10 2025, 6:59 PM
sbassett triaged this task as Low priority.
sbassett moved this task from Security Patch To Deploy to Watching on the Security-Team board.

I'm not fully sure how to best QA this, but adding @Etonkovidova because it is in our QA column now.

I'm not fully sure how to best QA this, but adding @Etonkovidova because it is in our QA column now.

Thank you @Michael! The issue described in the task description has been fixed - checked on testwiki wmf.5, i.e. if an email address was not verified, and that yet-to-be-verified email address was changed again in the Preferences, no notification would be sent to the old unverified email.

Michael moved this task from QA to Blocked / Needs Work on the Growth-Team (Current Sprint) board.

Reopening, because I think this task still needs to be made public, and the change needs to be added to the GrowthExperiments master branch. That being said, I'm not sure what the process is in this case. Should we wait until the change is included in any security releases?

I'm not fully sure how to best QA this, but adding @Etonkovidova because it is in our QA column now.

Thank you @Michael! The issue described in the task description has been fixed - checked on testwiki wmf.5, i.e. if an email address was not verified, and that yet-to-be-verified email address was changed again in the Preferences, no notification would be sent to the old unverified email.

Thank you for verifying! 🙏

Reopening, because I think this task still needs to be made public, and the change needs to be added to the GrowthExperiments master branch. That being said, I'm not sure what the process is in this case. Should we wait until the change is included in any security releases?

Since it is a Core patch, it needs to be included in a security release before the task can be made public. I'm boldly moving this to Incoming on Security Team's workboard, as I'd expect the next process to be driven by that team (if there is anything Growth can help with, please let us know). For now, I can see this task is listed in the tracking task for the next security release (T389303), so hopefully that means it would be included when the time comes.

No longer something we work on actively (please let us know if the Growth-Team is expected to take an action here). Moving to Tracking.

Reopening, because I think this task still needs to be made public, and the change needs to be added to the GrowthExperiments master branch. That being said, I'm not sure what the process is in this case. Should we wait until the change is included in any security releases?

Since it is a Core patch, it needs to be included in a security release before the task can be made public. I'm boldly moving this to Incoming on Security Team's workboard, as I'd expect the next process to be driven by that team (if there is anything Growth can help with, please let us know). For now, I can see this task is listed in the tracking task for the next security release (T389303), so hopefully that means it would be included when the time comes.

Ah right, thanks! I had already forgotten again what this was about in detail.

Since it is a Core patch, it needs to be included in a security release before the task can be made public. I'm boldly moving this to Incoming on Security Team's workboard, as I'd expect the next process to be driven by that team (if there is anything Growth can help with, please let us know). For now, I can see this task is listed in the tracking task for the next security release (T389303), so hopefully that means it would be included when the time comes.

Yep, that should be coming out in a week or two, so if we can hold off until then, that would be ideal.

Reedy renamed this task from "{{SITENAME}} registered email address has been changed" email sent to unverified email addresses to CVE-2025-6593: "{{SITENAME}} registered email address has been changed" email sent to unverified email addresses.Jun 24 2025, 11:27 PM

Change #1165073 had a related patch set uploaded (by Reedy; author: Michael Große):

[mediawiki/core@REL1_43] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165073

Change #1165086 had a related patch set uploaded (by Reedy; author: Michael Große):

[mediawiki/core@REL1_39] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165086

Change #1165099 had a related patch set uploaded (by Reedy; author: Michael Große):

[mediawiki/core@REL1_44] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165099

Change #1165086 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165086

Change #1165114 had a related patch set uploaded (by Reedy; author: Michael Große):

[mediawiki/core@master] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165114

Change #1165133 had a related patch set uploaded (by Reedy; author: Michael Große):

[mediawiki/core@REL1_42] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165133

Change #1165099 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165099

Change #1165073 merged by jenkins-bot:

[mediawiki/core@REL1_43] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165073

Change #1165114 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165114

Change #1165133 merged by jenkins-bot:

[mediawiki/core@REL1_42] SECURITY: fix IP leak to unverified email

https://gerrit.wikimedia.org/r/1165133

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Medium.