Network — exploitable remotely over the internet. Most dangerous. Example: a web server vulnerability anyone can hit from anywhere.
Adjacent — requires the attacker to be on the same local network or Bluetooth range. Example: WiFi attacks.
Local — attacker needs local access (logged in to the machine). Example: a privilege escalation bug.
Physical — attacker needs physical access to the device. Example: a USB attack.
Low — no special conditions required. The attacker can exploit it repeatedly and reliably. Most vulnerabilities are Low complexity.
High — specific conditions must exist that the attacker cannot guarantee. Example: a race condition that only works sometimes, or requires a specific configuration to be present.
None — unauthenticated attacker. No account needed. Most dangerous.
Low — attacker needs a basic user account. Example: any logged-in user can exploit it.
High — attacker needs admin or root privileges. Less common but still dangerous — admins can be compromised.
None — the attacker can exploit it alone, no victim interaction needed. Example: a server-side bug.
Required — a user must do something. Example: click a link, open a file, visit a page. This is the category phishing exploits fall into.
Unchanged — the vulnerability only affects the component being attacked. Example: a database query injection that only affects that database.
Changed — exploiting the vulnerability allows impact on other components. Example: a hypervisor escape that lets a VM attack the host OS. Or a browser sandbox escape. Scope Changed vulnerabilities are significantly more dangerous and score higher.
None — no confidentiality impact. The attacker gains no information.
Low — limited information disclosure. Attacker gets some data but not everything. Example: can read certain files but not all.
High — total loss of confidentiality. Attacker can read all data in the component. Example: full database dump, all credentials exposed.
None — attacker cannot modify any data.
Low — attacker can modify some data but the scope is limited. Example: can change their own profile but not others.
High — total loss of integrity. Attacker can modify anything. Example: arbitrary code execution, full database write access.
None — no availability impact. Service continues normally.
Low — reduced performance or intermittent outages. Example: attacker can slow the service but not fully stop it.
High — total loss of availability. Attacker can completely shut down the service. Example: a DoS vulnerability that crashes the server.
What is CVSS?
The Common Vulnerability Scoring System (CVSS) is the universal standard for rating the severity of security vulnerabilities. Every CVE (Common Vulnerability and Exposure) published by NIST's National Vulnerability Database has a CVSS score. When a SOC analyst triages an alert or a security team decides what to patch first, CVSS scores drive those priority decisions.
0.1 – 3.9 Low
4.0 – 6.9 Medium
7.0 – 8.9 High
9.0 – 10.0 Critical
How SOC analysts use CVSS: When a new vulnerability is disclosed, analysts check its CVSS score to decide urgency. A CVSS 9.8 Critical with Network attack vector and no privileges required gets patched immediately. A CVSS 4.2 Medium requiring physical access gets scheduled for the next maintenance window. CVSS doesn't tell you everything — context matters — but it gives every team a common language for risk prioritization.
CVSS limitations: CVSS scores the worst-case technical severity in isolation. It doesn't account for whether your environment is actually exposed, whether compensating controls exist, or the business impact of the specific asset. A CVSS 9.8 on a server that's air-gapped from the internet is less urgent than a CVSS 7.0 on your public-facing web application. Always combine CVSS with context.