Let's say I have an e-commerce organization. My organization has two security authorities A and B. The authority A manages access to data related to user orders, and the authority B manages access to data related to user payments.

My organization also has two software components: the websites W1 and W2. The website W1 is governed by the security authority A and the website W2 is governed by the security authority B.

At some point, W2 intentionally provides W1 with an access_token. That access_token can be used to retrieve the user's payment information. Now, due to a security vulnerability in W1, the access_token is leaked to an attacker, giving the attacker access to the user's payment information.

Would this be considered a scope change as per CVSS v3?

I think the description I provided suits the scope changed definition:

Scope changed: An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.

Formally, Scope refers to the collection of privileges managed by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization.

If an exploited vulnerability in an application that implements its own security authority can affect resources beyond its security scope, the vulnerability is also scored as scope changed.

But I would like to hear other opinions.


https://www.first.org/cvss/specification-document#2-2-Scope-S https://www.first.org/cvss/v3.1/user-guide#3-5-Scope-Vulnerable-Component-and-Impacted-Component


1 Answer 1


I would agree with you, as the issue can be exploited to gain access to data from another scope. That's a scope change.

To play devils advocate, we could look at this:

All the subjects and objects under the jurisdiction of a single security authority are considered to be under one security scope

The access_token was provided to W1. So if someone wanted to argue against the increased scope, the token could be considered under W1s jurisdiction (ie no scope change; you are attacking W1 and gaining access to data W1 is supposed to have).

I think it's a bit of a reach, and it's certainly not under its sole jurisdiction; W1 isn't a "single security authority" as it related to the token.

There's also this:

Intuitively, whenever the impact of a vulnerability breaches a security/trust boundary and impacts components outside the security scope in which vulnerable component resides, a Scope change occurs.

The vulnerability definitely breaches a boundary and impacts components outside of its security scope.

That's assuming W1 and W2 actually are considered separate scopes. If - by design - there isn't a trust boundary, ie if we assume that the sharing of the token means W1 and W2 form a single authority, then there wouldn't be two scopes and no scope change. But as you describe it, that doesn't seem to be the case here.

  • Hi tim, thanks for the response! In my theoretical organization, a user of the application W2 can authorize the application W1 to access his payment information only if he decides to do so. When the user clicks "I agree" on the application W2, an access_token granting access to his payment information will be sent to W1. Therefore, W1 has no direct privileges to access his payment information. The difficult question here, as you have mentioned, is whether the authorization privileges granted by that access_token should be included as part of the authorization privileges managed/intended by W1.
    – mateleco
    Commented Jul 1, 2023 at 23:23
  • 1
    @mateleco imho the user having to click doesn't change much. If there's an argument if these are even two scopes to begin with, the need to grant access via click strengthens the argument for two scopes. Apart from that, I still think that it's a scope change (W1 isn't a single authority in regard to the token & an attacker gains access beyond W1), but I do see how someone could argue for no scope change (the token is intended to be given to and managed by W1). I think that argument is weaker though.
    – tim
    Commented Jul 3, 2023 at 17:38
  • Hi @tim, I know you are keen on CVSS and XSS so I would also love to hear your opinion on this one: security.stackexchange.com/questions/271753/…
    – mateleco
    Commented Aug 18, 2023 at 15:11
  • 1
    @mateleco hehe, I actually saw the question already and have thoughts but didn't write them up yet. I'll write something up later :)
    – tim
    Commented Aug 18, 2023 at 15:20
  • 1
    @mateleco I actually wrote up an answer originally but didn't post it because I wasn't quite satisfied with it. But I'll work it over & post it.
    – tim
    Commented Sep 1, 2023 at 5:58

You must log in to answer this question.

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