What Is a CVSS Score?

CVSS (Common Vulnerability Scoring System) is a standardized method to assess the severity of software vulnerabilities. It outputs a score from 0.0 to 10.0 based on multiple impact and exploitability factors.

How It Works

1. Select values for each vector (e.g., AV, AC, PR).

2. The base score and vector string are automatically calculated.

3. Copy and use in your security reports or audits.

User Interaction (UI)

The User Interaction metric measures whether a vulnerability can be exploited independently or if it requires a user to play an active role.

• None: If this field is set to "None," it means the attacker does not need anyone else's help—the vulnerability can be triggered without any user involvement, which tends to increase the risk.

• Required: On the other hand, if "Required" is selected, exploitation is only possible if a legitimate user takes some specific action first, such as clicking a link, opening an email attachment, or performing a system installation. This user dependency can sometimes reduce the likelihood of a successful attack.

By assessing this metric, CVSS v3.1 helps you understand how much an attack relies on human interaction as opposed to being fully automated.

Availability (A)

When evaluating availability in CVSS v3.1, you'll select from three tiers, each capturing a different level of impact on system uptime and resource access:

• High (Worst): The attacker has the means to fully prevent access to resources in the targeted component. This might manifest as a complete service outage, where users cannot access important systems—either the disruption continues as long as the attack persists, or the damage lingers on even after the attack stops. In some cases, a vulnerability might need to be exploited multiple times, but the end result is a total lockdown for legitimate users.

• Low (Bad): In this scenario, performance may decline, or there are occasional hiccups in resource availability. While the service isn’t completely knocked offline, the impact is tangible—users may experience sluggishness, partial outages, or intermittent interruptions, but there’s no direct, catastrophic outcome for the affected component.

• None (Good): Lucky you—there’s no impact at all. The vulnerability doesn’t touch the system’s uptime or the ability of users to access its resources.

Each rating helps clearly define just how badly an issue might affect your ability to keep services running, making it easier to prioritize fixes where it matters most.

Integrity

When assessing the "Integrity" metric in CVSS v3.1, we're looking at how much an attacker could tamper with protected data or system resources. Here's how the impact is classified:

• High – This is the worst-case scenario. An attacker can freely alter any or all data, or make changes that would have severe, direct consequences—think of someone with the keys to modify vital operating system files or sensitive databases.

• Low – Here, bad things can happen, but they're limited. An attacker might be able to make some unauthorized changes, but either the extent of what they can change is controlled, or those changes don't have immediate, serious effects on the system.

• None – In this scenario, everything holds firm. There's no opportunity for an attacker to tamper with data, so integrity remains intact.

Examples for Each Attack Vector and Privilege Requirement

Attack Vectors (AV)

• Network:
  Picture a classic remote exploit—such as an attacker sending specially crafted packets over the Internet to compromise a web server. These attacks can happen from anywhere, requiring nothing but network access. Think of the infamous WannaCry ransomware that traveled the globe exploiting SMB vulnerabilities.

• Adjacent:
  Here, the attacker has to be on the same local network or within a limited administrative domain. For example, a Wi-Fi-based attack where someone floods a local area network with ARP requests to disrupt service, or an exploit that spreads through a shared VPN without crossing over to the larger Internet.

• Local:
  These attacks require the perpetrator to already have access to the system—perhaps directly at the keyboard, or remotely via a secure shell connection. A classic example? Tricking a logged-in user into opening a malicious file via email (social engineering), or a process that requires exploiting a bug while already logged on.

• Physical:
  If you thought Mission: Impossible, you’re not far off. The attacker must have hands-on access to the hardware, such as extracting encryption keys by briefly connecting to a machine’s memory chips, or plugging in a rogue USB device to exploit direct memory access.

Privilege Requirements (PR)

• None:
  The attacker doesn’t need to be authorized or logged in at all. For instance, exploiting a publicly facing web application vulnerability where anyone on the Internet can launch the attack without any special permissions.

• Low:
  The attacker needs basic user permissions—something like a regular account with no administrative rights. Examples include leveraging a local privilege escalation bug to move from regular user to administrator, or accessing files that aren’t considered sensitive but are still protected from the anonymous public.

• High:
  Here, significant system privileges are required before the attack can happen. The classic case: exploiting a vulnerability that only an administrator or root user could access, possibly to alter core system files or settings.

How CVSS v3.1 Classifies Confidentiality Impact

CVSS v3.1 categorizes the impact on confidentiality into three levels:

• High: This is the worst-case scenario—when sensitive data is fully exposed to an attacker. Think administrator passwords or private encryption keys falling into the wrong hands. If even a portion of restricted information is leaked and causes serious consequences, it lands in this category.

• Low: Here, the attacker gains some access to confidential information, but it’s limited. They might not get to choose what is revealed, or the leaked data doesn’t lead to any immediate, severe fallout. Essentially, there’s a breach, but not one that puts the entire system at risk.

• None: The gold standard—no confidential information is compromised, and everything remains under wraps within the affected component.

Direct vs. Indirect Consequences in CVSS v3.1

While the CVSS v3.1 scoring system breaks down Confidentiality, Integrity, and Availability into High, Low, and None, it also distinguishes between direct and indirect consequences under each category.

• Direct Consequences:
  These occur when an attacker’s actions immediately and seriously impact the component. For confidentiality, this could mean the attacker obtains sensitive information like administrator passwords or encryption keys—data that, once accessed, directly undermines the security of the system. Integrity is similarly affected if an attacker can deliberately and significantly alter protected files or data, causing harm right away. For availability, a direct consequence could be a total denial of service, where legitimate users cannot access resources for a sustained period.

• Indirect Consequences:
  Here, the impact is less straightforward or severe. If the attacker’s access is limited—perhaps only gaining some information, and not necessarily data that leads to grave outcomes—or if they cannot choose what information is accessed, the result is considered an indirect consequence. Losses in integrity or availability are marked as indirect if, for instance, the system suffers from sporadic performance issues, or if changes can occur but without a clear, critical outcome. Overall, indirect consequences do not create an immediate or serious impact on the core functionality or confidentiality of the component involved.

Core Features

• Supports CVSS v3.1 scoring

• Dynamic vector string generation

• Real-time score updates

• Simple UI for fast security assessments

• Ideal for compliance, DevSecOps, and bug bounty submissions

  
  

Example Output

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Score: 9.8 – Critical

Understanding “Worst,” “Worse,” “Bad,” and “Good” in CVSS v3.1

Within the CVSS v3.1 framework, the terms “Worst,” “Worse,” “Bad,” and “Good” help describe the relative severity or favorability of possible options for each metric. Think of them as quick shorthand indicators along a spectrum from the most critical impact to the least.

• Worst: Indicates the most severe or most concerning option for a given metric. For example, if an attack is categorized as “Worst,” like a vulnerability accessible over the Internet, it means the risk is at its highest.

• Worse: Falls just below “Worst” in severity. It’s still quite dangerous, perhaps limited to network neighbors instead of the whole Internet, but not quite as far-reaching as the “Worst” scenario.

• Bad: Suggests a meaningful negative impact or barrier, but it’s not as dire as “Worst” or “Worse.” For instance, successful exploitation might require local access or special privileges, so there’s some limitation to the threat.

• Good: Represents the most favorable or secure scenario for that metric—little to no risk or impact. If integrity or confidentiality is “Good,” it generally means those qualities are unaffected.

In short: “Worst” is your red-alert scenario, “Worse” is a serious warning, “Bad” is a caution, and “Good” means you’re in the clear. These labels

help quickly gauge where on the risk spectrum a particular security condition sits within the broader CVSS framework.

Common Use Cases

• Penetration testing and red teaming

• DevSecOps security gates

• Software patch prioritization

• Security compliance (ISO 27001, SOC 2)

• Bug bounty submissions

Recommended Companion Tools

• Password Generator – for securing endpoints

• Token Generator – for API simulations

• UUID Generator – for unique ID generation in bug tracking

• IP Address Generator – for network simulation