Page MenuHomePhabricator
Create Task
Maniphest T389009

CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication
Closed, ResolvedPublicSecurity
Actions

Description

Certain pages must be used shortly after login; if that's not the case, the user is asked to reauthenticate. (See $wgReauthenticateTime.) This is to prevent an attacker from stealing a session cookie and then e.g. changing the password.

Since some of the "login" logic is shared between login and autocreation (specifically they both call AuthManager::setSessionDataForUser(), which is the method that sets the AuthManager:lastAuthTimestamp field in session data, which will be used for reauthentication checks), AuthManager ends up considering autocreation the same way as login. This means an attacker who got hold of a CentralAuth session cookie (valid on any wiki) can just visit a wiki where the user has no local account yet, get an account autocreated, and then change credentials or perform other sensitive operations.

See also T389010: CVE-2025-6926: SUL3 local login should not count for security reauthentication.

Details

Risk Rating
Medium
Author Affiliation
WMF Technology
Related Changes in Gerrit:
SubjectRepoBranchLines +/-
SECURITY: Do not treat autocreation as login for reauthenticationmediawiki/coremaster+11 -7
SECURITY: Do not treat autocreation as login for reauthenticationmediawiki/coreREL1_42+11 -7
SECURITY: Do not treat autocreation as login for reauthenticationmediawiki/coreREL1_43+11 -7
SECURITY: Do not treat autocreation as login for reauthenticationmediawiki/coreREL1_44+11 -7
SECURITY: Do not treat autocreation as login for reauthenticationmediawiki/coreREL1_39+11 -7
Customize query in gerrit

Related Objects
Search...

StatusSubtypeAssignedTask
 ResolvedReedyT389313 Formally EOL MW 1.42
Restricted Task
Restricted Task
 ResolvedSecurityTgrT389009 CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication

Event Timeline

Tgr created this task.Mar 16 2025, 7:11 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 16 2025, 7:11 PM
Tgr changed Author Affiliation from N/A to WMF Technology.Mar 16 2025, 7:11 PM
Tgr added a project: MediaWiki-Core-AuthManager.
Restricted Application added a project: MediaWiki-Platform-Team. · View Herald TranscriptMar 16 2025, 7:11 PM
Tgr updated the task description. (Show Details)Mar 16 2025, 7:23 PM
Tgr mentioned this in T389010: CVE-2025-6926: SUL3 local login should not count for security reauthentication.
• larissagaulia moved this task from Inbox, needs triage to Needs refinement on the MediaWiki-Platform-Team board.Mar 17 2025, 3:22 PM
sbassett moved this task from Incoming to Watching on the Security-Team board.Mar 17 2025, 4:41 PM
sbassett added a project: SecTeam-Processed.
sbassett added a project: Vuln-Authn/Session.Mar 18 2025, 8:22 PM
sbassett subscribed.Mar 18 2025, 8:29 PM

Would the fix here be to just force re-auth within securitySensitiveOperationStatus() as the default behavior? e.g. don't check AuthManager:lastAuthId and AuthManager:lastAuthTimestamp?

Tgr added a comment.Mar 18 2025, 9:04 PM

That would lead to an infinite reauth loop I think. We just need to be more judicious of when we set lastAuthTimestamp. Should be an easy fix, will do it soon.

sbassett added a comment.Mar 26 2025, 12:28 AM
In T389009#10648864, @Tgr wrote:

That would lead to an infinite reauth loop I think.

Yeah, I was implying there'd be some other state-based check here, just something that didn't rely upon last auth data. Anyhow, if you've got a fix in mind, great.

Krinkle added a subscriber: DAlangi_WMF.Jun 3 2025, 3:46 PM
Tgr added a project: Patch-For-Review.Jun 15 2025, 9:02 PM

T389009.patch3 KBDownload

Tgr claimed this task.Jun 16 2025, 1:55 PM
Tgr moved this task from Needs refinement to In progress (DO NOT USE) on the MediaWiki-Platform-Team board.
Tgr added a comment.Jun 16 2025, 2:02 PM
In T389009#10676665, @sbassett wrote:

Yeah, I was implying there'd be some other state-based check here, just something that didn't rely upon last auth data.

I think the nice way to do it would be to

  • move the method from AuthManager to the session provider, so some session providers can decide to always or never support it, or force an OAuth token rerfesh if the access token is old, or whatever
  • CookieSessionProvider would mostly keep doing what it does, CentralAuthSessionProvider would do the same but in the central session
  • tell the session provider why the session is being changed to an authenticated one (probably on top of T394075: Investigate using different stores for different kinds of sessions) so it can differentiate between login / autologin / whatever

Not something to try in a security patch though.

sbassett moved this task from Watching to Security Patch To Deploy on the Security-Team board.Jun 16 2025, 9:08 PM
In T389009#10916118, @Tgr wrote:

T389009.patch3 KBDownload

LGTM, but would be nice to get another + review before we deploy this.

DAlangi_WMF added a comment.EditedJun 17 2025, 9:15 AM
In T389009#10920603, @sbassett wrote:
In T389009#10916118, @Tgr wrote:

T389009.patch3 KBDownload

LGTM, but would be nice to get another + review before we deploy this.

Spent some time today testing this patch locally, @Tgr, let me know if my observation matches what you expect.

Before this patch, when an account is auto-created on a wiki [which previously didn't have that account], visiting the Special:ChangePassword page would just present the user with an option to change their password [the password change form], which is what we're trying to fix here.

With this patch applied, I did the following.

  • Set $wgReauthenticateTime = [ 'default' => 30 ]; [30 seconds]
  • Created an account on the shared domain say User:Foobar
  • Logout and login [on the shared domain] to spend some time for 30 sec to elapse.
  • Then go to a local wiki [say enwiki], clicked on the "Login" link. This will auto-create the central user on that wiki [which didn't exist before] then logs the user in.
  • I visit the Special:Preferences page on the local wiki and click on "Change password" button
  • I get redirected to the shared domain with a login form to re-authenticate.

I left a piece, also, I increased $wgReauthenticateTime = [ 'default' => 3600 ]; and I still had the same effect with this patch applied. By same effect, I mean I still had to re-authenticate form presented [login again] even though the time hasn't elapsed because the auto-creation wasn't considered for re-authentication.

Let me know if I'm missing something but I think it works as expected.

Tgr added a comment.Jun 18 2025, 11:30 AM

I think that's correct, although with the SUL3 setup it's tricky because the similar but distinct T389010: CVE-2025-6926: SUL3 local login should not count for security reauthentication might interfere. What I did is use cookie-based autocreation (just visit a local wiki with no local account, with the centralauth_* cookies set) and use a special page that doesn't redirect to the central domain (e.g. Special:BotPasswords).

sbassett removed a project: Patch-For-Review.Jun 18 2025, 5:25 PM

Happy to deploy this Friday morning (would normally due Thursday after the late backport but it's a US holiday) and keep an eye on it, once everything's on 1.45.0-wmf.6. I didn't get the sense that it was more urgent than that?

Tgr added a comment.Jun 18 2025, 7:16 PM

Well, I took two months two fix it, so I can't exactly complain about urgency...
In terms of impact, the SUL3 task is the bigger one I think. It's not hard to hit that one accidentally; to exploit this one, you have to know what you are doing.

sbassett added a comment.Jun 20 2025, 5:29 PM
In T389009#10929494, @Tgr wrote:

Well, I took two months two fix it, so I can't exactly complain about urgency...
In terms of impact, the SUL3 task is the bigger one I think. It's not hard to hit that one accidentally; to exploit this one, you have to know what you are doing.

Yeah, maybe let's plan to get this one and the ones from T389010 deployed during this coming Monday's security window.

sbassett changed the task status from Open to In Progress.Jun 23 2025, 9:35 PM
sbassett triaged this task as Medium priority.
sbassett moved this task from Security Patch To Deploy to Watching on the Security-Team board.

Deployed the above patch during today's security window (2025-06-23). I assume we want to track this for the core release.

sbassett added a parent task: Restricted Task.Jun 23 2025, 9:36 PM
Reedy added a subscriber: GerritBot.Jun 24 2025, 8:11 PM
Reedy closed this task as Resolved.Jun 24 2025, 8:28 PM
Reedy added projects: MW-1.44-release, MW-1.43-release, MW-1.42-release.Jun 24 2025, 9:56 PM
Reedy added a project: MW-1.39-release.Jun 24 2025, 9:58 PM
Reedy renamed this task from MediaWiki should not consider autocreation as login for the purposes of security reauthentication to CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication.Jun 24 2025, 11:28 PM
Reedy edited subscribers, added: gerritbot; removed: GerritBot.Jun 30 2025, 1:44 PM
gerritbot added a comment.Jun 30 2025, 6:04 PM

Change #1165075 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_43] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a project: Patch-For-Review.Jun 30 2025, 6:04 PM
gerritbot added a comment.Jun 30 2025, 6:20 PM

Change #1165088 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_39] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 6:32 PM

Change #1165101 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_44] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 7:04 PM

Change #1165116 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@master] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 7:12 PM

Change #1165088 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 7:29 PM

Change #1165135 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/core@REL1_42] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 7:32 PM

Change #1165101 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 7:57 PM

Change #1165075 merged by jenkins-bot:

[mediawiki/core@REL1_43] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 7:58 PM

Change #1165116 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Do not treat autocreation as login for reauthentication

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

gerritbot added a comment.Jun 30 2025, 8:29 PM

Change #1165135 merged by jenkins-bot:

[mediawiki/core@REL1_42] SECURITY: Do not treat autocreation as login for reauthentication

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

sbassett removed a project: Patch-For-Review.Jul 8 2025, 8:35 PM
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.
sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.Jul 8 2025, 9:14 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits