CyphrQ
Menu

How to Read a CVE Record and NVD Entry (and the 2025 Funding Scare)

Read a CVE record and an NVD entry field by field, with a real example, and learn what the 2025 CVE funding scare and NVD backlog mean for defenders.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

A CVE record is a short public entry that gives one security flaw a unique ID, a plain description, the affected products and links to the vendor's advisory. The NVD entry for the same ID adds NIST's own analysis, such as its severity score and a machine-readable list of affected products. Knowing how to read a CVE record starts there: both can be late or disagree, so treat them as inputs, not verdicts.

What is a CVE record?

CVE stands for Common Vulnerabilities and Exposures. Each flaw gets an ID such as CVE-2025-32711, so that your scanner, your vendor and a news article can all point at the same thing.

The record is the CVE Program's entry for that ID. It is deliberately small: a description, the affected products, and references. It is not a risk assessment of your systems.

Who writes it matters. Records are mostly written by a CVE Numbering Authority (CNA), an organisation authorised by the CVE Program to assign IDs and publish records for its own scope. Microsoft is a CNA for Microsoft products, for example. So the first-hand description usually comes from the vendor that ships the flaw.

How do you read a CVE record, field by field?

I read one real record rather than describing a blank template. CVE-2025-32711 is a Microsoft 365 Copilot flaw, titled "M365 Copilot Information Disclosure Vulnerability" in Microsoft's own record. I read it on 25 October 2026 from the CVE Program's own record page and its CVE Services API, which returns the record as JSON (record format version 5.2 when I read it).

Field What it said for CVE-2025-32711 What it tells you
ID and state CVE-2025-32711, PUBLISHED The record is live and public.
Assigner microsoft Who wrote it. A vendor CNA knows its own product best.
Date published 2025-06-11 When the record went public, not when the flaw was found or fixed.
Description "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network." One or two sentences. Enough to triage, rarely enough to act on.
Affected Product "Microsoft 365 Copilot", status affected Which product. Here the version is just "-", because it is a hosted service.
Weakness CWE-74, "Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')" The type of flaw, as a Common Weakness Enumeration ID.
Score CVSS v3.1 base score 9.3, CRITICAL The CNA's own severity rating.
References One link to Microsoft's advisory Where the fix or guidance lives. Follow it.

Three things worth knowing as you read:

  • The description is short on purpose. The vendor advisory in the references has the detail.
  • A record can carry more than one author's work. This one has a second and third block of data added by others, covered next.
  • "Affected" is the vendor's statement. If it is wrong or vague, nothing in the record flags it.

What do the extra blocks in a CVE record add?

The CVE record format separates the CNA's own data from additions by other parties, called ADP (Authorized Data Publisher) containers. In CVE-2025-32711 I found two:

  1. CISA ADP (Vulnrichment). The container is labelled "CISA ADP Vulnrichment" in the record, and CISA's Vulnrichment page says CISA adds SSVC decision points to CVE records. SSVC is a prioritisation method with three decision points here: Exploitation, Automatable and Technical Impact. CISA's page explains "yes" for Automatable as meaning an attacker could generally exploit the flaw at will, and "total" for Technical Impact as meaning exploitation gives the attacker total control over the impacted software. For this record, as read on 25 October 2026, the values were Exploitation "none", Automatable "yes" and Technical Impact "total".
  2. The CVE Program container. It added one extra reference link, to a third-party write-up of the flaw.

Why this matters: a record you read in a scanner may show only the CNA's part. The enrichment is often there, one layer down.

What does the NVD entry add to a CVE record?

The National Vulnerability Database (NVD), run by NIST, takes each CVE record and adds its own analysis. It is a separate service with its own timeline.

I read the NVD's API entry for the same ID. Compare it with the CVE record above:

Item CVE record (Microsoft, CNA) NVD entry
CVSS v3.1 base score 9.3 CRITICAL 9.3 CRITICAL (source [email protected], "Secondary") and 7.5 HIGH (source [email protected], "Primary")
Weakness CWE-74 CWE-74, source [email protected]
Affected products Product name in plain text Machine-readable match string: cpe:2.3:a:microsoft:365_copilot:-:*:*:*:*:*:*:*
Status PUBLISHED Modified
Reference tags None The Microsoft advisory is tagged "Vendor Advisory"

A score has an author, so check whose score your tool is showing. The same flaw carries two different scores: Microsoft rated it 9.3 and NIST's own analysis rated it 7.5. I haven't traced why they differ, and the NVD entry doesn't say. The NVD values in this table are as read on 25 October 2026.

The NVD record also showed a last-modified date of 2026-06-17, a year after publication. Entries keep changing.

How do you read an NVD entry?

A short routine:

  1. Check the status. Look at the vulnerability status field, such as Modified here. NVD uses labels to show how far analysis has got.
  2. Find the scorer. Each score lists its source. Note whether it is the CNA or NIST.
  3. Read the match string. In a CPE (Common Platform Enumeration) string, a means application, then come vendor (microsoft) and product (365_copilot). The - in the version slot means no specific version is given. Scanners use this string to decide whether a CVE applies to you.
  4. Open the references and the tags. Look for the "Vendor Advisory" link first.
  5. Check the dates. Published, last modified, and whether the entry was analysed at all.

For what to fix first, and how severity, exploit likelihood and known-exploited lists fit together, see CVSS, EPSS and KEV: how to prioritise vulnerabilities. I don't repeat that here.

Why did the NVD fall behind on analysing CVEs?

The NVD adds its analysis after a CVE is published, and that step slowed. NIST's own NVD page lays out the timeline:

  • March 19, 2025: NIST said CVE submissions rose 32% in 2024 and the prior processing rate was "no longer sufficient to keep up with incoming submissions". It also said "the backlog is still growing."
  • April 2, 2025: CVEs published before 1 January 2018 that were still awaiting enrichment would be marked Deferred. NIST said it would still prioritise any CVE added to the CISA Known Exploited Vulnerabilities (KEV) catalog.
  • April 15, 2026: NIST wrote that "Starting in early 2024, the NVD developed a significant backlog of unenriched CVEs." It reported submissions up 263% from 2020 to 2025, and nearly 42,000 CVEs enriched in 2025. Backlogged CVEs published before 1 March 2026 move to a "Not Scheduled" category, and CVEs outside its new priority criteria are labelled "Lowest Priority - not scheduled for immediate enrichment."
  • April 28, 2026: NIST said approximately 4,500 CVE records, 19% of those with a CVSS v4.0 score, had been assigned incorrect numerical scores, most of them higher than the correctly calculated value, and scheduled a script to correct them that day.

In practice, an NVD entry for a recent or low-profile CVE may have no NIST score and no match string at all. That is not the same as "not vulnerable".

What was the 2025 CVE programme funding scare?

Short answer: in April 2025 a MITRE letter warned that the CVE Program's funding was about to expire, and CISA exercised a contract option the evening before it lapsed. Both points, and every figure below, are as reported by The Record.

As The Record reported on 16 April 2025, the CVE Program ran under a CISA contract with MITRE, and:

  • A MITRE letter from Yosry Barsoum, vice president and director of its Center for Securing the Homeland, warned that funding was expiring and the government appeared unlikely to renew.
  • The $57.8 million contract was due to expire on 16 April 2025.
  • CISA exercised the contract's option period on the evening of 15 April "to ensure there will be no lapse in critical CVE services". A CISA spokesperson called the program "invaluable to the cyber community and a priority of CISA."
  • The option ran to 16 March 2026, so the extension was for 11 months. CISA did not say what would happen after that.

I could not read CISA's original statement or MITRE's letter directly. I am relying on The Record's reporting of both, so treat the quotes as reported, not primary.

What I could not establish: I didn't find an official source confirming the contract's status after 16 March 2026, so I won't state it.

What I did read from CISA is a bulletin dated 23 September 2026, "CISA Releases Framework for the CVE Program's Holistic Shift into a New Quality Era", built around four areas: program governance, ecosystem participation, data infrastructure and CVE record content. The bulletin I read doesn't mention funding or contracts.

What do the funding scare and NVD backlog mean for defenders?

The CVE record kept being published throughout. The risk was not that the system would vanish. It was that your tools rely on two services run by different bodies, and either can slow or change.

A practical plan:

  • Don't wait for NVD scores. Read the vendor advisory and the CNA's data first.
  • Don't treat a blank as safe. No NVD score or match string can mean "not yet analysed".
  • Know which feed your tools use. Ask your vendor whether it relies on NVD only, or also on CNA data, CISA's additions and its own research.
  • Keep a second source. ENISA runs a European Vulnerability Database at euvd.enisa.europa.eu. I haven't reviewed its coverage, so check it before you rely on it.
  • Watch the dates. If you rely on a single dataset for compliance evidence, note when it was last updated.

Going deeper: for security and IT teams

Record format and ownership. CVE records use the CVE Record Format (JSON 5.x; the CVE Services API returned dataVersion 5.2 for CVE-2025-32711). The CNA container (containers.cna) holds affected, descriptions, metrics, problemTypes and references. The one I read also carried cpeApplicability, datePublic, title and a tags value of exclusively-hosted-service. ADP data sits in separate containers.adp entries, each with its own providerMetadata.shortName. Parse them separately and record the source, because your tooling should never merge them silently.

CNA scoring versus NVD scoring. CVE-2025-32711 shows two CVSS 3.1 base scores in NVD: 9.3 from [email protected] (Secondary) and 7.5 from [email protected] (Primary). If your scanner or SIEM ingests only one, you will get a different priority depending on the pipeline. Decide your policy in writing: CNA score, NVD score, the higher of the two, or your own. Store the scorer ID with every score. Then prioritisation inputs such as exploitation status belong in a separate field, not folded into the score.

CPE matching and its limits. NVD expresses affected products as cpeMatch criteria such as cpe:2.3:a:microsoft:365_copilot:-:*:*:*:*:*:*:*. Automated matching works only when your asset inventory uses the same vendor and product names. A version of - (as here, for a hosted service) gives you nothing to compare against an installed version. Where NVD has not analysed an entry, no configurations block exists. Your scanner may therefore produce no finding even for a real flaw. For software you run, test it: pick five recent CVEs, check whether your tool matched each, and record the misses.

Using multiple feeds. Build a pipeline that pulls from more than one source, and keep their fields apart:

  1. The CVE record itself (CNA container) via CVE Services or the CVE project's public data.
  2. NVD enrichment via its API, noting vulnStatus, lastModified, and whether configurations exists.
  3. CISA's ADP container (Vulnrichment) for SSVC values, where present.
  4. CISA's KEV catalog. NIST said in April 2025 it would keep prioritising KEV entries regardless of status.
  5. Vendor advisories, for example the Microsoft Security Response Center update guide linked from the record's reference.
  6. Optionally, the ENISA database after you have checked its coverage.

Detection and evidence. Alert on internal findings where a CVE has no NVD analysis after a set number of days, and route them to manual review rather than auto-closing. Log the data source and retrieval date for every CVE used in risk acceptance, so an auditor can see which version of the record you relied on. NVD entries are revised after publication (the entry I read was last modified 2026-06-17), so a snapshot taken at triage time can differ from today's.

Questions for vendors and auditors. Which datasets feed your vulnerability scoring? Do you show the CNA score, the NVD score, or both, and label them? What do you do with CVEs that NVD has labelled "Not Scheduled" or "Lowest Priority"? What is your fallback if a single upstream source is delayed?

Key takeaways

  • A CVE record gives a flaw an ID, a short description, affected products and references. It is not a risk rating for your environment.
  • The NVD entry adds NIST's analysis, but later, and its score can differ from the vendor's. For CVE-2025-32711, Microsoft's score was 9.3 and NIST's 7.5.
  • NIST reported a backlog of unenriched CVEs that began in early 2024, and in April 2026 moved older backlog items to "Not Scheduled".
  • In April 2025 CISA exercised a contract option, reported as an 11-month extension to 16 March 2026, with no public detail on what came next in the sources I read.
  • Use more than one source, record who scored what, and treat a blank NVD field as "unknown", not "safe".

Sources