User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151029151421 Steps to reproduce: Visit the attached svg file Actual results: The XSS within the SVG file is executed in the browser because the content-type in the HTTP response from clicking the attachment is set to "image/svg+xml" and not "application/octet-stream" Recommended fix: Force content type for all attachment requests to be "application/octet-stream" and force the user to download the file mitigating the automatic XSS in the browser.

we allow attachments to be rendered by the browser, but server them from a different domain to prevent xss. see one of the many duplicates of bug 38862 for more information: http://mzl.la/1BZDuXh

Just for the sake of record, this is less about whether this is XSS or not and more about the hard requirement to load web-content attachments inline. Considering this an accepted risk by the business owner at this time.

To an extent it _is_ about whether it's an XSS or not, and we put a lot of work into isolating uploaded content into a per-bug subdomain of a non-mozilla.org/com domain. There should be no non-public assets reachable by such scripts (or in the case of hidden bugs, the reachable content was already visible to the evil attachment creator). An XSS on BMO itself would be bad and we've paid bug bounties to people who have found such bugs.