Jan 6 2020
I see my name is on the list. I unfortunately haven't been as active as a volunteer for a while, but for some context, part of why I was originally given access here is related to my role at Fandom, providing early access to security releases for Fandom and Gamepedia so we can prepare and protect our user base quickly. I still use it for this purpose for each security release, and as we plan to launch a bug bounty for our wikis on Fandom and Gamepedia in the coming year which will include core MediaWiki (once we're on a newer MW version), I'd love to discuss collaborating more closely on it. :)
May 2 2018
@Bawolff this is great. One thought I had from looking at https://www.mediawiki.org/wiki/Reporting_security_bugs and https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Thanks is that they both only mention credit for vulnerabilities found in MediaWiki core or a bundled extension. I feel one missing part will be crediting those who report security issues in Wikimedia-deployed extension. These may not make sense to credit in the MW core CREDITS file as the issues weren't part of the code distributed in the tarballs, but it does seem worthwhile to also find a nice place to credit those who reported security issues that affected Wikimedia wikis such as through a deployed extension, as they're helping keep Wikimedia projects secure even if it's not an issue that is part of core or a bundled extension. What do you think?
Apr 5 2017
Thanks, @Reedy! Found one more issue in the patches for MW 1.23. In the patch for T108138, the calls to getUserPermissionsErrorsInternal are passing the undefined variable $rigor as MW 1.23 is still using the boolean $doExpensiveQueries instead. The call to Title::userCan should also probably use a boolean true instead of 'secure' for consistency.
Apr 4 2017
For the MW 1.23 patch for T108138, it looks like $user is undefined in the Title::userCan call as well, as it currently repeatedly calls $this->getUser() rather than storing it in a $user variable.
I believe the patch for MW 1.23 related to T48143 will break as it adds the call to parser::normalizeLinkUrl but the Parser::normalizeLinkUrl method does not exist in MW 1.23, as it is still using Parser::replaceUnusualEscapes instead.
Mar 20 2017
@dpatrick Looks like https://gerrit.wikimedia.org/r/#/c/319055/ was merged in February and is now live, so I think this can be closed and made public once it's announced as part of the fixes released in T134863?
Jan 18 2017
@dpatrick looks like the PoC https://www.mediawiki.org/wiki/Special:GlobalGroupPermissions?wpGroup=%3Cscript%3Ealert%28document.domain%29%3C/script%3E works again, did the patch get reverted?
May 10 2016
Here's a quick patch to fix the issue:
Apr 25 2016
I dunno, I think we could just set rel="noopener" on external links and document this.
That sounds like a reasonable response to me.
Just something to keep in mind, rel="noopener" only works on Chrome and Opera, and does not work in Firefox, Safari, IE, and Edge.
Dec 17 2015
The backport patches for this to MW 1.23 and 1.24 should also use hash_equals in the check in the return of the method as well, i.e. here: https://github.com/wikimedia/mediawiki/blob/REL1_24/includes/User.php#L3939 and https://github.com/wikimedia/mediawiki/blob/REL1_23/includes/User.php#L3814. And they should both also probably have the same done for User::matchEditTokenNoSuffix.
The patches for T119309 in MW 1.23 and 1.24 should use hash_equals in the check in the return of the method as well, i.e. here: https://github.com/wikimedia/mediawiki/blob/REL1_24/includes/User.php#L3939 and https://github.com/wikimedia/mediawiki/blob/REL1_23/includes/User.php#L3814. And they should both also probably have the same done for User::matchEditTokenNoSuffix.
Oct 23 2015
Oct 16 2015
Sep 3 2015
Sep 1 2015
Quick patch to URL encode the title:
Jul 14 2015
Jun 26 2015
It looks like the patches were pushed to Gerrit and merged: https://gerrit.wikimedia.org/r/220839
Jun 23 2015
There are some more vulnerable parameters not covered by that patch: