Severity of cross-site scripting vulnerabilities

Eagle-eyed readers of today’s security advisory may already have noticed that we consider the cross-site scripting (XSS) vulnerabilities to be ‘High’ severity.
This is a change from previous security advisories, in which similar vulnerabilities got a ‘Medium’ score.

We follow the guidelines of CVSS version 3.0 for the severity we assign to these issues.
Their examples for XSS vulnerabilities, as well as XSS vulnerabilities in other software, consider the most severe, immediate impact to be a modification of the HTML output, possibly also the extraction of the session cookie (something Jenkins prevents by declaring it to be HttpOnly).

Unfortunately, this does not adequately model the impact that a successful XSS exploitation in Jenkins can have:
Jenkins administrators can perform far more sensitive actions than e.g. the admins of most content management systems could, as it is designed to allow users to execute code to build, test, and deploy their software.
So this kind of vulnerability, that allows attackers to do anything their victims have permission to do, in Jenkins can mean execution of arbitrary code, perhaps via the script console, if the victim has the Overall/Administer permission.
None of this requires chaining different actions in an attack, a well-chosen XSS payload will accomplish this.

Therefore, starting today, we score XSS vulnerabilities by the highest immediate impact a successful attack can have, which is a complete system compromise if admins can be attacked.
For stored XSS requiring some permissions, like the ability to configure jobs, a typical score would be 8.0.
Reflected XSS, which don’t require any permissions to exploit, will usually score 8.8.