**Steps to reproduce**=== Summary
# Have a demo wiki with ext:UploadWizard & ext:TitleBlacklist both loaded.The UploadWizard extension is vulnerable to i18n/system-message stored XSS attacks via at least the following system messages (and, from looking at the code, probably more):
# //As an admin (i.e., a user with `editinterface` rights, but **not** `editsitejs` rights)://- `mwe-upwiz-blacklisted-details-titleblacklist-custom-filename-text`
## Add the following rule at `MediaWiki:Titleblacklist` (the important part for these reproduction steps is the `errmsg` being '`titleblacklist-custom-filename`'): - `mwe-upwiz-too-many-files-text`
*** `.*generic - `mwe-upwiz-filename.* <errmsg=titleblacklist-custom-filename>`e-too-large-text`
## Create the page `MediaWiki: - `mwe-upwiz-blacklisted-details-titleblacklist-custom-filename-text` with the given content:license-external-invalid`
*** `<script>alert("XSS: - `mwe-upwiz-blacklisted-details-titleblacklist-custom-filename-text");</script>`-other-v2`
# //As an unprivileged/regular user:// - `mwe-upwiz-submitting-details`
- `mwe-upwiz-published`
=== Prerequisites to reproduce
- Have a demo wiki with ext:UploadWizard (and, to reproduce vuln **[1]**, ext:TitleBlacklist) loaded.
- //As an admin (i.e., a user with the `editinterface` rights, but **not** the `editsitejs` right)://
-- For each of the message keys above, create the page `MediaWiki:<message-key>` with the content `<script>alert("XSS: <message-key>");</script>`.
(Alternatively, add `$wgUseXssLanguage = true;` to your demo wiki's `LocalSettings.php`, & access pages using `?uselang=x-xss`.)
=== Stored system-message XSS via...
==== [1] ...the popup that appears after clicking the 'view examples' link in a title-blacklist error message
# //As an admin://
## Add the following rule at `MediaWiki:Titleblacklist` (the important part for these reproduction steps is the `errmsg` being `titleblacklist-custom-filename`):
*** `.*generic-filename.* <errmsg=titleblacklist-custom-filename>`
# //As an unprivileged/regular user (i.e., someone without the `tboverride` right)://
## Navigate to `Special:UploadWizard`.
## Select a file to upload.
## On the 'Release rights' step, select any values that allow you to get to the next stage.
## Under 'Title', enter "generic-filename".
## Click on the "view examples" link in the error message that appears:
{F66747894 width=650}{F66754941 width=350}
//Note:// The possibility of an XSS vulnerability here jumped out to me when I was looking at UploadWizard's `en.json` & noticed that the [[https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/master/i18n/en.json#L204|default 'mwe-upwiz-blacklisted-details-titleblacklist-custom-filename-text' message]] contained an `<a>` tag, given that - to my knowledge - HTML anchor tags don't work in regular wikitext.
==== [2] ...the popup that appears when attempting to upload too many files at once
# For ease of reproducibility (ie., to avoid having to upload 50 items at once in order to reproduce this vuln), add the following line to your demo wiki's `LocalSettings.php`:
** `$wgUploadWizardConfig['maxUploads'] = 2;`
# Navigate to `Special:UploadWizard`.
# Either:
## Click on "Select media files to share", & select more than two images; or
## Drag-and-drop more than two image files onto the part of the page labelled "Drop files here".
**What happens?**==== [3] ...the popup that appears when attempting to upload a file that's above the max upload size
You get XSSed -- a JavaScript alertbox appears# For ease of reproducibility (ie., to avoid having to upload a [[https://gerrit.wikimedia.org/g/mediawiki/core/+/bc62eb069cf90abe6abaddfbecf6275328535790/includes/MainConfigSchema.php#1486|100MB]] file in order to reproduce this vuln), indicating that - through overriding the `mwe-upwiz-blacklisted-details-titleblacklist-custom-filename-text` message - the admin account with `editinterface` rights (but //without// `editsitejs` rights) has been able to inject JavaScript to be executed by the end-user's browser.add the following line to your demo wiki's `LocalSettings.php`:
|{F66748025 width=450}|** `$wgMaxUploadSize = 1024 * 1024;` [1MB]
# Navigate to `Special:UploadWizard`.
# Select/Drag-and-drop a file to upload that's over 1MB in size.
**What should have happened?**==== [4] ...the popup that appears when attempting to import an image from Flickr that has an incompatible license
# Add the following lines (adapted from <https://www.mediawiki.org/wiki/Extension:UploadWizard#Enabling_Flickr_uploads>) to your demo wiki's `LocalSettings.php`, in order to allow the UploadWizard Flickr integration to work:
** `$wgAllowCopyUploads = true;`
** `$wgGroupPermissions['user']['upload_by_url'] = true;`
** `$wgCopyUploadsDomains = ['*.flickr.com', '*.staticflickr.com'];`
** `$wgUploadWizardConfig['flickrApiKey'] = 'e9d8174a79c782745289969a45d350e8';` [I'm using the (public) [[https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/d4bb72a6b285c137254fcfd591b6a4ae53d5cc96/wmf-config/CommonSettings.php#2805|Wikimedia Flickr API key]] to repro this, as Flickr is [[https://www.flickrhelp.com/hc/en-us/articles/4404070036884-Flickr-API|currently restricting the ability to create API keys to 'Pro' subscribers]], and this key seems to work from my localhost demo wiki.]
# Navigate to `Special:UploadWizard`.
# Select 'Share images from Flickr'.
No XSS (i.e# Paste in the URL of a photo on Flickr that has a license marked as `'invalid'` in [[https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/bcc95a82a81fa98af6502708c29673b64bd66d63/resources/mw.FlickrChecker.js#L47-L75|this array]] (e.g., <https://flickr.com/photos/alexbalan/3717404325>).
# Click the 'Get from Flickr' button.
==== [5] ...the 'Any other information you want to include' field-label
# Navigate to `Special:UploadWizard`
# Select a file to upload.
# On the 'Release rights' step, select any values that allow you to get to the next stage, and click 'Next'. the alertbox shouldn't've appeared).(The XSS occurs immediately after reaching the next stage - 'Describe'.)
**Software versions**==== [6] [7] ...the status-text that indicates the status of an upload in progress
# Follow the steps in **[5]** above.
# On the 'Describe' step, enter any value in the 'Description' & 'Date' fields.
# Click the 'Publish files' button. (The two XSSes here occur in quick succession, presumably depending on how long it takes the wiki to publish the file(s) after the information about them has been submitted.)
=== What happens?
In each case, you get XSSed: a JavaScript alertbox appears, indicating that - through overriding these system messages - the admin account with `editinterface` rights (but //without// `editsitejs` rights) has been able to inject JavaScript to be executed by the end-user's browser.
|**[1]**|**[2]**|**[3]**|**[4]**|**[5]**|**[6]**|**[7]**|
|{F66748025 width=250}|{F66754303 width=400}|{F66754300 width=400}|{F66754702 width=400}|{F66754835 width=400}|{F66754840 width=400}|{F66754908 width=400}|
=== What should have happened?
No XSSes (i.e. the alertboxes shouldn't've appeared).
=== Software versions
mw/core @ ce36ccce81
mw/exts/UploadWizard @ 2b5c27014c
mw/exts/TitleBlacklist @ 7efae546ae
**Other information/Notes**
=== Other information/Notes
- Someone else should verify these; but as far as I can currently see:
-- Vuln **[1]** looks like it was introduced in <https://gerrit.wikimedia.org/r/1043017> (i.e., `REL1_43` onwards) for {T366323}.
-- Vulns **[2]** & **[3]** look like they were introduced in <https://gerrit.wikimedia.org/r/1010228> (i.e., `REL1_42` onwards) for {T355715}. I'm not certain, but I believe an underlying cause of these two may have been the change to [[https://gerrit.wikimedia.org/r/1010228/2/resources/mw.errorDialog.js#15|mw.errorDialog.js#15]] (which wrapped the `errorMessage` variable within a `new OO.ui.HtmlSnippet`) without there also being changes to that function's callers (to escape system messages where necessary).
-- `[origin analysis of vulns [4] & onwards to hopefully be added within the next few days --a smart kitten, 2025-10-16]`
- The possibility of an XSS vulnerability here jumped out to me when I was looking at UploadWizard's `en.json` & noticed that the [[https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/master/i18n/en.json#L204|default 'mwe-upwiz-blacklisted-details-titleblacklist-custom-filename-text' message]] contained an `<a>` tag, given that - to my knowledge - HTML anchor tags don't work in regular wikitextccing @cparle @matthiasmullie @mfossati as authors/reviewers of those patches FYI.
- ccing @cparle & @matthiasmullie as - at a first glance - it looks like this vuln may have been introduced in <https://gerrit.wikimedia.org/r/1043017> for {T366323}. (I might be missing somethingI'm not sure if I've found all of the system message XSSes in UploadWizard here or not. Given what I've found here (and given [[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UploadWizard/+/1189182|this i18n-XSS patch from only a month ago]] for T402095), though `:)`)it might be worth doing a proper audit to check if there are any more of them within the extension.