A CVE is a public identifier for one specific vulnerability in one product, so that vendors, scanners and advisories all refer to the same flaw. CVSS is a separate standard that scores how severe exploiting it would be, from 0 to 10, under standard assumptions. The identifier says what the problem is, the score how bad it could be; neither says whether anyone is exploiting it.
What a CVE identifier is and is not
The Common Vulnerabilities and Exposures programme, operated by MITRE and sponsored by the US Cybersecurity and Infrastructure Security Agency, assigns identifiers of the form CVE-YYYY-NNNNN: the year the ID was reserved, then a sequence number of four or more digits. Since 2014 the number can be any length, so CVE-2024-3094 and CVE-2021-44228 are both valid. The year is when the identifier was allocated, which is usually but not always the year the vulnerability was disclosed, and it says nothing about when the bug was introduced.
Identifiers are handed out by CVE Numbering Authorities (CNAs): software vendors, open-source projects, security companies, national bodies and bug-bounty platforms that have been authorised to assign IDs for vulnerabilities in their own scope. When Apache assigns an ID for a flaw in Log4j, Apache is the CNA. MITRE acts as the CNA of last resort for anything without a more specific one. A CVE record contains a short description, the affected product and versions, and references to advisories; it does not itself contain a score, a fix or exploit details.
The value of a CVE is coordination. Before the system existed, the same bug might have five names from five vendors and no way to tell whether two scanners were reporting one problem or two. A CVE is a primary key. It is not an assessment: a CVE can describe a flaw that is trivial or catastrophic, real or disputed, patched for a decade or unpatchable. Treat the presence of a CVE as "someone documented this", nothing more.
Where the score comes from: NVD and the CNAs
Most CVE records are enriched by NIST's National Vulnerability Database, which adds a CVSS score, a weakness classification (CWE) and machine-readable product identifiers (CPE) that scanners match against detected versions. Since 2024 the CNAs themselves have been asked to supply CVSS scores with their records, and NVD's enrichment has at times lagged behind the flow of new CVEs, so a fresh vulnerability may have a vendor score, an NVD score, both or neither for a while. Vendor and NVD scores frequently disagree by a point or more because they make different assumptions about configuration. When you see two scores, the vector strings tell you why they differ.
How CVSS v3.1 scores are built
The Common Vulnerability Scoring System is maintained by FIRST. Version 3.1, published in 2019, is still the most widely reported. Its Base score is computed from eight metrics describing the vulnerability itself, independent of any particular deployment: four exploitability metrics and three impact metrics, plus Scope. The score is published with a vector string that lists every metric value, and the vector is the part worth reading.
| Metric | Values | Question it answers |
|---|---|---|
| Attack Vector (AV) | N network, A adjacent, L local, P physical | From how far away can it be exploited? |
| Attack Complexity (AC) | L low, H high | Does it need conditions outside the attacker's control? |
| Privileges Required (PR) | N none, L low, H high | Must the attacker already have an account? |
| User Interaction (UI) | N none, R required | Must a victim do something, such as click a link? |
| Scope (S) | U unchanged, C changed | Does exploitation affect components beyond the vulnerable one? |
| Confidentiality / Integrity / Availability (C, I, A) | N none, L low, H high | How much can be read, altered or made unavailable? |
Two example vectors, both real and worth memorising as reference points:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Base 9.8 (Critical)
remotely exploitable, no preconditions, no account, no user action, full compromise
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N Base 6.1 (Medium)
the standard vector for reflected cross-site scripting
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Base 10.0 (Critical)
CVE-2021-44228, Log4Shell: same as the first, with scope changedThe qualitative ratings map the number to a word: 0.0 None, 0.1 to 3.9 Low, 4.0 to 6.9 Medium, 7.0 to 8.9 High, 9.0 to 10.0 Critical. Scanners, including Scan.now, borrow this scale for their own severities, which is convenient but means the word "high" can come from a computed CVSS score or from an analyst's judgement about a missing header, and the two are not equivalent. How to Read a Security Scan Report deals with that distinction.
Version 3.1 also defines Temporal metrics (exploit maturity, remediation level, report confidence) and Environmental metrics (how much confidentiality, integrity and availability matter to you, and which modified base values apply in your deployment). Almost nobody publishes them, and almost every score you will see is a bare Base score, which is precisely the score that knows nothing about your situation.
What changed in CVSS v4.0
CVSS v4.0, published in November 2023, addresses the most common complaints about 3.1. Scope, which was widely misunderstood, is gone; in its place the impact metrics are split into the Vulnerable System (VC, VI, VA) and any Subsequent System (SC, SI, SA). A new Attack Requirements (AT) metric separates preconditions in the target from attack complexity proper, and User Interaction gains a middle value, Passive, for cases where the victim need only visit a page. Temporal became Threat, reduced to a single Exploit Maturity metric, and a set of Supplemental metrics (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency) carry context without affecting the number. The standard also introduced explicit nomenclature so you know what a score includes: CVSS-B is base only, CVSS-BT adds threat, CVSS-BE adds environmental, CVSS-BTE all three.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N CVSS-B 9.3 (Critical)That is the v4.0 equivalent of the 9.8 vector above; the maximum 10.0 is reserved for flaws that also fully compromise subsequent systems. Adoption is gradual: NVD publishes both where available, many CNAs still score in 3.1, and scanners report whichever the source provides. Do not compare a 3.1 number directly with a 4.0 number; compare vectors.
What the score does not measure
CVSS answers "if this were exploited under standard assumptions, how bad would it be?" It explicitly does not answer three questions that decide what you should fix first.
- Is it being exploited? A 9.8 that no attacker has ever used is, this week, less urgent than a 7.5 with a public exploit in every automated toolkit.
- Is it reachable in my deployment? A critical flaw in a component your configuration never loads, or behind authentication you do not expose, has a different real severity than its Base score.
- Is it real for my version? Version-based detection assumes upstream numbering. A Debian or Red Hat package at an "old" version often carries the fix backported, which is the single largest source of false positives in scan reports.
Two public data sources fill the first gap. CISA's Known Exploited Vulnerabilities (KEV) catalogue lists CVEs with confirmed exploitation in the wild, with a required remediation date for US federal agencies under Binding Operational Directive 22-01; for everyone else it is the shortest credible "fix this now" list available. EPSS, the Exploit Prediction Scoring System from FIRST, publishes a daily probability, from 0 to 1, that each CVE will be exploited in the next 30 days, derived from observed exploitation and vulnerability characteristics. Neither replaces CVSS; together they turn a severity into a priority.
Prioritising a list of twenty CVEs
- Confirm each one applies. Check whether the detected version is really vulnerable, whether a distribution backport fixed it, and whether the vulnerable feature is used and exposed. This step removes most of the list.
- Fix anything in KEV immediately, regardless of score. Exploitation is not hypothetical.
- Fix anything with a high EPSS score or a public exploit next, starting with those reachable without authentication (
AV:N/PR:N). - Then work by CVSS, reading the vector: unauthenticated, network-reachable, no-interaction flaws before those needing a logged-in attacker or a victim's click.
- Batch the rest into the normal update cycle. A low-scored CVE in a library you update monthly does not need its own ticket.
Where CVEs appear in a Scan.now report
An external, passive scan sees CVEs in one main place: the JavaScript library scanner and the website scanner identify front-end libraries and their versions from the page and match them against the Retire.js vulnerability database, reporting each match under JavaScript library with known vulnerabilities with the CVE, its severity and the version that fixes it. Server-side software is different: a version in a Server or X-Powered-By header is reported as a disclosure under Server version disclosure, not as a list of CVEs, because a header cannot tell us whether the distribution has backported fixes and we would rather report nothing than report false positives. Protocol-level weaknesses such as deprecated TLS versions are reported under their own checks, since they are configuration states rather than product bugs. This is deliberate: a passive scanner should report what it can verify, and CVE matching from a version string is a lead, not a verification. The browser update guide shows the same identifiers from the client side, where a CVE in your browser is the reason the update prompt exists.
Our position: a CVSS number without its vector is a headline, and a headline is not a plan. Read the vector, check KEV, check EPSS, confirm the version, and then decide. That takes five minutes per finding and it is the difference between a report that produces panic and one that produces a schedule. The broader model of what a scan can and cannot establish is in the website security hub.
