It sounds like someone needs to contact the researcher, ROOTxDEAD aka Sohail Shaikh on sohailss799@gmail.com to get actionable details.

@sbassett: How to exactly interpret that you moved this task to "Watching" on the Security-Team workboard? Does it mean that the Security-Team will not contact the reporter, and that it's up to some undefined person with access to this task to maybe contact the reporter before things get disclosed on 2020-02-22?

I've sent an email (from my gmail) to the address provided:

Hi Sohail,

Thanks for reporting a vulnerability in the tools project. Please can you send the details to security@wikimedia.org, mentioning Phabricator task T239036?

Many thanks
Alex
Wikimedia volunteer

Please can someone on security@ copy their response to the task.

This should probably be also filed at https://bitbucket.org/magnusmanske/not-in-the-other-language/issues?status=new&status=open but I see zero options how to create a non-public ticket in that "Bitbucket" software... sigh.

[Adding the original reporter to the subscribers list]

In T239036#5701798, @Aklapper wrote:

@sbassett: How to exactly interpret that you moved this task to "Watching" on the Security-Team workboard? Does it mean that the Security-Team will not contact the reporter, and that it's up to some undefined person with access to this task to maybe contact the reporter before things get disclosed on 2020-02-22?

Correct. The Security-Team does not manage cloud/toolforge projects in any way, though we are certainly concerned with XSS vulnerabilities within quasi-production environments like this. Hence, tasks like this get placed within our watching column so that we can follow up on them if need be.

By the looks of things this is just a straightforward classic use of a request var directly in output, missing an htmlspecialchars call:

krenair@tools-sgebastion-07:~$ grep pagepile ~tools.not-in-the-other-language/public_html/index.php 
require_once ( '/data/project/pagepile/public_html/pagepile.php' ) ;
$pagepile = get_request ( 'pagepile' , '' ) ;
if ( $pagepile_enabeled ) {
	print "<tr><th>PagePile</th><td><input class='span4' type='text' name='pagepile' id='pagepile' value='$pagepile' placeholder='PagePile input ID' /> (optional; check out <a href='/pagepile' target='_blank'>PagePile</a>)</td></tr>" ;

other parameters this stuff can be passed in: lang1, lang2, proj1, proj2, starts_with, depth - and maybe others.

near the top:

$lang[1] = get_request ( 'lang1' , 'de' ) ;
$lang[2] = get_request ( 'lang2' , 'en' ) ;
$proj[1] = get_request ( 'proj1' , 'wiki' ) ;
$proj[2] = get_request ( 'proj2' , 'wiki' ) ;

$start = get_request ( 'start' , 0 ) ;
$limit = get_request ( 'limit' , 100 ) ;

$cat = get_request ( 'cat' , '' ) ;
$starts_with = get_request ( 'starts_with' , '' ) ;
$depth = get_request ( 'depth' , '9' ) ;
//$wdq = get_request ( 'wdq' , '' ) ;
$targets = get_request ( 'targets' , 'wikidata' ) ;
$format = get_request ( 'format' , 'html' ) ;
$pagepile = get_request ( 'pagepile' , '' ) ;

near the bottom:

	if ( $start > 0 ) $last_next .= "<a href='?lang1={$lang[1]}&proj1={$proj[1]}&lang2={$lang[2]}&proj2={$proj[2]}&cat=".escape_attribute($cat)."&depth=$depth&limit=$limit&starts_with=$starts_with&start=" . ($start-$limit) . "&targets=$targets&doit=1'>prev</a>" ;
	else if ( $cnt == $limit || $start > 0 ) $last_next .= "prev" ;
	if ( $cnt == $limit ) $last_next .= " | <a href='?lang1={$lang[1]}&proj1={$proj[1]}&lang2={$lang[2]}&proj2={$proj[2]}&cat=".escape_attribute($cat)."&depth=$depth&limit=$limit&starts_with=$starts_with&start=" . ($start+$limit) . "&targets=$targets&doit=1'>next</a>" ;

on it

This should get them all:

https://bitbucket.org/magnusmanske/not-in-the-other-language/commits/3c09e968d71ada6827dc90bd8221182eb86fe184

The above bitbucket patch looks ok, though htmlspecialchars() should probably be passed the [[ https://www.php.net/manual/en/function.htmlspecialchars.php | ENT_QUOTES flag ]] when sanitizing within the html attribute context.

Done.

Actually the patched is done OBB. If its resloved

@ROOTxDEAD - Ok, thanks.

Hello sir, The vulnerability is been patched by the OBB side too.

Thanks and Regards

@ROOTxDEAD - hmm, it's showing up as "on hold" (OBB-1022554) in various lists like this on OBB:

Actually It will be shown on hold until 31st December'19. After that it will have a patched written on it.

Hello Team,

I am still able to have a XSS vulnerability in the same website. Should I paste the details over here or make a new report. Waiting for your response

@sbassett @Reedy

In T239036#5715194, @ROOTxDEAD wrote:

Hello Team,

I am still able to have a XSS vulnerability in the same website. Should I paste the details over here or make a new report. Waiting for your response

@sbassett @Reedy

Did you clear your browser cache?

Yes Sir, I did clear out my cache and cookies as well. But its not on the URL which i mention in my report its new but on the same website.

In T239036#5715365, @ROOTxDEAD wrote:

Yes Sir, I did clear out my cache and cookies as well. But its not on the URL which i mention in my report its new but on the same website.

This is information you need to tell us, otherwise it's the same as going "there's a bug" and not telling us what the bug is.

It's clear from the commit that Magnus did fix the reported one, and the same problem on some other similar parameters too. But as always, it's not always 100% possible to guarantee all have been fixed

As this covers the same tool, but is a different XSS (and this report has been closed), please open a new task

I understand sir. I wasn't saying it here because of the report is publicly available.

@ROOTxDEAD - Generally speaking, it's a good idea to create a new security issue task if you've found a new vulnerability, even for a website or app for which you've previously found vulnerabilities. And you are correct in that you definitely should avoid disclosing new security issues on public tasks. Thanks.