| Dreamy_Jazz | |
| Aug 29 2025, 5:09 PM |
| F66007771: T403289.updated.patch | |
| Sep 11 2025, 9:00 AM |
| F65943398: T403289.patch | |
| Sep 1 2025, 12:31 PM |
| F65931575: image.png | |
| Aug 29 2025, 5:09 PM |
| F65931579: image.png | |
| Aug 29 2025, 5:09 PM |
| F65931583: image.png | |
| Aug 29 2025, 5:09 PM |
| F65931585: image.png | |
| Aug 29 2025, 5:09 PM |
| F65931566: image.png | |
| Aug 29 2025, 5:09 PM |
| F65931564: image.png | |
| Aug 29 2025, 5:09 PM |
The CheckUser-UserInfoCard feature is vulnerable to message key XSS through several messages
| Message name(s) | Override using stored XSS | Resulting alert showing that JavaScript was run |
|---|---|---|
| All group-* messages |  |  |
| checkuser-userinfocard-groups |  |  |
| All global group messages |  |  |
| checkuser-userinfocard-global-groups |  |  |
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| SECURITY: Escape XSS vector in UserInfoCard | mediawiki/extensions/CheckUser | master | +4 -4 |
This wasn't findable using the normal x-xss language, because the script tags were not loaded if they are added to the DOM after the fact (AFAICS). I had to use <img src="" onerror="alert(1)"> to get the javascript to fire.
Perhaps we can consider updating the X-XSS language to use something like <img src="" onerror="alert('<message key>')"> instead, so that it's easier to detect message key XSS when the XSS occurs after page load.
+2. Works locally for me.
Given it's a US Holiday, the Security-Team might not be able to deploy this. Therefore, I'm going to see if I can deploy this myself.
Applied a version of the patch to wmf.16 that applies (it seemed just doing a three way merge fixed the issue).
Applied the original version of the patch to wmf.17.
Given this issue is minor (in terms of comparing to other possible security problems), I think we can skip QA on this.
Filed {T403407} to update the x-xss language to support detection of this type of i18n XSS
Patch 04-T403289.patch is currently failing to apply for the most recent code in the mainline branch of extensions/CheckUser. This is blocking MediaWiki release 1.45.0-wmf.19(T396380)
If the patch needs to be rebased
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' /srv/patches/next/extensions/CheckUser/04-T403289.patch "$REVISED_PATCH"
If the patch has been made public
The patch can be dropped in the deployment server with the following Scap command:
scap remove-patch --message-body 'Dropping patch already made public' /srv/patches/next/extensions/CheckUser/04-T403289.patch
I've updated the patch (however, I don't have deploy rights, so it's not placed on the server):
I'll update the patch on the deployment server, otherwise the bot will re-apply UBN and the parent task shortly
Unless I'm mistaken.. Both of these are only in master, not in a release branch rECHU1da1d9e72bb0: UserInfoCard: Display active global groups and rECHU280ff12ac104: UserInfoCard: Display user groups seemingly added them...
Change #1193256 had a related patch set uploaded (by Reedy; author: STran):
[mediawiki/extensions/CheckUser@master] SECURITY: Escape XSS vector in UserInfoCard
Change #1193256 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] SECURITY: Escape XSS vector in UserInfoCard
Yep, I can do that now. I think @Catrope's actions above were from our attempt to tidy up the Security-Team workboard yesterday, which didn't necessarily involve making private tasks public.