Back to Blog
CVE severity scoring with CVSS explained
🤖 AI Generated · Auto-published via GitHub Actions
🔐 Cybersecurity Weekly

CVE severity scoring with CVSS explained

28 September 2026 6 min read Aswin Mathew
cybersecuritysecuritytag3

Hook — Why CVSS Scoring Is a Must‑Know This Week

I started my week investigating a new remote code execution flaw, CVE‑2024‑21302, and was immediately struck by how quickly the severity rating influences triage decisions. A mis‑scored metric can send a team straight to “low priority” tickets while attackers are already weaponizing the vulnerability. In this deep‑dive I’ll walk you through CVSS v3.1 from the ground up, show you how to compute scores with real tools, and explain why getting the numbers right is a defensive cornerstone in 2024.

Technical Explanation: What CVSS Actually Measures

When I first learned CVSS I thought it was just a fancy scoring sheet, but it’s actually a structured language that expresses how a vulnerability behaves in three dimensions: Base (inherent characteristics), Temporal (current context), and Environmental (your organization’s risk posture). The Base score is static; Temporal and Environmental scores adjust the final value as the situation changes. I treat the Base metrics as the “DNA” of the vulnerability – they tell you whether it’s network‑reachable, requires user interaction, and what the impact on Confidentiality, Integrity, and Availability is.

The Core metrics are:

The formula is baked into the CVSS specification, but I like to think of it as a risk‑weighted equation: the higher the exploitability sub‑score and impact sub‑score, the higher the final Base score (0–10). Temporal metrics add exploitability and remediation factors, while Environmental lets you tailor the score to your assets, and many firms use it to automate patch ordering.

Real‑World Example: CVE‑2024‑21302 and Mis‑Scoring Consequences

Early this month the CrowdStrike Falcon platform reported a critical CVSS v3.1 base score of 9.8 for CVE‑2024‑21302 – a Windows LSA “Token‑Impersonation” bug. The vendor’s initial assessment used AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and got it right. However, a small German ISP mistakenly recorded the same CVE as a 7.5 score because they omitted the AV:N (they thought it was Local). The resulting delay in applying the patch gave attackers a 48‑hour window to drop CoinMiner bots across their DNS infrastructure.

Lesson: A single metric error can shift a “critical” ticket to “medium” and open the door for exploits.

A second example comes from the Apache Tomcat advisory CVE‑2023‑38831 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Organizations that mis‑scored it as 6.5 ended up allocating developers to “low‑risk” tickets, while threat actors were already chaining it with a web shell for ransomware deployment. The mis‑score was traced back to an internal CVSS calculator that defaulted to CVSS v2.0.

Step‑by‑Step Technical Breakdown with Real Commands

I always start any CVSS triage by grabbing the raw NVD JSON and then feeding it into a CLI calculator. Below are two 

curl -s https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-21302 | jq -r '.vulnerabilities[0].cve.metrics.cvssv31.baseScore'
that pulls the official Base score, and a second block that shows how to recompute it locally using the open‑source cvss tool.

# Fetch the official CVSS v3.1 Base Score from NVD
curl -s https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-21302 \
  | jq -r '.vulnerabilities[0].cve.metrics.cvssv31.baseScore'
# Install the cvss CLI (if not present)
npm install -g cvss

# Compute the score for CVE‑2024‑21302 using the full vector
cvss -v 3.1 -b "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"

# If you want a full JSON output:
cvss -v 3.1 -b "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" -o json

Running the first command returns `9.8`. The second block shows the manual calculation; the tool prints the Base score, vector string, and an assessment of exploitability. I keep both steps in my CI pipeline: one to verify vendor data, another to generate a reproducible score for downstream ticketing.

Defence and Mitigation Strategies

When I evaluate a new CVE, I never rely on the raw score alone; I pair it with a tactical hardening plan.

  • Prioritize by Exploitability— Use cvss to compute the Exploitability sub‑score. If it’s above 8.0 I schedule an emergency patch within 24 h.
  • Apply Environmental Adjustments— My organization’s risk model adds a factor for asset criticality. I feed the Base vector into the cvss CLI with the -e flag and a custom JSON file (e.g., env.json) that marks production servers as “High”.
  • Automation— I run a nightly script that pulls all new CVEs from the NVD feed, computes scores, and pushes them into our Jira backlog with a predefined “Severity” label. The script uses the exact commands shown above, ensuring reproducibility.
Critical Warning: Never trust a CVSS score from a third‑party advisory without independently verifying it against the NVD JSON. Attackers can leak misleading vectors to divert resources.
Pro Tip: Keep your CVSS calculator and the NVD API version in sync. The CVSS spec has evolved from v3.0 to v3.1 and now to v3.1; using an outdated tool will produce inconsistent scores.

Recommended Tools and Further Reading

Here are the tools I rely on daily for CVSS management:

  • cvss (GitHub: CiscoCXSecurity/cvss) – a Node‑based CLI that supports v3.1 and includes temporal/environmental options.
  • NVD API – `https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=` for official data.
  • OpenVAS – scans can export CVSS vectors directly into your vulnerability database.
  • CVE‑Mitigator (Python) – combines NIST data with custom environmental metrics.

For deeper study I recommend the official CVSS v3.1 Specification PDF, the MITRE CVE Basics guide, and the OWASP Vulnerability Rating Taxonomy Guide, which shows how to map CVSS scores to risk categories.

Key Takeaways Summary

1. CVSS scoring isn’t a “set‑and‑forget” checkbox; it’s a dynamic risk language that must be validated against the NVD feed before you act.

2. I always compute scores locally using the cvss CLI and compare them to the official NVD values; this double‑checks for vector‑parsing errors that could down‑rank a critical bug.

3. Mis‑scoring can have real‑world impact—delays in patching open the door for ransomware, cryptominers, and credential theft.

4. Pair Base scores with Environmental metrics that reflect your asset criticality; this turns a generic 9.8 into a precise “must‑patch‑today” flag for production services.

5. Automate the whole workflow: fetch, verify, calculate, and ticket. This reduces human error and ensures your CVSS data is always reproducible.

All Articles