Anatomy of a CVE: From Discovery to Your Patch Queue
Follow a vulnerability through its full lifecycle: discovery, coordinated disclosure, CNA assignment, NVD enrichment, publication, and exploitation, and learn what every field of a CVE entry really tells you.
What a CVE actually is
A CVE (Common Vulnerabilities and Exposures) entry is not a vulnerability. It is a name for one: a globally unique identifier plus a minimal description, so that your scanner, your vendor's advisory, and your threat intel feed can all agree they are talking about the same bug. The program is run by MITRE, sponsored by CISA, and the naming work is delegated to hundreds of CVE Numbering Authorities (CNAs).
That distinction matters, because most of the information you rely on for triage (scores, affected products, exploitation status) is layered on top of the identifier by other parties, on their own timelines. Understanding who adds what, and when, tells you how much to trust each field.
The lifecycle, stage by stage
1. Discovery
Someone finds the bug: an internal engineer, a bug bounty hunter, an academic team, or, in the worst case, an attacker whose exploitation gets caught in the wild. Who finds it first shapes everything downstream. Log4Shell (CVE-2021-44228) was reported to Apache by Alibaba's cloud security team; by the time the patch shipped, exploitation exploded within hours of public disclosure.
2. Reporting and coordinated disclosure
Under coordinated disclosure, the researcher reports privately to the vendor and agrees on an embargo, commonly around 90 days (the deadline Google Project Zero popularized), so a fix can ship before details go public. The alternative paths are full disclosure (details published immediately, vendor ready or not) and the silent path, where the first public evidence of the bug is an incident.
3. Reservation
Early in the process, the vendor or researcher requests an ID from a CNA. Big vendors (Microsoft, Red Hat, Apple, GitHub and several hundred others) are their own CNAs and assign IDs from blocks delegated by MITRE. The entry now exists in the RESERVED state: the ID is public, the details are not. If you have ever clicked a CVE link and found an empty shell, you caught it in this state. The year in the ID (CVE-2024-12345) is the year of assignment, not necessarily of disclosure.
4. Publication
When the embargo lifts, the CNA populates the record: description, affected products and versions, references, credits, and increasingly a CVSS vector and CWE from the CNA itself. The entry flips to PUBLISHED on the CVE List. Records can also end up REJECTED (duplicate, not actually a vulnerability); a rejected ID is never reused.
5. NVD analysis and enrichment
The US National Vulnerability Database ingests the CVE List and adds the analysis layer most tooling depends on:
- CVSS scores: NVD analysts derive a base vector and score, which may differ from the CNA's. Both can be valid readings of the same bug.
- CWE: the weakness class behind the bug (CWE-79 cross-site scripting, CWE-787 out-of-bounds write). Useful for spotting patterns across a vendor or a codebase.
- CPE: machine-readable product identifiers (
cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*) that let scanners match the CVE to your inventory.
This enrichment takes time, sometimes days, sometimes much longer: the NVD backlog that built up during 2024 left thousands of published CVEs waiting for analysis. During that gap, a CVE is real and possibly exploited but nearly invisible to CPE-matching scanners. Do not let "no NVD score yet" read as "not important."
6. Exploitation and the aftermarket
In parallel, and on nobody's schedule, the offensive ecosystem does its work: proof-of-concept code on GitHub, a Metasploit module, exploitation in the wild. Third-party signals attach to the entry: an EPSS probability from FIRST, a CISA KEV listing if exploitation is confirmed, vendor advisories, patches. For a bug like EternalBlue (CVE-2017-0144, patched in MS17-010), this stage rewrote history: the patch preceded WannaCry by two months, and the CVE entry alone never conveyed the urgency.
Reading an entry like an analyst
Here is how each field maps to a triage decision:
| Field | Written by | What it tells you | Watch out for |
|---|---|---|---|
| CVE ID | CNA | Identity, assignment year | Year != disclosure year |
| Description | CNA | Bug class, component, attack surface | Often vague on preconditions |
| Affected versions / CPE | CNA / NVD | Whether you are exposed | Version ranges lag reality |
| CVSS vector | CNA and/or NVD | Theoretical severity and attack preconditions | Scores may disagree; read the vector, not just the number |
| CWE | CNA / NVD | Weakness class | Generic classes hide detail |
| References | CNA | Advisories, patches, write-ups | The write-up is often more useful than the entry |
| EPSS / KEV | FIRST / CISA | Exploitation probability and evidence | Attached later, check freshness |
Three habits pay off:
- Read the vector string, not the score.
AV:N/AC:L/PR:N/UI:Non a network service is a different animal fromAV:L/PR:Hat the same numeric score. - Check the CNA. A vendor-assigned CVE with a detailed advisory usually beats the terse description; some vendors also systematically score low, which is worth knowing.
- Treat the description as a starting pointer. The linked advisory and patch diff tell you what is actually reachable in your deployment.
Having the layers in one view helps. Each entry on vuln.mlab.sh assembles the description, CVSS v3.1 and v4.0 vectors, CWE, affected products, EPSS score, and KEV status across 240k+ CVEs in one page, with a JSON API when you want the same data in a pipeline.
Why the lifecycle matters for your queue
The practical takeaway is about timing. A CVE's danger and its documentation move on different clocks:
- At reservation, defenders know nothing, but the vendor and researcher do. Attackers sometimes do too.
- At publication, the race starts. For modern edge-device bugs, mass exploitation within days of publication is normal.
- Enrichment lags publication, so scanner-driven programs are structurally late on exactly the CVEs that matter most.
- KEV listing lags exploitation by definition.
Build your intake accordingly: watch vendor advisories for your stack directly, treat unenriched CVEs in critical products as guilty until scored, and let the enriched, scored, cross-referenced entry be the confirmation layer rather than the trigger.
A CVE entry is a birth certificate, not a biography. Learn who writes each line and when, and you will stop waiting for paperwork that arrives after the fight has started.
