I also try my payloads in the photo description & saw the same vulnerability.I dont know about your bounty or swag.I hope you fixed your site soon.

My screenshot:

This doesn't appear to be an actual vulnerability, unless the alert is creating an alert window in your browser - the use of font tags to alter display is a supported feature

Please recheck it.Because i use my other payloads using the word alert.But it did not display like that!

Looking at https://commons.wikimedia.org/wiki/File:Dp_test_xss.jpg I don't see an XSS either.

I see some interesting truncation of fields by MW... But without knowing exactly what you put in where, it's hard to know what transformation happened

Hello Reedy,Please Check Caption no: 05

Then go to the Summary part & check the Description. Then you found something.

In T269130#6659724, @Pealhasan.x2 wrote:

Hello Reedy,Please Check Caption no: 05

Then go to the Summary part & check the Description. Then you found something.

I found some text. All these fields are sipposed to take basically any text.

You've got 3 alerts, I don't get presented with an alert. I'm not seeing any evidence of an XSS.

If you've got evidence otherwise, please provide it

You don't get any alerts in caption? Here .

That's not an alert. That is just text on the page. MediaWiki allows you to put almost anything into most of the boxes, that's expected and wanted.

Please see https://www.w3schools.com/jsref/met_win_alert.asp and https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_alert for how an alert works

aww,You mean that error! Basically any webpage did not allows me to put any payloads in any where if there is not a error.If there is an error webpage shows something unusual Wikipedia Commons allows me to do that.So i reported that issue.Thanks for response politely.

Noting that this is the same as T293556, this was not invalid and was a real vulnerability... which means we made a high risk XSS public and unfixed for 10 months.

Given the above comment and that it is not invalid. Feel free to revert/change if you feel it is inappropriate.

In T269130#7548729, @Pealhasan.x2 wrote:

Hello Dylsss,Hope you are well. I know that was valid, But I have no word to express how to prove that one! Now the Wikipedia Security team got it! I reported it last year in 2020 (December)! But who report again that is this year (2021). But my report got a duplicate tag! I don't know why! Is it possible to do anything about this issue?

Just fyi, i sometimes do bug bounty hunting - a tip: when looking for xss it is often more succesful to use <img src=x onerror=alert(1)> than script tags, because per the html spec, script tags are not executed by innerHTML, so you miss out on most DOM based xss if you use a script tag based payload.

In bug bounties i've participated in [for different organizations] it is really important to get all the way to the exploit and be clear in describing what is happening. Generally speaking, getting only half way to the vulnerability doesn't count for much; you need to show actual js executing. Which you didn't here.

[This is just about my experiences elsewhere in case its helpful. This is not meant to be a comment about wikimedia or this specific situation]

@Pealhasan.x2 - do you believe this to be a different issue from the one it was merged into, that is T293556? Because it appears to me to be the same issue which has been resolved via the other task. In which case we should keep this task merged into that one and resolved.

@Pealhasan.x2 one would generally mark the second report of a bug as a duplicate of the first one. However, in this case it was tracked on T293556, and only determined to be the same as this later. Marking it as a duplicate means "this is the same problem as T293556". It makes sense to put them in this orer since the work was done there. even though in this case it does happen that your report came earlier.