The Common Vulnerability Scoring System is an open framework for communicating the severity of software security vulnerabilities. Maintained by the Forum of Incident Response and Security Teams (FIRST), CVSS provides a standardized numerical score that security teams use to prioritize remediation efforts across their environments.
Every CVE (Common Vulnerabilities and Exposures) entry published by MITRE and the National Vulnerability Database (NVD) receives a CVSS base score. That score condenses multiple technical factors into a single number between 0.0 and 10.0. The higher the score, the more severe the vulnerability.
CVSS does not measure risk. It measures severity. The distinction matters. Severity is intrinsic to the vulnerability itself. Risk depends on your environment, your assets, your compensating controls and whether the vulnerability is being actively exploited. A CVSS 9.8 on a test machine behind three firewalls may pose less real-world risk than a CVSS 5.3 on your public-facing payment portal.
Disclaimer: All exploit scenarios on this page are illustrative patterns for defensive understanding only. No working exploit code is provided. These examples help security teams recognize vulnerability categories and prioritize response.
CVSS Severity Levels
CVSS base scores map to four severity levels. Each level carries a recommended patching timeline based on industry consensus and frameworks including CISA KEV and NIST SP 800-40.
| Score Range | Severity | Patching Timeline | Detection Priority |
|---|---|---|---|
| 9.0 - 10.0 | Critical | Hours | Immediate alerting, active hunt |
| 7.0 - 8.9 | High | Days | Next business day triage |
| 4.0 - 6.9 | Medium | Weeks | Scheduled scan cycle |
| 0.1 - 3.9 | Low | Next maintenance cycle | Routine assessment |
Critical Severity (9.0 - 10.0)
What It Means
Critical vulnerabilities allow an attacker to compromise a system remotely with little or no effort. These flaws typically require no authentication, no user interaction and no special privileges. The attacker sends a crafted request to a network-accessible service and gains full control. There is no barrier between the attacker and total system compromise.
Illustrative Scenario: Unauthenticated Remote Code Execution
A web application server contains a deserialization flaw in its request handler. An unauthenticated attacker sends a specially crafted HTTP request containing a malicious serialized object. The server processes the object without validation and executes the embedded commands with the web server's privileges. The attacker now has a remote shell on the server.
- What the attacker gains
- Full command execution on the target server. The attacker can read sensitive files, install persistent backdoors, pivot to internal networks, exfiltrate databases and deploy ransomware. If the web server runs as root (a common misconfiguration), the attacker owns the entire machine.
- What the defender should do
- Apply the vendor patch immediately. If no patch exists, take the vulnerable service offline or place it behind a web application firewall with a rule blocking the exploit pattern. Monitor for indicators of compromise. Conduct forensic triage on any system that was running the vulnerable version while internet-facing. Assume compromise until proven otherwise.
- Patching timeline
- Hours. Critical vulnerabilities on internet-facing systems demand emergency patching outside normal change windows. If your organization cannot patch within hours, isolate the vulnerable system from the network until remediation is complete.
High Severity (7.0 - 8.9)
What It Means
High severity vulnerabilities enable significant compromise but require an additional condition that limits mass exploitation. That condition might be valid credentials, a specific configuration, elevated privileges on a related system or local network access. The vulnerability is dangerous but not trivially exploitable by any anonymous attacker on the internet.
Illustrative Scenario: Authenticated Privilege Escalation
A content management system contains an insecure direct object reference in its user management API. A user with read-only access modifies their own user ID parameter in an API request to reference an administrator account. The application fails to validate authorization and applies the requested changes. The read-only user now has full administrative privileges.
- What the attacker gains
- Administrative access to the entire application. The attacker can create new admin accounts, modify content, access other users' data, change application configuration and potentially execute code through admin-only functionality such as plugin installation or template editing.
- What the defender should do
- Patch within days. Review application logs for any suspicious privilege changes or API calls targeting the user management endpoint. Audit all accounts for unauthorized privilege escalation. Implement server-side authorization checks that validate the requesting user's permissions against the target resource for every API call.
- Patching timeline
- Days. High severity vulnerabilities should be remediated within 1 to 7 days depending on exposure. Internet-facing systems trend toward 1 to 2 days. Internal systems with compensating controls may extend to 7 days.
Medium Severity (4.0 - 6.9)
What It Means
Medium severity vulnerabilities require multiple conditions for successful exploitation. The attacker may need user interaction (clicking a link or opening a file), local access, a specific non-default configuration or a combination of factors. These vulnerabilities are real threats but are not self-propagating and cannot be exploited at scale without additional effort.
Illustrative Scenario: Reflected Cross-Site Scripting (XSS)
A web application reflects user-supplied input in error messages without sanitization. An attacker crafts a URL containing JavaScript in a query parameter. When a victim clicks the link (delivered via phishing email or social media), the JavaScript executes in the victim's browser session. The script sends the victim's session cookie to an attacker-controlled server.
- What the attacker gains
- The victim's authenticated session. The attacker can impersonate the victim, access their data, perform actions on their behalf and potentially escalate privileges if the victim has administrative access. The impact is limited to users who click the malicious link.
- What the defender should do
- Patch within the next scheduled maintenance window. Implement Content Security Policy headers to mitigate XSS impact. Enable HttpOnly and Secure flags on session cookies to prevent JavaScript access. Deploy input validation and output encoding on all user-supplied data reflected in HTML responses.
- Patching timeline
- Weeks. Medium severity vulnerabilities should be addressed within 2 to 4 weeks. Prioritize higher if the application handles sensitive data or if the vulnerability is being actively exploited in phishing campaigns targeting your organization.
Low Severity (0.1 - 3.9)
What It Means
Low severity vulnerabilities have limited impact or require restrictive conditions for exploitation. The attacker may need physical access, local network positioning or an unlikely configuration. The information gained is typically minor and does not directly lead to system compromise. These vulnerabilities are still documented because they can serve as building blocks in multi-stage attacks.
Illustrative Scenario: Minor Information Disclosure
A network service on a local subnet responds to unauthenticated requests with verbose error messages that include the software version number, internal IP addresses and directory paths. An attacker on the same local network segment can query this service to enumerate the internal environment.
- What the attacker gains
- Reconnaissance data: software versions for targeted exploit selection, internal IP ranges for lateral movement planning and directory structures for path traversal attempts. This information alone does not compromise the system but reduces the effort required for subsequent attacks.
- What the defender should do
- Address during the next scheduled maintenance cycle or patch rotation. Disable verbose error messages in production. Configure services to return generic error responses. Restrict service access to authorized IP ranges using firewall rules or access control lists.
- Patching timeline
- Next maintenance cycle. Low severity vulnerabilities are addressed during routine patching, typically monthly or quarterly. Escalate if the vulnerability is chained with other findings during a penetration test.
How CVSS Is Calculated
The CVSS base score is derived from eight metrics organized into two groups: exploitability and impact. Understanding these metrics allows security teams to interpret the vector string attached to every CVE and make informed decisions about prioritization.
Exploitability Metrics
| Metric | Values | What It Measures |
|---|---|---|
| Attack Vector (AV) | Network, Adjacent, Local, Physical | How the attacker reaches the vulnerable component. Network means remotely exploitable over the internet. Physical means the attacker must touch the device. |
| Attack Complexity (AC) | Low, High | Whether special conditions beyond the attacker's control must exist. Low means the exploit works reliably. High means specific configurations or race conditions are required. |
| Privileges Required (PR) | None, Low, High | The level of authentication needed before exploitation. None means unauthenticated. High means administrative privileges are required. |
| User Interaction (UI) | None, Required | Whether a victim must perform an action for the exploit to succeed. None means fully automated. Required means the victim must click a link, open a file or take another action. |
Impact Metrics
| Metric | Values | What It Measures |
|---|---|---|
| Scope (S) | Unchanged, Changed | Whether the vulnerability can affect resources beyond the vulnerable component. Changed means a web application vulnerability can impact the underlying operating system. |
| Confidentiality (C) | None, Low, High | The degree of data exposure. High means total information disclosure. Low means partial or limited data access. |
| Integrity (I) | None, Low, High | The degree of data modification possible. High means the attacker can modify any data. Low means limited modification capability. |
| Availability (A) | None, Low, High | The impact on system availability. High means total denial of service. Low means degraded performance or partial disruption. |
These eight metrics are combined using a mathematical formula defined in the CVSS specification. The formula weights exploitability metrics to reflect attack surface and impact metrics to reflect damage potential. The resulting score is rounded to one decimal place.
Why CVSS Alone Is Not Enough
CVSS measures the intrinsic characteristics of a vulnerability in isolation. It does not account for your specific environment. Two organizations running identical vulnerable software may face vastly different levels of actual risk.
- Internet-facing vs. internal systems
- A CVSS 9.8 vulnerability on an air-gapped lab machine poses minimal risk. The same vulnerability on a public-facing web server is an emergency. CVSS assigns the same score to both because it measures the vulnerability, not the deployment context.
- Asset value and data sensitivity
- A Medium severity vulnerability on a server hosting customer payment data may warrant faster remediation than a Critical vulnerability on a development sandbox containing synthetic test data. CVSS does not factor in what the system stores or processes.
- Compensating controls
- Network segmentation, web application firewalls, intrusion detection systems and endpoint protection may reduce the exploitability of a vulnerability. CVSS does not account for these controls because they vary between deployments.
- Active exploitation
- The CISA Known Exploited Vulnerabilities (KEV) catalog tracks vulnerabilities being actively exploited in the wild. A CVSS 6.5 vulnerability on the KEV list should be prioritized above a CVSS 9.0 vulnerability with no known exploitation. The Exploit Prediction Scoring System (EPSS) provides probability estimates of exploitation within 30 days.
Effective vulnerability management combines CVSS base scores with environmental context, asset criticality, threat intelligence and exploitation data. Organizations that patch strictly by CVSS score will misallocate resources by over-prioritizing theoretical threats while under-prioritizing actively exploited vulnerabilities on high-value assets.
How Sherlock CVE Blog Posts Include Detection Signatures
Every CVE analysis published on the Sherlock Forensics Intelligence blog goes beyond the NVD advisory. Each post includes the CVSS score breakdown with plain-language impact analysis, the attack vector explained for non-specialist stakeholders and detection signatures that security teams can deploy immediately.
Detection signatures in Sherlock CVE posts cover network-level indicators (Snort/Suricata rules for identifying exploit traffic patterns), endpoint indicators (file hashes, registry modifications, process behaviors associated with post-exploitation) and log-based detection queries (SIEM queries for identifying exploitation attempts in web server logs, authentication logs and application logs).
This approach bridges the gap between vulnerability disclosure and operational defense. A CVSS score tells you how bad a vulnerability is. A detection signature tells you whether someone is trying to exploit it in your environment right now.
CVSS v3.1 vs. CVSS v4.0
CVSS v4.0 was released by FIRST in November 2023 and introduces several improvements over the widely deployed v3.1. The most significant change is the addition of supplemental metric groups that capture threat context (active exploitation, automatable attacks) and environmental adjustments (safety impact, recovery capability, value density) directly within the scoring framework.
CVSS v4.0 also separates scoring nomenclature into CVSS-B (base only), CVSS-BT (base plus threat) and CVSS-BTE (base plus threat plus environmental). This makes it explicit which factors are included in a given score. Most CVE databases and scanning tools are transitioning from v3.1 to v4.0 through 2026. During the transition period, many advisories publish both scores.
External Resources
For additional guidance on vulnerability scoring and management: