Vulnerabilities, CVE & CVSS

Enumeration left you with services and versions. The next question is: which of these have known weaknesses, and how serious are they? The security industry has shared vocabulary for exactly this — CVE names individual vulnerabilities, CVSS scores their severity, and CWE classifies the underlying weakness types. Knowing how these work lets you turn "the host runs version X" into "the host is affected by CVE-YYYY-NNNNN, scored High, which means…" — the language your report will speak.

The vocabulary

• Vulnerability — a weakness that can be exploited to violate confidentiality, integrity or availability.
• Exploit — the code or technique that takes advantage of a vulnerability.
• Payload — what the exploit delivers once it succeeds (e.g. a shell).
• CVE (Common Vulnerabilities and Exposures) — a unique public identifier for a specific vulnerability in a specific product, like CVE-2021-44228. Managed under MITRE/CISA; each CVE has a description and references.
• CWE (Common Weakness Enumeration) — a catalogue of weakness types (e.g. CWE-89 SQL Injection, CWE-79 Cross-site Scripting, CWE-787 Out-of-bounds Write). Many CVEs map to one CWE.
• CVSS (Common Vulnerability Scoring System) — a standard 0.0–10.0 severity score.
• NVD (National Vulnerability Database) — the US government feed that enriches CVEs with CVSS scores and CWE mappings; where you'll usually look a CVE up.
• KEV (Known Exploited Vulnerabilities) — CISA's list of CVEs known to be exploited in the wild. A CVE on the KEV list deserves priority regardless of its score.

CVE vs CWE — the difference that trips people up

A CWE is the class of mistake ("SQL injection"). A CVE is one instance of a mistake in one product ("SQL injection in Acme CMS 3.2, identified as CVE-2023-XXXXX"). CWE-89 describes SQL injection in general; thousands of CVEs are each a particular SQL-injection bug in a particular product that is an instance of CWE-89. Testers use CWE to talk about categories of finding and CVE to point at the exact bug in the exact software the target runs.

CVSS: how severity is scored

CVSS v3.1 (and the newer v4.0) computes a 0–10 score from a set of metrics. The core Base metrics describe the vulnerability's intrinsic properties:

Metric	Asks	Example values
Attack Vector (AV)	How close must the attacker be?	Network / Adjacent / Local / Physical
Attack Complexity (AC)	How hard to pull off reliably?	Low / High
Privileges Required (PR)	What access is needed first?	None / Low / High
User Interaction (UI)	Must a victim do something?	None / Required
Scope (S)	Can it affect components beyond the vulnerable one?	Unchanged / Changed
Confidentiality / Integrity / Availability (C/I/A)	Impact on each?	None / Low / High

The qualitative bands:

Score	Severity
0.0	None
0.1–3.9	Low
4.0–6.9	Medium
7.0–8.9	High
9.0–10.0	Critical

A vulnerability that is network-reachable, low-complexity, needs no privileges and no user interaction, and fully compromises C/I/A scores near 10.0 — the worst case. One that needs local access, high complexity and only leaks a little information scores low. This is why the same CWE (say, SQL injection) can be Critical in one product and Medium in another: context changes the Base metrics.

Beyond Base there are Temporal metrics (is there a known exploit? a patch?) and Environmental metrics (how important is this asset to this organisation?). A tester often adjusts the raw NVD Base score for the client's environment — a Medium on a throwaway test box may be a High on a customer-data server.

Looking a vulnerability up

Given an enumerated version, you check for known CVEs:

• Search the NVD (nvd.nist.gov) for the product and version.
• Use searchsploit <product> (the offline Exploit-DB CLI) to see if public exploit code exists.
• Nmap's --script vuln and dedicated scanners (Level 3 lesson 1) flag candidates automatically.
• Vendor security advisories give the authoritative affected-version ranges.

Finding a CVE is a lead, not proof. The version may be back-patched, the feature may be disabled, or the exploit may not fire in this configuration. Validation (actually confirming the vuln is present and exploitable) comes next — and is what separates a scanner's noisy output from a tester's confirmed finding.

A worked example (the reasoning, not a live exploit)

Suppose enumeration found a web server reporting an old version of a library, and the NVD lists a CVE for that version: network attack vector, low complexity, no privileges, no user interaction, high confidentiality impact — CVSS ~9.x, Critical. Your reasoning:

1. The version matches the affected range → candidate.
2. Is a public exploit available (searchsploit, Exploit-DB)? → raises likelihood and Temporal score.
3. Is the vulnerable feature actually reachable in this deployment? → validate before claiming it.
4. Is this asset sensitive? → Environmental adjustment for the client.

Only after steps 1–4 do you write it up as a confirmed Critical finding with the CVE, the CVSS vector, evidence of reachability, and the remediation (upgrade to the fixed version).

How It Actually Works

Why does the industry split naming (CVE), classification (CWE) and scoring (CVSS) into three systems instead of one? Because they answer three different questions that change on different timescales:

• CVE is identity. It exists so that everyone — vendors, scanners, testers, defenders — refers to the same bug by the same name. Without a shared identifier, "the Log4j thing" and "that JNDI bug" might be the same vulnerability discussed as if they were different. A CVE is assigned once and never changes meaning; it is a stable anchor.
• CWE is taxonomy. It groups bugs by root cause so that patterns are visible: if most of a product's CVEs map to CWE-89, the product has a systemic input-handling problem, not twelve unrelated bugs. Taxonomy drives fixes at the class level (parameterised queries kill all of CWE-89), which is why your report groups findings by weakness type.
• CVSS is measurement. Severity isn't a property of the bug alone; it depends on how reachable and impactful the bug is, which is why CVSS is a formula over metrics rather than a single number someone picks. Encoding severity as a vector (AV:N/AC:L/PR:N/...) means the score is reproducible and auditable — anyone can see why it's a 9.8, and adjust the Environmental metrics for their own context.

The three together let a tester say something precise and defensible: this exact bug (CVE), an instance of this weakness class (CWE), is this severe in this environment (CVSS), and here is the vector showing why. That precision is what makes a finding actionable rather than alarming.

Common mistakes and pitfalls

• Treating a scanner's CVE match as a confirmed finding. It's a candidate until you validate reachability and configuration.
• Reporting the raw NVD Base score as if it's the final severity. Adjust for the environment — a Critical on an isolated test box may genuinely be lower risk; a Medium on a crown-jewel asset may be higher.
• Confusing CVE and CWE in a report. Say "SQL injection (CWE-89), specifically CVE-2023-XXXXX in Acme CMS 3.2" — class and instance.
• Chasing the highest CVSS score and ignoring the KEV list. A 7.5 that's actively exploited in the wild often outranks a theoretical 9.0 with no known exploit.
• Assuming a version string is accurate. Back-ports and edited banners mean the reported version may not reflect the actual patch level. Validate.

Exercise

1. Pick any product/version your lab enumeration found (or any software on your own machine). Search the NVD for a CVE affecting it. Record the CVE ID, its CVSS v3.1 base score, and the CWE it maps to.
2. For that CVE, write out the CVSS Base vector (AV/AC/PR/UI/S/C/I/A) and explain in plain English what each metric value means for that bug.
3. Explain the difference between CWE-89 and a specific SQL-injection CVE, in two sentences.
4. Check whether your chosen CVE is on CISA's KEV list. Explain how that would change your prioritisation.
5. Describe the four validation steps you'd take before writing a scanner's CVE match into a report as a confirmed finding.