What is a CVE? A CVE (Common Vulnerabilities and Exposures) is a unique public identifier, such as CVE-2014-6271, that names one specific security vulnerability so that vendors, scanners, and defenders all talk about the same flaw. A CVE tells you which bug you are dealing with; it does not tell you how urgently you need to fix it. That decision comes from scoring and context.
Every week brings a flood of newly disclosed vulnerabilities, and understanding the system behind them helps you separate genuine emergencies from background noise. This guide explains how CVE IDs work, how to read a CVE record and its CVSS score, and how to prioritize the vulnerabilities that actually matter in your environment.
What Is a CVE?
CVE stands for Common Vulnerabilities and Exposures. A CVE ID is simply a unique identifier for a publicly disclosed vulnerability. It is a naming system, not a database of fixes, and its job is to give everyone a common reference. The program is run by the CVE Program, which publishes the official CVE records.
A CVE ID has a fixed format: CVE-YEAR-NUMBER. The year is when the ID was assigned or reserved, not necessarily when the bug was found or made public, and the number has at least four digits with no upper limit. For example, CVE-2014-6271 is the original Shellshock vulnerability in Bash.
Who Assigns CVE IDs?
CVE IDs are assigned by authorized organizations called CNAs (CVE Numbering Authorities). Many large software vendors are CNAs for their own products, and some security research organizations and CERTs can assign IDs for a wider scope. The CNA reserves an ID, and the CVE record is published once the vulnerability is disclosed.
How to Read a CVE Record
A CVE record on its own is short. The useful detail usually comes from the record plus databases that enrich it, such as the NIST National Vulnerability Database (NVD). When you open a CVE, look for these fields:
| Field | What it tells you |
|---|---|
| Description | The affected product, the type of flaw, and what an attacker can achieve. |
| Affected versions | Which releases are vulnerable and which version contains the fix. |
| CVSS score and vector | The technical severity and the conditions needed to exploit the flaw. |
| CWE | The weakness category, for example CWE-78 (OS command injection). |
| References | Vendor advisories, patches, and write-ups. Always read the vendor advisory. |
How Severity Is Scored: CVSS
Most CVEs come with a CVSS (Common Vulnerability Scoring System) score from 0.0 to 10.0, maintained by FIRST. The score reflects factors like how the flaw is reached, attack complexity, whether authentication or user interaction is needed, and the impact on confidentiality, integrity, and availability.
| CVSS score | Severity rating |
|---|---|
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
Reading a CVSS Vector String
The number is a summary. The vector string explains it. Here is a typical CVSS v3.1 vector for a critical, remotely exploitable flaw:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Base score 9.8)- AV:N (Attack Vector: Network): reachable over the network.
- AC:L (Attack Complexity: Low): no special conditions are needed.
- PR:N / UI:N: no privileges and no user interaction are required.
- S:U (Scope: Unchanged): the impact stays within the vulnerable component.
- C:H / I:H / A:H: high impact on confidentiality, integrity, and availability.
Reading the vector is often more useful than the score. A flaw that needs local access (AV:L) or high privileges (PR:H) is a very different risk from one any internet user can trigger.
CVSS v4.0 vs v3.1
FIRST published CVSS v4.0 in November 2023, and you will now see both versions in advisories. v4.0 adds an Attack Requirements metric, separates impact on the vulnerable system from impact on subsequent systems, and uses labels such as CVSS-B (base only) and CVSS-BT (base plus threat) so you know which metrics went into the number. The severity bands in the table above are the same in both versions, but scores are not directly comparable, so always note which version you are looking at.
Why the CVSS Score Isn’t Everything
A high score does not automatically mean you must panic. CVSS base scores measure technical severity, not the risk to your organization. Context matters: is the affected software even in your environment, is it internet-facing, and is there a public exploit? A medium-rated bug on an exposed system can be more dangerous than a critical one buried behind other controls.
How to Prioritize Vulnerabilities in the Real World
Combine the CVSS score with real-world exploitation signals and your own asset context. Two free, authoritative signals help most:
- CISA Known Exploited Vulnerabilities (KEV) catalog: a list of CVEs with evidence of active exploitation. If a CVE in your environment is on KEV, treat it as urgent.
- EPSS (Exploit Prediction Scoring System): a model from FIRST that estimates the probability that a published CVE will be exploited in the wild in the next 30 days.
A simple, repeatable triage order looks like this:
- Confirm exposure. Is the affected product and version actually deployed? Use your asset inventory, not assumptions.
- Check active exploitation. Is the CVE on the KEV catalog or reported as exploited by the vendor?
- Check likelihood. A high EPSS probability means exploitation is likely soon even if it is not confirmed yet.
- Weigh severity and asset value. Use the CVSS vector and how critical and exposed the system is (internet-facing, holds sensitive data, domain controller).
- Patch or mitigate, then verify. Apply the fix, or a vendor workaround if a patch is not available, and confirm the vulnerable version is gone.
For a worked example of this process on a recent critical flaw, see our PHP2Shell CVE analysis, which covers affected versions, verification, and detection.
Common Mistakes
- Patching purely by CVSS score and ignoring exploitability and exposure.
- Chasing every new disclosure and burning out the team on low-risk issues.
- Comparing CVSS v3.1 and v4.0 scores as if they were the same scale.
- Trusting a third-party summary without reading the vendor advisory for affected and fixed versions.
Best Practices
Maintain an accurate asset inventory, subscribe to reliable vulnerability feeds and vendor advisories, track the KEV catalog, and build a repeatable patch prioritization process with clear timelines for each risk level. Keep operating systems current too: our guides on Windows updates and Patch Tuesday and Linux package security cover the patching side.
Frequently Asked Questions
What is the difference between a CVE and a CVSS score?
A CVE is the identifier that names a vulnerability. CVSS is a separate scoring standard that rates its technical severity from 0.0 to 10.0. One CVE can have scores from different sources, for example the vendor and NVD.
Where can I look up CVE details?
Search the official record on cve.org, enriched data on the NVD, and the vendor’s own security advisory. Always confirm affected and fixed versions against the vendor source.
Does every vulnerability get a CVE?
No. CVEs are assigned to publicly disclosed vulnerabilities that fall within a CNA’s scope. Flaws in custom in-house code, or issues fixed silently, often never receive one, which is why your own testing still matters.
Conclusion
CVEs and CVSS give the industry a shared language for vulnerabilities, but smart prioritization depends on context, not just the score. Confirm exposure, check KEV and EPSS, read the CVSS vector, and patch what attackers are actually using first.