S:C means Scope Changed. In a CVSS 3.1 vector it says an exploit can impact resources managed by a different security authority than the vulnerable component, for example breaking out of a sandbox. It usually raises the score, so a finding with S:C deserves a closer read, not automatic panic.
Definition in plain words
CVSS 3.1 defines a security authority as a mechanism, such as an application, an operating system, firmware or a sandbox, that decides how subjects may access restricted objects. Scope asks one question: when the flaw is exploited, does the damage stay inside the resources that authority manages, or does it reach resources managed by another authority?
| Value | Vector text | Meaning |
|---|---|---|
| Unchanged | S:U | Impact stays within the same security authority |
| Changed | S:C | Impact reaches resources under a different security authority |
The specification adds that components which exist only to serve another component share that component's scope. So a helper library inside your application does not, by itself, create a changed scope.
Where you see it
A typical vector looks like this:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Scanners usually print the vector in a details panel or in the raw record. Look for the segment between UI and C. If it reads S:C, the scorer judged that the flaw crosses a boundary. Typical shapes are a script in a web page reaching data owned by the browser's wider context, or a process escaping a container or virtual machine. Which of those fits your finding comes from the advisory text, not from the letters.
Why it changes the number
The 3.1 specification uses different constants for Privileges Required depending on scope. For Low privileges the constant is 0.62 when scope is unchanged and 0.68 when changed. For High privileges it is 0.27 unchanged and 0.5 changed. The same values in the same vector therefore score higher with S:C. That is why two otherwise identical vectors can land in different severity bands.
How to use it when triaging
- Read the advisory summary and find the boundary it claims is crossed. If you cannot name the boundary, treat the S:C as unverified.
- Ask whether that boundary exists in your deployment. A sandbox escape matters little if you never run untrusted code in that sandbox.
- Check the other metrics. S:C with PR:H and AC:H describes a narrow attack. S:C with PR:N and AC:L describes a wide one.
- Record your answer next to the finding so the next reader does not repeat the work.
Remember the base score assumes a reasonable worst case across deployments. The specification itself recommends adding temporal and environmental information, and notes that other factors outside CVSS can inform the remediation decision.
What S:C does not tell you
It does not say the flaw is being exploited, that exploit code exists, or that your build reaches the vulnerable function. It is a statement about potential blast radius. Pair it with exploit evidence and with whether your code calls the affected function before you set a priority.
Safeguard's reachability analysis can show whether your code reaches the vulnerable function behind a finding, which helps you decide how much weight a scope claim deserves. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the exploitability signals sit beside the severity score.
Quick check
Does S:C always mean a critical finding?
No. Scope raises the score for the same other metrics, but a changed scope with high required privileges and high complexity can still land in the medium or high band.
Is a vulnerable library inside my app a changed scope?
Usually not. The specification says components that exist solely to serve another component share its scope, so a helper library normally stays in the same security authority.
Sources
Last reviewed: 19 October 2026.
