A CVE, short for Common Vulnerabilities and Exposures, is a unique public identifier for one specific flaw in a piece of software or hardware, written in the format CVE-YYYY-NNNNN. MITRE runs the program, thousands of vendor-run CVE Numbering Authorities hand the IDs out, and anyone can look one up to find a description, the affected products and versions, a severity score and links to patches.
Here is the part most people get wrong on the first try: a CVE is a name, not a verdict. It tells you a flaw has been disclosed and given a shared label. It does not tell you whether your systems are running the affected code, whether anyone is attacking it, or how urgently you should drop what you are doing.
So “what is a CVE and how to read one” is really two questions. The first is what the identifier means. The second, and the more useful one, is how you move from that identifier to a decision about your own machines. This guide walks through both, in the order you would actually do the work.
Table of Contents
- What Is a CVE?
- What Does a CVE Number Tell You?
- How to Read a CVE Record
- What Do CVSS Scores Mean?
- How Do You Check Whether a CVE Affects Your System?
- What Is the Difference Between a CVE and a Vulnerability Scan?
- How to Use CVE Information Responsibly
- Frequently Asked Questions
- What is the format of a CVE number?
- What is the difference between CVE and CVSS?
- What is the difference between CVE and CWE?
- How do you find CVE vulnerabilities that affect your systems?
- Are zero-day vulnerabilities assigned CVEs?
- What does it mean when a CVE is Reserved or Rejected?
- Conclusion
What Is a CVE?
A CVE is a standardized reference that names one publicly disclosed vulnerability so everyone can talk about the same bug. Before the program existed, researchers and vendors described flaws in prose, which made cross-referencing painful. The CVE list launched in 1999 to fix exactly that.
The identifier gets assigned by a CVE Numbering Authority, usually the vendor that owns the affected product, sometimes a third-party research group or a CERT coordination centre. The record is then published to the CVE list and mirrored into databases such as the NIST National Vulnerability Database.
It helps to keep four things apart, because they get blurred constantly:
- A CVE is the identifier and the record attached to it.
- A vendor advisory is the vendor’s own write-up, which is where the real fix details live.
- A scanner alert is your tool telling you it matched something on a host. It points at a CVE; it does not confirm the flaw is exploitable there.
- An exploit is working attack code. Its existence is a separate fact from the CVE’s existence.
Records also carry a status. You will see Reserved for IDs handed out but not yet published, Published for live records, Rejected when an ID turns out to be invalid or a duplicate, and Modified when the details change after publication. Seeing Reserved in a tool usually means the ID is allocated but the details have not gone public yet.
What Does a CVE Number Tell You?
A CVE identifier has three parts, and each one carries a different piece of information.
- CVE — the literal prefix, present on every identifier in the program.
- YYYY — the four-digit year in which the ID was reserved, not necessarily the year the bug was discovered or exploited.
- NNNNN — a sequence number that makes the ID unique within that year.
That is the whole format: CVE-2021-44228 is the 44228th identifier reserved in 2021. Nothing in the number encodes severity, the vendor, or the type of bug. Any tool that claims to derive risk from the digits themselves is reading tea leaves.
The key property is stability. Once an ID is published it never changes and is never reused, even if the description, the affected versions and the score are all revised later. That is what lets a scanner from one vendor and a patch note from another refer to the same flaw without any mapping work in between.
How to Read a CVE Record
Records look different in every database, but the same information is there. Knowing which field answers which question saves a lot of time.
| Field | What it tells you | Read it for |
|---|---|---|
| Description | A prose summary of the flaw | The actual mechanism, in words |
| Affected products | Vendor, product and version ranges | Whether your build is in range |
| Published and modified dates | When it went live and when it last changed | Whether the details are fresh |
| Metrics | CVSS base score plus the vector string | Severity and the reasoning behind it |
| Weakness | A CWE identifier such as CWE-79 | The bug class, for pattern matching |
| References | Vendor advisories, patches, write-ups | Your actual next step |
| Status | Reserved, Published, Rejected, Modified | Whether to trust the record |
| Source | Which CNA published it | How much vendor context to expect |
The vector string in the metrics section is the most under-used part of a record, because it explains the score rather than just asserting it. The affected version list is the most important field in practice, and it is also the one most often missing or vague.
Working out how to read one of these efficiently means starting at the description to understand the mechanism, moving to the affected products to test it against your inventory, then reading the references for the fix. The score is context for that sequence, not a substitute for it.
What Do CVSS Scores Mean?
CVSS, the Common Vulnerability Scoring System, is a separate framework that rates severity on a 0.0 to 10.0 scale. The CVE identifies the flaw; CVSS describes how bad it is under stated conditions.
A CVSS v3.1 base score is computed from eight metrics, and the vector string spells them out in order:
| Metric | Abbreviation | Question it answers |
|---|---|---|
| Attack Vector | AV | Network, adjacent, local or physical |
| Attack Complexity | AC | How special the conditions are |
| Privileges Required | PR | Does the attacker need access first |
| User Interaction | UI | Must a person be tricked into something |
| Scope | S | Does impact cross a security boundary |
| Confidentiality | C | Data exposure impact |
| Integrity | I | Data and system modification impact |
| Availability | A | Service disruption impact |
Base metrics assume the worst reasonable case, which is why scores skew high across the catalog. Temporal metrics adjust for factors that change after publication, such as an exploit appearing or a patch shipping. Environmental metrics let you tune the score to your own deployment.
| Band | Score range | Common shorthand |
|---|---|---|
| None | 0.0 | Informational |
| Low | 0.1 to 3.9 | Minor |
| Medium | 4.0 to 6.9 | Needs attention |
| High | 7.0 to 8.9 | Schedule a patch |
| Critical | 9.0 to 10.0 | Drop other work |
A 9.8 means an unauthenticated attacker over the network with no user interaction can compromise confidentiality, integrity and availability across a scope boundary, under the assumptions baked into the base score. It does not mean an exploit exists. Plenty of 9.8s sit unexploited for years, and plenty of actively exploited bugs carry a 7.x.
For prioritisation, cross-check two things. CISA’s Known Exploited Vulnerabilities catalog lists the small set of flaws confirmed to be exploited in the wild, and EPSS estimates the probability a flaw will be exploited in the next 30 days. Both matter more to your queue than a Critical band label does.
How Do You Check Whether a CVE Affects Your System?
Matching a CVE to a real machine takes a deliberate sequence. Skipping straight to the score is how teams patch the wrong things for weeks.
- Pin the exact product and version. Not “we run Apache” but the precise build, including service pack or patch level. Most machines run something older than the docs suggest.
- Read the affected version ranges. Each database expresses them differently. Some list exact versions, some ranges like “before 2.14.1”, some a git commit, some a configuration state rather than a version at all.
- Check the operating system build too. Many backported fixes never bumped the application version, so the vendor ships a package revision instead. Two hosts claiming the same app version can differ.
- Confirm reachability. If the vulnerable component runs on a box with no inbound path from untrusted networks, your actual risk is lower than the base score implies. Say so in the ticket rather than silently dropping it.
- Check the configuration preconditions. A fair share of critical CVEs only apply when a non-default option is enabled.
- Record the verdict. Affected and patching, affected and mitigated, not affected because of X, or needs deeper analysis. Write it down; the same CVE will be re-flagged next scan day.
Product matching is automated through CPE identifiers, which are structured strings naming vendor, product and version. They work well on common software and fall apart on obscure appliances, bundled forks and anything with a customized build. When a match is uncertain, assume affected until proven otherwise.
What Is the Difference Between a CVE and a Vulnerability Scan?
A CVE is a database entry about a flaw. A vulnerability scan is one method of checking whether your inventory matches that entry. Confusing the two is the source of most alert fatigue.
| Source | It can tell you | It cannot tell you |
|---|---|---|
| CVE record | A flaw is public and what it affects | Whether you run it, or whether anyone attacks it |
| Scanner output | A fingerprint matched on this host | That the flaw is reachable or exploitable |
| Vendor advisory | The fix, the affected builds, workarounds | Whether attackers are using it |
| Patch changelog | That a fix exists in this release | Whether you deployed that release |
| KEV and threat feeds | Confirmed exploitation somewhere | Whether you are the target |
None of these rank your work for you. That ranking comes from combining inventory accuracy with reachability, severity and evidence of active exploitation, which is a judgement call rather than a lookup.
How to Use CVE Information Responsibly
Good habits compound here. The first is an accurate asset inventory, because every downstream decision depends on knowing what you actually run, down to the build.
Prioritise on evidence rather than on band labels. A KEV-listed flaw outranks an unlisted Critical every time, and an internet-facing box carrying a Medium outranks an isolated host carrying a Critical.
For developers, fold the check into the pipeline. Scan dependency manifests and container images on every build so a newly published record surfaces in the next run rather than at the next quarterly review. An SBOM makes this far more accurate because it lists what is actually shipped, not what is declared as a dependency.
Treat updates as changes that need testing, not keystrokes. Patch, confirm services restarted, then confirm the version on disk. Plenty of teams discover months later that the fix was installed but the process never reloaded it.
Watch the logs after patching. If a scanner keeps flagging the record, something in the environment disagrees with the ticket, and that discrepancy is worth chasing down.
Finally, keep exploit detail proportionate. Researchers need proof-of-concept code to confirm bugs. Defenders need enough to write detection rules. Publishing working attack code for an unpatched flaw helps people who should not have it, so follow the disclosure timelines the vendor’s advisory describes rather than racing to publish.
Frequently Asked Questions
What is the format of a CVE number?
A CVE identifier has three parts: the literal prefix CVE, a four-digit year in which the ID was reserved, and a sequence number that makes it unique within that year. CVE-2021-44228 means the 44228th identifier reserved in 2021. The year reflects reservation, not discovery or exploitation, and the digits encode nothing about severity or vendor.
What is the difference between CVE and CVSS?
A CVE is the identifier that names a specific vulnerability. CVSS is the scoring system that rates how severe that vulnerability is on a 0.0 to 10.0 scale, using metrics like attack vector and impact. One record can carry several CVSS scores from different sources, and none of them tell you whether the flaw affects your systems.
What is the difference between CVE and CWE?
A CVE names one specific flaw in one specific product. A CWE, or Common Weakness Enumeration, names a category of flaw, such as improper input validation or missing authentication. A single CWE can describe hundreds of separate CVEs across hundreds of products, which is why CWE is useful for pattern matching rather than for tracking an individual issue.
How do you find CVE vulnerabilities that affect your systems?
Start with your asset inventory, then look up each product in the CVE list or the National Vulnerability Database and compare the published affected version ranges against the builds you actually run. Where product matching is ambiguous, treat the host as affected until you confirm otherwise, and record the reasoning so the same alert does not need re-deciding next scan day.
Are zero-day vulnerabilities assigned CVEs?
A zero-day is a flaw being exploited before the vendor has a fix, and the term describes timing rather than record status. A CVE can be published while a flaw is still unpatched, so a published CVE and a zero-day condition can overlap on the same flaw. Not every exploit gets a CVE either, since disclosure only obliges a CNA to assign one when the flaw is publicly disclosed through it.
What does it mean when a CVE is Reserved or Rejected?
Reserved means an identifier has been handed out by a CVE Numbering Authority but the record is not public yet. Rejected means the record was published and then withdrawn as invalid, a duplicate, or not a genuine vulnerability. A reserved ID in your tooling usually signals that details have not been disclosed, and a rejected one should be closed rather than tracked.
Conclusion
Open the authoritative record first, every time. Read the description, pin the affected version range against the exact build on your host, then follow the vendor advisory for the fix and verify on the machine that the update actually took effect. The CVE identifier gets you there in seconds, but it is the version comparison that turns it into a decision you can still defend when budget day comes.
