Page MenuHomeMiraheze

Numerous confirmed XSS in ManageWiki
Closed, ResolvedPublic




Event Timeline

/extensions and /settings confirmed busted. /core doesn't give any alerts.

On /extensions, the alerts involve the managewiki-conflicts and managewiki-requires messages. where required and conflicting extensions are added to the form.

generated HTML, tidified.

<span class='oo-ui-fieldLayout-header'>
											<label for='ooui-php-30' class='oo-ui-labelElement-label'>&lt;script&gt;alert('managewiki-extension-name')&lt;/script&gt;"&gt;&lt;script&gt;alert('managewiki-extension-name')&lt;/script&gt;&lt;x y="(: <a class="external free" href=""></a>, &lt;script&gt;alert('cargo-extensionname')&lt;/script&gt;"&gt;&lt;script&gt;alert('cargo-extensionname')&lt;/script&gt;&lt;x y="()) </label>
											<label for='ooui-php-30' class='oo-ui-inline-help oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelElement oo-ui-labelWidget'>
												</script>"> <script>
												<x y="() semanticmediawiki
													<x y="(): Permissions - managewiki-restricted
														<br/> &lt;script&gt;alert('cargo-desc')&lt;/script&gt;" &gt;&lt;script&gt;alert('cargo-desc')&lt;/script&gt;&lt;x y="() 
														<br/>Stewards: it is recommended to not enable this extension on wikis with more than 
														<b>50,000</b> pages. This includes all pages, 
														<b>not</b> only content pages. Please use discretion.

so it seems to be in our usage of labels for the extensions form. I would like to test some patches privately on mirabeta, not sure how possible that would be.

Looking at, that is indeed supposed to be the "label" (it is not actually a label HTML element)

Attaching my patch for the extensions subpage now, I think this should fix that at least.

Assuming that patch fixes that for the extensions subpage, I can more or less make a theory (the form descriptor is passed around through so many functions that it is hard to keep track).

See how we use HTML for the description of extensions in ManageWikiExtensions.php (at LS.php) ? That means raw mode is somewhere set for that element in the form descriptor. See this HTML from

<label for="ooui-php-367" class="oo-ui-inline-help oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelElement oo-ui-labelWidget">Requires: Permissions - managewiki-restricted <br> Making your wiki more accessible - for machines <i>and</i> humans ( <a rel="nofollow" class="external text" href="">online documentation</a>) <br>
	<br> Permanently "experimental" and may be removed with little to no prior notice. WARNING: Disabling this extension after it's already been enabled will clear all SemanticMediaWiki database tables as well. <br>
	<b>Note: <a href="" target="_blank">Stewards</a>, please ensure that a member of the <a href="" target="_blank">Site Reliability Engineering</a> team is available and not mobile in order to run <a href="" target="_blank">a series of commands</a> on mwtask181 after enabling this. </b>

Those interface messages are used in the label element! Since raw mode is set for this entry on the formdescriptor, and those i18n messages are included the content of this element, there we have our XSS vector.

Something very similar must be going on on the other subpages.

I think I know what is causing this, so I'll try to get this fixed tomorrow at the latest.

Also, just to clarify my previous message.

IN the case of the extensions subpage, the vulnerability is that unescaped interface messages are being included in the help element of formdescriptor elements that have raw mode enabled.

New patch superseding the other patch. Only thing missing is I think the XSS on the permissions subpage, which seems a bit more complex.

Confirmed in Special:ManageWikiDefaultPermissions also

Yeah there's no way my last patch is right.

Thinking it must be from User::getRightDescription at the help key on the formdescriptor (which returns an interface message in ->text() mode), but then why does the alert pop twice with the same message? Or why does it pop at all? Best way to answer these questions is to merge some of these patches and test at mirabeta, which I'll do tomorrow since it is getting late here (UTC+1).

DO NOT MERGE my permissions XSS patch, but if anyone wants to test while I'm one, feel free to merge F2713428 and test.

I think what we should do is allow raw messages in MWS to be defined in config, and if it is, add them to $wgRawHtmlMessages, which prevents true security vulnerabilities by not only require editinterface, but also the same rights to editsitecss/js which would mean absolutely no difference from Common.js, etc...

This comment was removed by OrangeStar.

@Universal_Omega You mean making the help messages in MWS.php, like, interface messages? Because if so that looks like a complex rewrite. Also, all of those messages as well as managewiki-requires, managewiki-conflicts, and all the various right-* messages from core that are also XSS vectors in the permissions subpage must be added to wgRawHtmlMessages. We can do that, if you want, but after this.

Adding all the messages that has an issue to wgRawHtmlMessages is a mitigation to this but it might be to complex with to many at this time.

I think I'm good to go to squash all of these and make a PR.

Please do a security merge not a normal PR, should be fairly easy to do security with GitHub

security advisory draft ( is ready, all the changes have been made to the private fork if I'm not missing anything. Waiting for an SRE to review everything and give me the okay (or merge the changes themselves) so that they can double check my work and we can deploy the fixes to production as soon as possible.

I'm going to create a new draft GHSA, GitHub got bugged and thinks there are no changes waiting to be merged from the private fork sigh.

I've set confidentiality to high, since you could read private ManageWiki settings (for example, the Discord webhook for wikis using that extension) with XSS on those pages.

I just realized it will be better to just leave deploying the fixes to someone with access to mwtask181. Removing myself as assignee as my part is done, I think.

Security advisory is now published. This task should be good for opening to the public now. For those reading this, we actually found some more XSS vectors when deploying the fixes to prod, so we actually have multiple patches in the GHSA for this one.

Universal_Omega changed the visibility from "Custom Policy" to "Public (No Login Required)".Feb 10 2024, 17:19