Subsequent system impact/changed scope in CVSS calculation for security advisories

Development
1

Hi,

since some time, GitHub supports CVSS v4, which we already started using for computing the severity of security advisories. An important new part is the “Subsequent system impact metrics”. This basically replaces the “Scope” of CVSS v3. However, I have a hard time understanding how to fill this part. According to the user guide there are two cases we should consider I think:

  1. XSS, which impacts the browser according to the user guide. I have a hard time understanding how this would affect the confidentiality or integrity of the web browser as browsers have high security boundaries between web applications and thus every interaction in the browser either is in the regular security scope of the web application or exploits another vulnerability in the browser, which I think we shouldn’t assume.
  2. Accessing resources beyond the “regular” scope of the web application. With programming right, XWiki already allows users to do arbitrary things on the host system, so one could argue that it isn’t really crossing any security boundary. On the other hand, this isn’t possible for users without programming right, so it might still be considered a security boundary.

Previously, with CVSS v3, for me, the scope was “Unchanged” when the vulnerability only concerned data inside XWiki itself and “Changed” when the vulnerability allowed accessing or modifying data outside XWiki on the server (so arbitrary file reading, file writing, or remote code execution). In our security policy we have currently no guidance regarding the scope.

There are some examples provided by First. They have an XSS example which shows they would put a low impact for confidentiality and integrity for the subsequent system as “An attacker could read data from the user’s browser.”/“An attacker could modify data in the user’s browser.” They also have the “Spring4shell” vulnerability that sounds similar to a remote code execution vulnerability in XWiki. In this case, they consider the whole webserver as one system and thus there is no impact on subsequent systems.

There is no immediate loss of confidentiality within the subsequent systems. But, based on how Spring is deployed in the target environment, the compromised server could be used as a pivot to leverage further. If there are subsequent impacts, they should be defined in environmental metrics.

Taking these examples, it seems to me we should:

  1. In the case of XSS, indicate a low confidentiality and integrity impact for subsequent systems.
  2. In the case of remote code execution, only indicate an impact on subsequent systems when the same vulnerability also allows XSS (which is usually the case with XWiki syntax injection).

What I absolutely don’t understand is their assessment of XSS. How does a vulnerability with the following description have “no direct impact to the web application confidentiality”?

[…] The attacks could allow the attacker to read content that the attacker is not authorized to read, use the victim’s identity to take actions on the SharePoint site on behalf of the user, such as change permissions and delete content, […].

Maybe we should re-consider how we evaluate XSS vulnerabilities? We discussed this here and said that we assume a high impact for these vulnerabilities, but apparently this isn’t consistent with the recommendations?

Do you have any input how we should fill in the ‘Subsequent system impact metrics’ for XWiki vulnerabilities? Do you agree with the conclusions from the examples? What should we do with the (direct) impact of XSS?

Thank you very much for your input!

2

To get some arguments, I asked an LLM (Llama 3.3 70B Instruct to be precise) to explain the reasoning for the XSS assessment to me. The key argument it provided is the following:

The reasoning behind this classification is that the vulnerability itself does not directly compromise the confidentiality or integrity of the SharePoint Server. Instead, it allows an attacker to exploit the vulnerability to attack the user’s browser, which is a subsequent system. The impact on the user’s browser is what leads to the compromise of confidentiality and integrity, rather than a direct impact on the SharePoint Server.

I find this reasoning interesting as it kind of makes sense (but only kind of, I find it still strange). Basically, the user’s browser is considered a normally secure environment that can be attacked through XSS. When asked, the LLM also explained that the scoring should be changed if it allowed executing actions in the name of an admin user. I don’t put any trust into these statements (it’s an LLM), but I find the reasoning interesting. It would basically mean that for pure XSS, we should basically put high risk for the subsequent system and no impact on the system itself.

There is an interesting discussion web application - CVSS3 score for XSS leading to account takeover - Information Security Stack Exchange that takes about this also. If I understand the mention there directly, one could also consider the user’s browser the attacked system and the web application the subsequent system, but this seems a bit far-fetched to me (and it is not clear to me if this is really what the author meant).