Reference for CVSS v3.1 and v4.0 metrics, scoring guidance, and the difference between severity and remediation priority. Use when scoring a vulnerability, checking a vendor score, or explaining a CVSS vector.
Installs into .claude/skills of the current project.
Are you the author of Cvss Scoring?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/hermeticormus-cvss-scoring)
---
name: "cvss-scoring"
description: "Reference for CVSS v3.1 and v4.0 metrics, scoring guidance, and the difference between severity and remediation priority. Use when scoring a vulnerability, checking a vendor score, or explaining a CVSS vector."
---
# CVSS Scoring Methodology
> Reference knowledge base for the Common Vulnerability Scoring System (CVSS) v3.1 and v4.0, including metric definitions, scoring guidance, and practical application.
## Knowledge Base
### CVSS v3.1
CVSS v3.1 is the most widely used vulnerability scoring system. It produces a score from 0.0 to 10.0 across three metric groups: Base, Temporal, and Environmental.
#### Base Metrics
Base metrics represent the intrinsic characteristics of a vulnerability that are constant over time and across environments.
**Attack Vector (AV)** -- How the vulnerability is exploited:
| Value | Code | Description | Example |
|-------|------|-------------|---------|
| Network | N | Exploitable via network, no special access needed | Remote code execution via HTTP request |
| Adjacent | A | Requires adjacent network access (same LAN, Bluetooth, etc.) | ARP spoofing attack |
| Local | L | Requires local access (shell, physical keyboard, local app) | Privilege escalation from local user |
| Physical | P | Requires physical access to the device | USB-based attack, cold boot attack |
**Attack Complexity (AC)** -- Conditions beyond attacker control:
| Value | Code | Description | Example |
|-------|------|-------------|---------|
| Low | L | No special conditions required | Sending a crafted HTTP request |
| High | H | Requires specific conditions (race condition, MITM position, specific config) | Exploiting a race condition with tight timing window |
**Privileges Required (PR)** -- Level of privileges needed before exploitation:
| Value | Code | Description | Example |
|-------|------|-------------|---------|
| None | N | No authentication needed | Unauthenticated RCE |
| Low | L | Basic user-level access | Authenticated user exploiting IDOR |
| High | H | Significant privileges (admin) | Admin panel vulnerability |
**User Interaction (UI)** -- Whether a user other than the attacker must participate:
| Value | Code | Description | Example |
|-------|------|-------------|---------|
| None | N | No user interaction needed | Server-side vulnerability exploited directly |
| Required | R | User must perform an action | Clicking a malicious link (XSS), opening a file |
**Scope (S)** -- Whether exploitation impacts resources beyond the vulnerable component:
| Value | Code | Description | Example |
|-------|------|-------------|---------|
| Unchanged | U | Impact limited to the vulnerable component | SQLi affecting only the database |
| Changed | C | Impact extends beyond the vulnerable component | VM escape, XSS (browser is vulnerable component, user's session in different origin is impacted) |
**Impact Metrics (C/I/A)** -- Effect on Confidentiality, Integrity, and Availability:
| Value | Code | Description |
|-------|------|-------------|
| None | N | No impact |
| Low | L | Limited impact, partial data exposure or modification |
| High | H | Total loss of confidentiality, integrity, or availability |
#### Severity Ratings
| Score Range | Rating |
|-------------|--------|
| 0.0 | None |
| 0.1 - 3.9 | Low |
| 4.0 - 6.9 | Medium |
| 7.0 - 8.9 | High |
| 9.0 - 10.0 | Critical |
#### Common Scoring Examples
**SQL Injection (unauthenticated, data extraction)**:
- Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
- Score: 9.1 (Critical)
- Rationale: Network-accessible, no complexity, no privileges, no interaction, high confidentiality and integrity impact
**Reflected XSS**:
- Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N`
- Score: 6.1 (Medium)
- Rationale: Network-accessible, but requires user interaction (clicking link), scope changed (browser context), low impact per occurrence
**Stored XSS (admin panel)**:
- Vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N`
- Score: 5.4 (Medium)
- Rationale: Requires low privileges to inject, still needs victim interaction, scope changed
**Remote Code Execution (unauthenticated)**:
- Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
- Score: 9.8 (Critical)
- Rationale: The worst case -- network-accessible, no barriers, complete system compromise
**Local Privilege Escalation (kernel)**:
- Vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
- Score: 7.8 (High)
- Rationale: Requires local access and low privileges, but gives complete control
**IDOR (data exposure)**:
- Vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N`
- Score: 6.5 (Medium)
- Rationale: Requires authentication (low privileges), reads data but doesn't modify
**SSRF (cloud metadata)**:
- Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`
- Score: 8.6 (High)
- Rationale: Unauthenticated, scope changed (accessing cloud metadata service), high confidentiality impact (credentials)
#### Temporal Metrics
Temporal metrics adjust the base score based on factors that change over time:
**Exploit Code Maturity (E)**:
| Value | Code | Description |
|-------|------|-------------|
| Not Defined | X | Default, no adjustment |
| Unproven | U | No exploit code available |
| Proof-of-Concept | P | PoC exists but not practical |
| Functional | F | Working exploit available |
| High | H | Reliable, automated exploitation (worm, Metasploit module) |
**Remediation Level (RL)**:
| Value | Code | Description |
|-------|------|-------------|
| Not Defined | X | Default |
| Official Fix | O | Vendor-provided patch available |
| Temporary Fix | T | Workaround available |
| Workaround | W | Unofficial mitigation |
| Unavailable | U | No fix or workaround available |
**Report Confidence (RC)**:
| Value | Code | Description |
|-------|------|-------------|
| Not Defined | X | Default |
| Unknown | U | Unconfirmed reports |
| Reasonable | R | Multiple sources, some detail |
| Confirmed | C | Vendor confirmed, detailed analysis available |
#### Environmental Metrics
Environmental metrics customize the score for a specific organization's environment by modifying the impact metrics and adding security requirements:
- **Modified Base Metrics**: Adjust any base metric to reflect the actual environment
- **Confidentiality/Integrity/Availability Requirements**: Rate as Low/Medium/High based on the asset's business criticality
### CVSS v4.0
CVSS v4.0 (released November 2023) provides more granular scoring with additional metric groups.
Key differences from v3.1:
- **Scope removed**: Replaced with explicit "Subsequent System" impact metrics
- **Attack Requirements (AT)**: New metric replacing some aspects of Attack Complexity
- **New supplemental metrics**: Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency
- **Threat metrics**: Replaces Temporal metrics with simplified threat intelligence integration
- **Nomenclature**: CVSS-B (base only), CVSS-BT (base+threat), CVSS-BE (base+environmental), CVSS-BTE (all)
**New metric -- Attack Requirements (AT)**:
| Value | Description |
|-------|-------------|
| None | No special deployment or execution conditions |
| Present | Requires specific conditions (race condition, specific configuration, MITM position) |
**Subsequent System Impact** (replaces Scope):
Separate Confidentiality, Integrity, and Availability impact ratings for the Vulnerable System and the Subsequent System (if impact crosses boundaries).
## Patterns
### Scoring Best Practices
1. **Score the vulnerability, not the exploit**: Base score reflects the worst reasonable outcome, not a specific exploit technique
2. **Scope is about trust boundaries**: Changed scope means the vulnerability in component A impacts component B across a trust boundary (e.g., XSS: browser is vulnerable, web application's session is impacted)
3. **Attack Complexity reflects conditions, not skill**: AC:H means specific conditions must exist (race condition, specific config), not that the attacker needs to be skilled
4. **User Interaction means a victim action**: The attacker must convince a user to do something. Clicking a link counts. Being on the same network doesn't.
5. **Use Environmental scoring for actual risk**: A critical CVE in an air-gapped system is different from the same CVE on an internet-facing server. Environmental metrics capture this.
### Priority vs Severity
CVSS provides severity (how bad the vulnerability is). Priority (what to fix first) requires additional context:
| Factor | Source | How It Modifies Priority |
|--------|--------|------------------------|
| Active exploitation | CISA KEV, threat intel | Massively increases priority |
| Exploit availability | Exploit-DB, Metasploit | Increases priority |
| EPSS score | FIRST EPSS | Probability-based urgency |
| Asset criticality | Business context | Amplifies or reduces priority |
| Exposure level | Network architecture | Internet-facing >> internal |
| Compensating controls | Security architecture | May reduce priority if controls are strong |
| Fix availability | Vendor advisory | No fix = compensating controls only |
| Fix effort | Engineering assessment | Low-effort fixes first for quick wins |
## Anti-Patterns
- **Using only CVSS base scores for prioritization**: Base scores ignore environmental context and threat intelligence. A CVSS 9.8 vulnerability that requires a configuration nobody uses and has no known exploit may be lower priority than a CVSS 7.0 with a Metasploit module actively used in the wild.
- **Scoring inflation**: Maximizing every metric to get the highest score. Score accurately, not dramatically.
- **Ignoring Scope**: Scope:Changed is frequently misassigned. It specifically means the vulnerability crosses a security authority boundary.
- **Treating CVSS as a risk score**: CVSS measures technical severity. Risk = severity x likelihood x asset value. CVSS alone is not risk.
- **One score for all instances**: The same CVE in different environments has different environmental scores. A SQL injection on a public-facing application has different risk than the same bug on an internal tool.
## References
- [CVSS v3.1 Specification (FIRST)](https://www.first.org/cvss/v3.1/specification-document)
- [CVSS v4.0 Specification (FIRST)](https://www.first.org/cvss/v4.0/specification-document)
- [CVSS v3.1 Calculator (FIRST)](https://www.first.org/cvss/calculator/3.1)
- [CVSS v4.0 Calculator (FIRST)](https://www.first.org/cvss/calculator/4.0)
- [EPSS - Exploit Prediction Scoring System](https://www.first.org/epss/)
- [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [NVD - National Vulnerability Database](https://nvd.nist.gov/)