To Make this submission more clear.. i Tried installing the same version of the Demo Site which was 1.8 into my localhost to verify the issue in a good sense

when i did all the necessary steps for the installation the exploit doesn't work and i believe the issue was in my tables name and the process of verifying the table name

because one i reviewed the source code of the vulnerable endpoint it was pretty clear that its vulnerable to RXSS , in the below picture :

Code_Picture

in line 34 its getting my parameter which is template then in line 47 it prints it out with out any sanitization to my input..

so its clearly vulnerable but i cannot re procedure the issue from my localhost.

Could you please point out what are possible reasons that prevented the payloads from firing-up at my localhost while at the same time it works perfectly at yours.

Kind Regards, Rawi.

Thanks for raising this. We should be filtering this input, even though this is just a debugging tool. I will investigate.

Oh actually the point here is not to sanitize, as that can prevent your code as written from running properly. This is a debugging tool, not something you'd ever have running in a production system, so I'm not sure what the solution is.

Hello, i don't know what i'm supposed to say but will this issue be fixed and considered as a valid report? since i saw people were testing the same site and got a valid reports and the XSS is working just fine on the site mentioned.

Kind Regards, Rawi.

We'll fix it one way or another; just not sure how we can fix it without breaking the required functionality while testing. More soon.

Thanks again for testing this and raising the issue.

Hello, i have a question if the vulnerability got fixed and confirmed a CVE will be assigned ? if yes fill me in with the process

Kind Regards, Rawi.

@0xraw - we can assign a CVE for this report if you would like?

@maintainer - are you happy for us to assign and publish a CVE?

From my side , Yes i would like to have a CVE.

Kind Regards, Rawi.

It's reflected input in a rarely used debugging mode disabled by default, in a password protected application interface used only by trusted users. The reflection was allowed intentionally to facilitate debugging of display configuration.

We've only started filtering here now to resolve this on Huntr and avoid the impression that there's a truly exploitable issue.. The change makes this debugging option largely useless, but it's so rarely used we decided it doesn't really matter.

So does this need a CVE? I don't think so, but do what you believe is correct.

Given that @collectiveaccess does not believe a CVE is needed here, we will leave it, for now, 👍

We do require the maintainer's go-ahead for assigning and publishing a CVE...

Thanks to all. We really appreciate the work you do.