It is possible to have JavaScript code in pdf or svg files. I think JavaScript inside svg runs in almost all browsers and I think JavaScript inside pdf generally always runs in chrome.

So during a pentest we have seen that the website allows upload of pdf files with Javascript content, which runs inside the browser (the PDF is opened by the browser e.g. example.com/files/example.pdf). The uploaded files served from the main domain and not a third party service or CDN. The pdf is later reviewed by an admin of website. The payload will only trigger on google chrome browser. Can we say the website is vulnerable to stored xss in the report? If the payload only runs in chrome, does this affect CVSS score?

Also, what about svg file?

New contributor
user26317030 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • Recall the definition of XSS. Does simply having code inside a file qualify as XSS?
    – schroeder
    Commented Jul 10 at 8:04
  • 6
    There are a ton of questions in the answers that also need to be answered, else we're guessing.
    – schroeder
    Commented Jul 10 at 16:44
  • 2
    Have you proven that the PDF or SVG actually trigger a payload? Even if it's theoretically possible for a payload to trigger from one of these (or any other) file, doesn't mean it actually will trigger.
    – Bee H.
    Commented Jul 10 at 19:51
  • are they reflected back? I believe downloading or viewing downloaded file in the browser directly will have a special local domain... (and a special window handle). If instead the server outputs/processes them inside of a web page, you might see if proper XSS prevention is in place. (For instance, using a sandboxed iframe) Commented Jul 11 at 22:25

2 Answers 2


When risk assessing such a scenario, there are a few questions to ask:

  • Are the uploaded files served from the main domain? If they're served from a different domain, that's usually a mitigation. This is why googleusercontent.com exists.
  • Are Content-Disposition headers used? If they're served as attachments, they execute in a different origin. Trying alert(document.domain) as a payload is helpful.
  • Can other users view the uploaded files? If not, this is just self-XSS, so reportable but low risk.
  • Would other users naturally navigate to these files? If not, while this is technically stored XSS, user interaction is required so the risk profile looks more like reflective XSS.

I see the question has been updated to confirm:

  • Uploaded files are on the main domain
  • Other users (including admin) can view files
  • Other users (including admin) naturally navigate to such files

If there are no Content-Disposition headers, then this appears to be exploitable as a stored XSS which allows escalation from low-privilege user to admin, which is almost certainly high-risk and possibly critical.

I believe this is exploitable for SVG files only. While JavaScript can execute in a PDF, it is restricted and effectively operating in a separate origin.

Payload only running in Chrome doesn't affect the risk rating, because Chrome is very widely used. If the exploit only worked in an old browser like IE 6, that would change the rating.

  • 2
    The result of alert(document.domain) is "document is not defined" Commented Jul 10 at 21:24
  • 3
    @user26317030 - I think that implies that PDF JavaScript is now non-exploitable, due to lockdowns implemented within PDF readers. However, SVG is exploitable. I created a quick lab
    – paj28
    Commented Jul 11 at 8:06

Not without further details.

Why? Well, your reasoning is vulnerable (pardon the pun) to a reductio ad absurdum.

By your definition, Google Drive / OneDrive / SharePoint / virtually any filesharing service is inherently vulnerable and insecure. So is e-mail.

Even more so than "just" XSS, they allow the sharing of arbitrary content, so they pose the risk of full remote code execution on any client machine! Wanna see my collection of photos and educating movies, pretty_girls.mp4.exe? I love you!

And, well, it is indeed the case. The use of such services is inherently insecure.

And yet it would be absurd to say that "e-mail has failed pentest on grounds that it allows sending almost arbitrary files as attachments". Well OK, nowadays e-mail mostly forbids .exe files as attachments (so I'll send you a password protected ZIP instead), but filesharing services are commonly used instead of e-mail if one really has to share an executable, so we should condemn all file-sharing services even more firmly than e-mail.

Problem is, they exist specially to provide that functionality. Demanding that a file-sharing service must stop providing file-sharing capabilites (or else security audit fails and consequences follow) kind of misses the point.

  • This is absolutely the best answer. Commented Jul 13 at 5:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .