To read an NVD record in two minutes, check five things in order: the status and dates, the description, the CVSS score and who assigned it, the affected product configurations, and the references. Then ask one extra question outside NVD: is it on CISA's Known Exploited Vulnerabilities list?
What are we looking at?
The National Vulnerability Database (NVD) is run by NIST and attaches scores, weakness types and affected-product data to CVE records. The example below is CVE-2024-3094, the xz backdoor. The values come from the NVD API on 18 October 2026, and they can change when NVD updates the record.
Step 1 (10 seconds): status and dates
Look at the published date, the last modified date and the status. For CVE-2024-3094 the published date is 29 March 2024, the last modified date is 17 June 2026 and the status reads Modified. A recent modified date means someone has changed the record, so read the fields rather than trusting a screenshot from last year.
Status matters because NVD has a backlog. NIST states that starting in early 2024 NVD developed a significant backlog of unenriched CVEs, and that older backlogged CVEs are now labeled as not scheduled for immediate enrichment, with KEV-listed CVEs excluded from the backlog. If a record has a description but no score or configurations, it may not have been enriched yet.
Step 2 (20 seconds): the description
The description is usually supplied by the CVE numbering authority that assigned the ID, so it tends to come from people close to the flaw. Read it for what is affected, how, and under what conditions. For CVE-2024-3094 it says malicious code was found in the upstream tarballs of xz, starting with version 5.6.0.
Step 3 (30 seconds): the score and its source
A record can carry more than one CVSS score. The API shows two for this CVE: one from the NVD itself marked Primary and one from Red Hat marked Secondary. Both give version 3.1 base score 10.0, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.
Learn to read the vector. AV is attack vector (N is network), AC is attack complexity, PR is privileges required, UI is user interaction, S is scope, and C, I, A are the confidentiality, integrity and availability impact. The FIRST specification maps scores to labels: 0.1 to 3.9 is Low, 4.0 to 6.9 Medium, 7.0 to 8.9 High and 9.0 to 10.0 Critical.
Remember what the number means. FIRST says the base score reflects intrinsic severity and assumes a reasonable worst case, and that consumers should supplement it for their own environment. A 10.0 on software you do not run is not urgent. A 6.5 on an internet-facing system you do run might be.
Step 4 (30 seconds): weakness and affected configurations
The weakness field holds a CWE ID, the kind of flaw. Here it is CWE-506, embedded malicious code, supplied by Red Hat. Note who supplied it.
The configurations section lists product matches as CPE strings. For this CVE they name the tukaani xz product at versions 5.6.0 and 5.6.1. Compare them with the exact versions in your inventory. CPE matching is imperfect: a distribution may rename or backport, so a package can be affected without matching and the reverse.
Step 5 (30 seconds): references and exploitation
References carry tags that tell you what each link is, such as vendor advisory or patch. Open the vendor advisory first, since it says what to install. Then check CISA's Known Exploited Vulnerabilities catalog, which CISA describes as the authoritative source of vulnerabilities exploited in the wild and which organizations should use as an input to prioritization. NVD flags KEV entries, but check the catalog directly. Exploitability analysis then tells you whether your own code can reach the flaw.
Open the exploitability check demo
What to do
- Read status and dates, and be wary of records with no enrichment.
- Read the description first, since it usually comes from the party that assigned the CVE.
- Note which source assigned each CVSS score, and read the vector, not only the number.
- Compare CPE versions with your own inventory, allowing for backports.
- Open the vendor advisory before anything else in the references.
- Check the CISA KEV catalog.
- Decide using your environment, not the base score alone.
Quick check
Is a CVSS base score a measure of risk to my company?
No. FIRST describes it as intrinsic severity under a reasonable worst case. Risk depends on whether you run the software and whether the flaw is reachable and exploited.
Why does a record sometimes have no score?
NVD has had a backlog of unenriched CVEs since early 2024, so some records have a description but no NVD score or configuration data yet.
Sources
- NVD API record for CVE-2024-3094 (retrieved 18 October 2026)
- NIST: National Vulnerability Database program page
- FIRST: CVSS v3.1 specification
- CISA: Known Exploited Vulnerabilities catalog
Last reviewed: 18 October 2026.
