https://office.wikimedia.org/wiki/Special:PasswordReset
Abuse the username field using {{:Homepage}} as the username.
Description
Description
Details
Details
- Risk Rating
- High
- Author Affiliation
- Wikimedia Communities
Related Changes in Gerrit:
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Reedy | T389313 Formally EOL MW 1.42 | |||
| Restricted Task | |||||
| Restricted Task | |||||
| Resolved | Release | jnuche | T392178 1.45.0-wmf.8 deployment blockers | ||
| Resolved | Security | Dylsss | T392746 CVE-2025-6590: Complete content leak of private wikis due to PasswordReset Wikitext injection in error message |
Event Timeline
Comment Actions
I assume wfEscapeWikiText prevents the template expansion here? I think this warrants an emergency security deployment, I just want to make sure this won't break anything else. A simpler, temporary approach might be to just change htmlform-user-not-valid to "This isn't a valid username." or similar which wouldn't break anything, just downgrade the usefulness of the message. Or just adding some more validation/stripping around https://gerrit.wikimedia.org/g/mediawiki/core/+/94e485551e3c6e7f76a6c1c5483f6c04c598bd80/includes/user/PasswordReset.php#217.
Comment Actions
A simpler, temporary approach might be to just change htmlform-user-not-valid to "This isn't a valid username." or similar which wouldn't break anything, just downgrade the usefulness of the message.
Off the top of my head, I don't think that is realistic. You would have to change it for every language (which would be a massive patch) otherwise you could just use uselang in the URL and use a different language I think?
Or just adding some more validation/stripping around https://gerrit.wikimedia.org/g/mediawiki/core/+/94e485551e3c6e7f76a6c1c5483f6c04c598bd80/includes/user/PasswordReset.php#217.
I don't think this code is ever reached because it hits the validation error on the username field within HTMLForm first.
Comment Actions
Ok, I've got the patch staged on deployment to roll out to wmf.25. I'm going to deploy now and keep an eye on logstash errors just in case, but your patch looks fine.
Comment Actions
Thanks for the quick report and patch.
Deployed to Wikimedia production. Logstash error rates fine. Officewiki seems fine now:
Thanks for the quick report and patch.
Comment Actions
For historical context, there was some discussion about potential longer term solutions at T160266 but nothing really happened.
Comment Actions
Does anyone have a problem if I deploy this patch to Miraheze too?
We have a fair number of private wikis and this isn't exactly a fun bug.
I only have access to the task via WMF NDA though so I'd like an explicit nod from someone.
The other alternative is disabling password resets on private wikis.
Comment Actions
No problems with you all deploying, but please be extremely careful to avoid public disclosure of the issue and the patch at this time.
Comment Actions
Thanks, I've gone ahead and deployed the patch and made it extremely clear that it can't be shared
Comment Actions
It's a bugfix even aside from the security implications. Usernames cannot contain templates, but can contain some forms of wikitext markup (e.g. '''Foo''' is a valid username) so they should always be escaped when used in wikitext messages. Unfortunately our localization framework makes it very easy to miss.
Comment Actions
I would say there is probably some argument for T297791, being able to decouple authn from the rest of mediawiki would prevent these types of vulnerabilities. This is the 3rd vulnerability where an attacker could dump all the content of our private wikis (T297322 and T297574 being the other two, which were exploitable since 2014), I don't think it can be guaranteed that another vulnerability like this won't come at some point in the future, code evolves and since private wiki configuration is not always taken into account it can be easy to create these types of vulnerabilities.
I am not sure what T160266 is about since I can't see it but it would nice to have some defense in depth against these types of issues.
Comment Actions
I am not sure there's much in common there. T297322 and T297574 are about missing permission checks. T297791/T391784 is about limiting the impact of SQL injection or remote code execution attacks (where the vulnerability is not specifically in the auth stack) by isolating authentication data. T160266 and this task is about using transclusion to exfiltrate private information. Fixing any one or two of those three groups wouldn't affect the rest.
Comment Actions
I am thinking that once authentication is standalone, you could put the entire MediaWiki stack behind authentication. The goal being to completely remove it from the attack surface, making any MediaWiki-level vulnerabilities irrelevant for private wikis.
Comment Actions
Change #1165071 had a related patch set uploaded (by Reedy; author: Dylsss):
[mediawiki/core@REL1_43] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165084 had a related patch set uploaded (by Reedy; author: Dylsss):
[mediawiki/core@REL1_39] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165097 had a related patch set uploaded (by Reedy; author: Dylsss):
[mediawiki/core@REL1_44] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165084 merged by jenkins-bot:
[mediawiki/core@REL1_39] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165112 had a related patch set uploaded (by Reedy; author: Dylsss):
[mediawiki/core@master] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165097 merged by jenkins-bot:
[mediawiki/core@REL1_44] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165131 had a related patch set uploaded (by Reedy; author: Dylsss):
[mediawiki/core@REL1_42] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165112 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165131 merged by jenkins-bot:
[mediawiki/core@REL1_42] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Change #1165071 merged by jenkins-bot:
[mediawiki/core@REL1_43] SECURITY: Escape usernames in HTMLUserTextField validation errors
Comment Actions
Patch 02-T392746.patch is currently failing to apply for the most recent code in the mainline branch of core. This is blocking MediaWiki release 1.45.0-wmf.8(T392178)
If the patch needs to be rebased
To unblock the release, a new version of the patch can be placed at the right location in the deployment server with the following Scap command:
REVISED_PATCH=<path_to_revised_patch> scap update-patch --message-body 'Rebase to solve merge conflicts with mainline code' /srv/patches/1.45.0-wmf.8/core/02-T392746.patch "$REVISED_PATCH"
If the patch has been made public
To unblock the release, the patch can be removed for the right version from the deployment server with the following Scap command:
scap remove-patch --message-body 'Remove patch already made public' /srv/patches/1.45.0-wmf.8/core/02-T392746.patch
(Note that if patches for the version don't exist yet, they will be created and the patch you specified removed)
Comment Actions
Patch had a double space that was removed when submitting, hence the conflict.
Removed from deploy1002