I tried this on my test domain, and sure enough the impact of this behavior is very small for now.

You can see in the File below, where the XSS is triggered in the PDF View https://upload.wikimedia.org/ :
https://commons.wikimedia.org/wiki/File:Xss2141241.pdf

I tried this on Dropbox and Google Drive. They seem to be aware of this problem, so when I pass a PDF file that is injected with the javascript protocol payload, then the responds get the javascript cleaned up in Google Drive and in Dropbox the protocol javascript is escaped with the HTTPS prefix. And that's what makes this behavior less vulnerable due to inspection of PDF files.

I tried on the beta site and this is the result:

1. https://commons.wikimedia.beta.wmflabs.org/

In BETA, it looks like there is validation on the PDF file, so it doesn't pass.

I don't think this has any effect on my browser executing arbitrary scripts.
I noticed no protection against javascript protocol escaping in checking the contents of file metadata. So that it will pass the javascript protocol in the PDF File.
I believe almost all users use PDF View in their Chrome and Edge Browsers. So that it can trigger XSS on multiple users side.

Can you give me the location of the Commons Upload on Wikipedia BETA?

Can the URL of this report be disclosed, sir?

Oh I see, I understand now.

I don't understand the reason why it went low sir :(

Why is XSS STORED risk rating Low?

Thanks for fixing this issue so fast, it's great :)

After I double checked, it seems this behavior has been fixed.

After I double checked, it seems this behavior has been fixed.

Thanks for responds :)

I think this is just an additional step towards the behavioral findings in this report.

Thanks for adding me here :)