⚓ T389009 CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication

⚓ T389009 CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication
Page Menu
Phabricator
Create Task
Maniphest
T389009
CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication
Closed, Resolved
Public
Security
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
Tgr
Authored By
Tgr
Mar 16 2025, 7:11 PM
2025-03-16 19:11:19 (UTC+0)
Tags
Security-Team
(Our Part Is Done)
Security
MediaWiki-Core-AuthManager
(Backlog)
MediaWiki-Platform-Team
(In progress (DO NOT USE))
SecTeam-Processed
(Completed)
Vuln-Authn/Session
(Tracked)
MW-1.44-release
(Blocker)
MW-1.43-release
(Blocker)
MW-1.42-release
(Blocker)
MW-1.39-release
(Blocker)
Referenced Files
F62340836: T389009.patch
Jun 15 2025, 9:02 PM
2025-06-15 21:02:08 (UTC+0)
Subscribers
Aklapper
DAlangi_WMF
gerritbot
sbassett
Tgr
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:
Subject
Repo
Branch
Lines +/-
SECURITY: Do not treat autocreation as login for reauthentication
mediawiki/core
master
+11
-7
SECURITY: Do not treat autocreation as login for reauthentication
mediawiki/core
REL1_42
+11
-7
SECURITY: Do not treat autocreation as login for reauthentication
mediawiki/core
REL1_43
+11
-7
SECURITY: Do not treat autocreation as login for reauthentication
mediawiki/core
REL1_44
+11
-7
SECURITY: Do not treat autocreation as login for reauthentication
mediawiki/core
REL1_39
+11
-7
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Status
Subtype
Assigned
Task
Resolved
Reedy
T389313
Formally EOL MW 1.42
Resolved
Reedy
T389302
Release MediaWiki 1.39.13/1.42.7/1.43.2
Restricted Task
Resolved
Security
Tgr
T389009
CVE-2025-6597: MediaWiki should not consider autocreation as login for the purposes of security reauthentication
Mentioned In
T389010: CVE-2025-6926: SUL3 local login should not count for security reauthentication
Mentioned Here
T394075: Investigate using different stores for different kinds of sessions
T389010: CVE-2025-6926: SUL3 local login should not count for security reauthentication
Event Timeline
Tgr
created this task.
Mar 16 2025, 7:11 PM
2025-03-16 19:11:19 (UTC+0)
Restricted Application
added a subscriber:
Aklapper
View Herald Transcript
Mar 16 2025, 7:11 PM
2025-03-16 19:11:21 (UTC+0)
Tgr
changed Author Affiliation from N/A to WMF Technology.
Mar 16 2025, 7:11 PM
2025-03-16 19:11:37 (UTC+0)
Tgr
added a project:
MediaWiki-Core-AuthManager
Restricted Application
added a project:
MediaWiki-Platform-Team
View Herald Transcript
Mar 16 2025, 7:11 PM
2025-03-16 19:11:39 (UTC+0)
Tgr
updated the task description.
(Show Details)
Mar 16 2025, 7:23 PM
2025-03-16 19:23:03 (UTC+0)
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
2025-03-17 15:22:34 (UTC+0)
sbassett
moved this task from
Incoming
to
Watching
on the
Security-Team
board.
Mar 17 2025, 4:41 PM
2025-03-17 16:41:06 (UTC+0)
sbassett
added a project:
SecTeam-Processed
sbassett
added a project:
Vuln-Authn/Session
Mar 18 2025, 8:22 PM
2025-03-18 20:22:39 (UTC+0)
sbassett
subscribed.
Mar 18 2025, 8:29 PM
2025-03-18 20:29:44 (UTC+0)
Comment Actions
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
2025-03-18 21:04:12 (UTC+0)
Comment Actions
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
2025-03-26 00:28:47 (UTC+0)
Comment Actions
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
2025-06-03 15:46:17 (UTC+0)
Tgr
added a project:
Patch-For-Review
Jun 15 2025, 9:02 PM
2025-06-15 21:02:08 (UTC+0)
Comment Actions
T389009.patch
3 KB
Tgr
claimed this task.
Jun 16 2025, 1:55 PM
2025-06-16 13:55:58 (UTC+0)
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
2025-06-16 14:02:05 (UTC+0)
Comment Actions
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
2025-06-16 21:08:31 (UTC+0)
Comment Actions
In
T389009#10916118
@Tgr
wrote:
T389009.patch
3 KB
LGTM, but would be nice to get another + review before we deploy this.
DAlangi_WMF
added a comment.
Edited
Jun 17 2025, 9:15 AM
2025-06-17 09:15:11 (UTC+0)
Comment Actions
In
T389009#10920603
@sbassett
wrote:
In
T389009#10916118
@Tgr
wrote:
T389009.patch
3 KB
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
2025-06-18 11:30:29 (UTC+0)
Comment Actions
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
2025-06-18 17:25:45 (UTC+0)
Comment Actions
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
2025-06-18 19:16:55 (UTC+0)
Comment Actions
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
2025-06-20 17:29:58 (UTC+0)
Comment Actions
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
2025-06-23 21:35:58 (UTC+0)
sbassett
triaged this task as
Medium
priority.
sbassett
moved this task from
Security Patch To Deploy
to
Watching
on the
Security-Team
board.
Comment Actions
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
2025-06-23 21:36:47 (UTC+0)
Reedy
added a subscriber:
GerritBot
Jun 24 2025, 8:11 PM
2025-06-24 20:11:59 (UTC+0)
Reedy
closed this task as
Resolved
Jun 24 2025, 8:28 PM
2025-06-24 20:28:17 (UTC+0)
Reedy
added projects:
MW-1.44-release
MW-1.43-release
MW-1.42-release
Jun 24 2025, 9:56 PM
2025-06-24 21:56:36 (UTC+0)
Reedy
added a project:
MW-1.39-release
Jun 24 2025, 9:58 PM
2025-06-24 21:58:38 (UTC+0)
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
2025-06-24 23:28:11 (UTC+0)
Reedy
edited subscribers, added:
gerritbot
; removed:
GerritBot
Jun 30 2025, 1:44 PM
2025-06-30 13:44:45 (UTC+0)
gerritbot
added a comment.
Jun 30 2025, 6:04 PM
2025-06-30 18:04:30 (UTC+0)
Comment Actions
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
gerritbot
added a project:
Patch-For-Review
Jun 30 2025, 6:04 PM
2025-06-30 18:04:33 (UTC+0)
gerritbot
added a comment.
Jun 30 2025, 6:20 PM
2025-06-30 18:20:20 (UTC+0)
Comment Actions
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
gerritbot
added a comment.
Jun 30 2025, 6:32 PM
2025-06-30 18:32:29 (UTC+0)
Comment Actions
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
gerritbot
added a comment.
Jun 30 2025, 7:04 PM
2025-06-30 19:04:12 (UTC+0)
Comment Actions
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
gerritbot
added a comment.
Jun 30 2025, 7:12 PM
2025-06-30 19:12:46 (UTC+0)
Comment Actions
Change #1165088
merged
by jenkins-bot:
[mediawiki/core@REL1_39] SECURITY: Do not treat autocreation as login for reauthentication
gerritbot
added a comment.
Jun 30 2025, 7:29 PM
2025-06-30 19:29:43 (UTC+0)
Comment Actions
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
gerritbot
added a comment.
Jun 30 2025, 7:32 PM
2025-06-30 19:32:29 (UTC+0)
Comment Actions
Change #1165101
merged
by jenkins-bot:
[mediawiki/core@REL1_44] SECURITY: Do not treat autocreation as login for reauthentication
gerritbot
added a comment.
Jun 30 2025, 7:57 PM
2025-06-30 19:57:49 (UTC+0)
Comment Actions
Change #1165075
merged
by jenkins-bot:
[mediawiki/core@REL1_43] SECURITY: Do not treat autocreation as login for reauthentication
gerritbot
added a comment.
Jun 30 2025, 7:58 PM
2025-06-30 19:58:03 (UTC+0)
Comment Actions
Change #1165116
merged
by jenkins-bot:
[mediawiki/core@master] SECURITY: Do not treat autocreation as login for reauthentication
gerritbot
added a comment.
Jun 30 2025, 8:29 PM
2025-06-30 20:29:02 (UTC+0)
Comment Actions
Change #1165135
merged
by jenkins-bot:
[mediawiki/core@REL1_42] SECURITY: Do not treat autocreation as login for reauthentication
sbassett
removed a project:
Patch-For-Review
Jul 8 2025, 8:35 PM
2025-07-08 20:35:47 (UTC+0)
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
2025-07-08 21:14:44 (UTC+0)
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
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits