In CVSS v3.1, what does Scope:Changed mean and when is it justified?
answer
- who is impacted, not how many
- ask who administers the damaged resource
- escaping a sandbox, a guest, a container
- impact metrics now describe someone else
- 1.08 multiplier and higher PR weights
basics
~20 sScope:Changed in CVSS v3.1 means the exploit crosses out of the vulnerable component's own security authority and impacts resources governed by a different one — a hypervisor escape reaching co-tenant VMs, for example. It raises the score, never lowers it.
solid answer
~50 s`Scope:Changed` means the exploited vulnerability affects resources beyond the security authority that governs the vulnerable component — the vulnerable component and the impacted component are administered by different authorities. The canonical case is a guest-to-host escape: a paying tenant on shared hosting exploits the hypervisor from inside their own VM and reaches co-tenant workloads. The hypervisor is the vulnerable component, the neighbours' VMs are the impacted ones, and nobody granted that tenant authority over them, so `S:C`. It is *not* a count of affected machines. Once you set `S:C` the C/I/A metrics rate the worst impact on the **impacted** component rather than the vulnerable one, the Privileges Required weights rise, and the total is multiplied by 1.08 — so `S:C` can only push a score up, and the maximum base score becomes 10.0 instead of 9.8.
go deeper
Know that Scope is one of the eight CVSS v3.1 base metrics, that its values are Unchanged and Changed, and that Changed means the damage lands outside the flawed component.
Be able to explain security authority in your own words and give one clean example each way, plus what Changed does to the impact metrics and the final multiplier.
Expect to be handed a described architecture and asked to set Scope and defend it, including cases where the honest answer is Unchanged even though the consequence sounds severe.
Be ready to say why this metric was the least reproducible in v3.x, what guidance you would give raters to make it consistent, and what its removal in v4.0 says about designing rating schemes people can actually apply.
## Security authority, not blast radius CVSS v3.1 defines a **security scope** as the set of resources governed by a single security authority — one entity that grants access and enforces policy over them. An operating system is an authority over its processes and files; a hypervisor is an authority over its guests; an application is an authority over the data and sessions it manages; a database is an authority over its schemas and roles. Scope answers one question: after the exploit, does the damage stay inside the authority that governs the flawed component, or does it land on resources some *other* authority governs? If it stays inside, `S:U` (Unchanged). If it crosses over, `S:C` (Changed). The key discipline is to keep two components separate in your head: - the **vulnerable component** — where the flaw lives, the thing you would patch; - the **impacted component** — where the damage lands. If they are the same thing, or are governed by the same authority, Scope is Unchanged. If they are governed by different authorities, Scope is Changed. ## The canonical case A multi-tenant shared-hosting platform runs customer workloads as guests on a hypervisor. A paying tenant — an attacker position that is legitimate, authenticated and *inside* the perimeter — exploits a flaw in the hypervisor's device emulation from within their own guest and executes code on the host, reaching the memory and disks of co-tenant workloads. The vulnerable component is the hypervisor. The impacted components are the other tenants' VMs and their data. The tenant was granted authority over exactly one guest and nothing else, so the exploit has crossed a security authority: `S:C`. The asset lost here is other customers' workloads and the isolation guarantee the platform sells, which is precisely what a base score is meant to convey to every reader downstream. Contrast a flaw in the same platform's tenant portal that lets a signed-in tenant read their own account's data through an unintended path. That never leaves the portal's own authority, so `S:U`, regardless of how many rows it touches. ## What Scope does mechanically Scope is not cosmetic — it changes three things at once. 1. **Which component the impact metrics describe.** Under `S:C`, `C`, `I` and `A` rate the *most severely impacted* component, which may be the vulnerable one or a downstream one, whichever is worse. Under `S:U` they can only describe the vulnerable component. 2. **The Privileges Required weights.** `PR:L` and `PR:H` are weighted higher when Scope is Changed — 0.62 rises to 0.68, and 0.27 rises to 0.50. The reasoning is that privileges held over the vulnerable component buy the attacker less when the damage lands somewhere they were never trusted. 3. **The final multiplier.** The combined impact and exploitability sub-scores are multiplied by 1.08 before the 10.0 cap. Because every one of those pushes upward, switching `S:U` to `S:C` with all other metrics held equal can only raise the score. It also lifts the ceiling: the highest possible `S:U` base score is 9.8, while `S:C` can reach 10.0. ## How to settle a disagreement about it When two raters disagree, do not argue about severity — argue about administration. Ask: *who grants access to the thing that got damaged, and is it the same entity that grants access to the thing that was flawed?* If a single team, product or kernel owns both sides of the exploit, it is Unchanged. If the exploit hands the attacker something a different authority was supposed to gate, it is Changed. Writing the vulnerable component and the impacted component down explicitly, as two named items, resolves most of these arguments in a sentence. Also be honest about what Scope is *not* measuring. It is not lateral movement potential, not the number of hosts, not whether the attack was remote, and not privilege escalation on the same box — a local user becoming root is normally `S:U`, because the operating system was the authority over both the user and root all along. ## The metric people got wrong most often Scope was the most inconsistently applied metric in v3.x, and CVSS v4.0 responded by removing it entirely. In its place, v4.0 records impact twice: once on the vulnerable system and once on any subsequent system, so the rater states the crossing directly rather than encoding it in a single letter. When you are asked about Scope, knowing that it was retired for exactly this reason is a strong close.
- Under Scope:Changed, which component do the C, I and A metrics describe?The most severely impacted component, which is usually the downstream one rather than the flawed one. In the hypervisor escape you rate what happens to co-tenant workloads, not what happens inside the attacker's own guest. Under Scope:Unchanged you have no such freedom — the impact metrics can only describe the vulnerable component itself. Getting this backwards is the second most common Scope mistake after treating it as a count of affected machines.
- A local user exploits a kernel flaw to become root. Scope Unchanged or Changed?Unchanged. The operating system is a single security authority governing both the unprivileged user and root, so the exploit never crosses into someone else's scope — it is a privilege escalation inside one authority. Raters often reach for Changed because the outcome feels dramatic, but severity is already carried by the impact metrics and by Privileges Required. Scope asks only about the boundary, not about how bad the result is.
- Two raters disagree on Scope for the same finding. How do you resolve it in review?Make them name two things explicitly: the vulnerable component and the impacted component. Then ask a single administrative question — does one entity grant and revoke access to both? If yes, it is Unchanged; if the exploit delivers something a different authority was supposed to gate, it is Changed. This turns a subjective argument about seriousness into a factual one about ownership, and it is why v4.0 replaced the metric with separate vulnerable-system and subsequent-system impact metrics.
Think of a landlord: breaking the lock on your own flat is Scope Unchanged, while breaking the building's master lock and walking into every other flat is Scope Changed.
saying these in an interview costs you the question
- Sets Scope:Changed whenever more than one host is affected
- Treats Scope as blast radius rather than security authority
- Uses Scope:Changed for any remotely exploitable flaw
- Rates the impact metrics on the vulnerable component under S:C
- Believes Scope:Changed can lower a base score
- Calls local privilege escalation to root Scope:Changed