What is a CVE? What the record does not say

The entire NVD description for CVE-2023-23397 is six words: "Microsoft Outlook Elevation of Privilege Vulnerability." That record carries a 9.8 CVSS base score and entered CISA's KEV catalog on 14 March 2023, the day it published. It names no attack path, no affected MAPI property, no port. Nothing in it can be matched by a SIEM.

That gap is the whole point of this post. A CVE ID is a name. It is not a severity, not a finding, and not a detection.

What the record actually contains

A CVE Record in the current JSON 5.x format holds a few required things: the ID, the assigning organization, a description, and references. Everything else is optional. A CNA may add affected product and version ranges, a CVSS vector, a CWE mapping and a problem type. Many add none of it.

Pull the raw record and the shape is obvious:

{
  "cveMetadata": {
    "cveId": "CVE-2026-58000",
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "state": "PUBLISHED",
    "assignerShortName": "VulnCheck",
    "dateReserved": "2026-06-26T17:58:05.796Z",
    "datePublished": "2026-06-29T18:16:04.973Z"
  }
}

There is no field for exploitation behaviour. No process names, no file paths, no network artifacts. The format exists so two vendors discussing the same bug use the same word for it.

Who assigns what

MITRE operates the program as the Top-Level Root, with CISA sponsoring it. Below that sit Roots, and below those sit CNAs, the CVE Numbering Authorities that actually reserve IDs and publish records inside a declared scope. The program's published CNA list carried 533 entries across 44 countries when we checked on 31 July 2026. Microsoft assigns for Microsoft products. Anything outside every declared scope falls to a CNA of Last Resort.

The CVE List is the authoritative set of records. The NVD is a separate NIST database that ingests those records and enriches them, adding a CVSS score of its own, a CWE mapping, and CPE product identifiers that scanners match against. A third role exists: an Authorized Data Publisher, or ADP, which appends a container to someone else's record without owning it. CISA is an ADP and uses that slot for its Vulnrichment work. On CVE-2023-23397 the CISA container carries an SSVC decision:

{
  "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
  "ssvcData": {
    "options": [
      { "exploitation": "active" },
      { "automatable": "no" },
      { "technicalImpact": "total" }
    ]
  }
}

Three organizations, three sets of data, one ID. That is where most downstream confusion starts.

The identifier

The format is CVE, a year field and a sequence field of four or more digits, with no upper bound on the sequence. CVE-2026-54896 is valid.

The year is the year the ID was reserved, not the year the bug was found or fixed. CVE-2020-19909 was published on 22 August 2023 against a curl bug fixed in 2019. Sorting a vulnerability list by the year in the ID gives you a wrong timeline. Sort on datePublished.

Reserved, published, rejected, disputed

The record state machine has three values. RESERVED means a CNA has claimed the ID and published nothing. PUBLISHED means the description and references are live. REJECTED means the ID should not be used, usually as a duplicate or a withdrawn report.

Reserved is where defenders get stuck. A vendor advisory or a conference talk cites an ID, you go looking, and the program API has nothing to give you:

{ "error": "CVE_RECORD_DNE", "message": "The cve record for the cve id does not exist." }

That is the response from https://cveawg.mitre.org/api/cve/CVE-2026-70000 today. There is no way to distinguish an ID that is reserved and embargoed from one that was never allocated. You wait, or you work from the vendor advisory instead.

DISPUTED is not a state. It is a tag applied to a published record when someone challenges whether the issue is a vulnerability at all. CVE-2020-19909 carries it:

"cveTags": [
  { "sourceIdentifier": "cve@mitre.org", "tags": ["disputed"] }
]

The curl maintainers asked MITRE to reject that record on the grounds that it was not a security issue. MITRE declined and tagged it instead. Tagged records stay in your scanner output.

Where automated matching breaks

Scanners do not match on the CNA's version ranges. They match on CPE strings, and CPE is produced by NVD enrichment, not by the CNA. When enrichment does not happen, the record has no configurations block and matches nothing.

We sampled the first 200 of the 5,479 CVEs the NVD published between 1 and 20 July 2026. The status split:

Analyzed             89
Deferred             82
Awaiting Analysis    16
Modified             11
Undergoing Analysis   1
Rejected              1

Ninety-nine of those 200 records carried no configurations block at all. Half the window is invisible to CPE-based matching.

This is deliberate now. NVD's backlog started building in early 2024 and never cleared. On 15 April 2026 NIST changed the model: it enriches CVEs in KEV (target of one business day), CVEs for software used in the federal government, and critical software under Executive Order 14028. Everything else is filed as "Lowest Priority, not scheduled for immediate enrichment", and every backlogged CVE with an NVD publish date before 1 March 2026 was moved to Not Scheduled. NIST cites a 263 percent rise in submissions between 2020 and 2025 as the driver.

The operational consequence: "no CVSS in NVD" no longer means "not serious". It means nobody at NIST looked.

When the scores disagree

CVE-2023-23397 has two CVSS 3.1 vectors on the record, one from Microsoft as CNA and one from NVD. Both read AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H for 9.8. Agreement is not the norm.

CVE-2020-19909 sits at the other end. The curl project reported it arrived in NVD as 9.8 critical for a retry delay integer overflow its own security team had already ruled a plain bug. NVD today shows CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, a 3.3. Same record, a 6.5 point swing, driven by nothing but who was scoring.

When the CNA and NVD disagree, prefer the CNA vector. The vendor knows the code path. Then override both with your own environmental metrics, because neither party knows whether the affected service is internet-facing in your estate.

CWE and KEV are not the same axis

These three get conflated constantly. They answer different questions.

CWE is a taxonomy of weakness types, not instances. Note that the two CWE mappings on this record disagree. Microsoft assigned CWE-20, Improper Input Validation. NVD assigned CWE-294, Authentication Bypass by Capture-replay. Both are defensible readings of the same bug. If you group your vulnerability data by CWE, know which source you pulled.

KEV is CISA's catalog of CVEs with reliable evidence of exploitation in the wild and a clear remediation. It was established under BOD 22-01, which CISA has since revoked and superseded with BOD 26-04. As of catalog version 2026.07.29 it holds 1,656 entries against 372,240 CVE records in the NVD. That is 0.44 percent. KEV is the strongest free prioritisation signal available, and it is also a lagging one. It tells you exploitation was observed, not that it was not.

From a CVE to a detection

None of the above is detectable. To write a rule you need the exploitation behaviour, and that lives in vendor advisories, exploit write-ups and your own lab, never in the CVE record. This is the daily reality of detection engineering: the identifier is where the research starts.

Work CVE-2023-23397 through it. Microsoft's guidance blog fills in what the record omits. A crafted message sets the PidLidReminderFileParameter extended MAPI property to a UNC path on an attacker-controlled server. When the reminder fires, Outlook on Windows resolves that path and sends a Net-NTLMv2 hash in the SMB negotiation. The user does not open anything. Microsoft traced potential exploitation back to April 2022 and later attributed in-the-wild use to Forest Blizzard, a Russian state-sponsored actor.

Now there are artifacts. Outbound TCP 445 to a public address from a workstation. Outlook touching the WebClient and LanmanWorkstation network provider registry keys before it does so. Mailbox items where the reminder property points into the internet zone.

The SigmaHQ rule takes the registry path:

title: CVE-2023-23397 Exploitation Attempt
id: 73c59189-6a6d-4b9f-a748-8f6f9bbed75c
status: test
description: Detects outlook initiating connection to a WebDAV or SMB share, which could be a sign of CVE-2023-23397 exploitation.
logsource:
    service: security
    product: windows
    definition: 'Requirements: SACLs must be enabled for "Query Value" on the registry keys used in this rule'
detection:
    selection:
        EventID:
            - 4656
            - 4663
        ProcessName|endswith: '\OUTLOOK.EXE'
        ObjectName|contains|all:
            - '\REGISTRY\MACHINE\SYSTEM'
            - 'Services\'
        ObjectName|endswith:
            - 'WebClient\NetworkProvider'
            - 'LanmanWorkstation\NetworkProvider'
        AccessList|contains: '%%4416'
    condition: selection
level: critical

What it catches: OUTLOOK.EXE reading the network provider keys, which happens when it is about to resolve a remote path over WebDAV or SMB. What it misses: everything, unless you have first enabled a SACL for Query Value on those two keys. That is not on by default. The rule is also behavioural rather than exploit-specific, so a legitimate remote path in a reminder produces the same events.

Known false positives, per the rule author: searchprotocolhost.exe queries the same keys constantly, so filter it upstream of the SIEM rather than in the rule.

The network-side view is cheaper to collect. Microsoft's own hunting query for the same behaviour:

//Hunt for SMB to the internet
let range = ago(30d);
DeviceNetworkEvents
| where Timestamp > range
| where RemotePort == 445 or LocalPort == 445
| where not(ipv4_is_private(RemoteIP)) or not(ipv4_is_private(LocalIP))
| extend SignatureName = tostring(parse_json(AdditionalFields).SignatureName)

That query has no CVE in it. Outbound SMB to the internet is worth an alert whether or not this particular bug is involved, and it survives the next forced-authentication CVE.

Relevant techniques: T1187 for the forced authentication, T1557.001 for the relay that follows. Note that a Net-NTLMv2 hash cannot be replayed as pass-the-hash, so T1550.002 does not apply here. It is relayed or cracked.

Summary

A CVE ID names a flaw and nothing else. Severity, weakness class and exploitation status come from three different systems with three different owners, and any of them can be absent, stale or wrong. As of April 2026 the NVD only enriches CVEs that hit KEV, federal software or EO 14028 critical software, so an empty CVSS field is now normal rather than informative. Getting from an ID to a rule means finding the exploitation behaviour somewhere else, then detecting that behaviour rather than the ID. Rules written against behaviour keep working after the patch ships.

Collect for this class of bug:
  Windows Security 4656, 4663   (requires SACL on the two NetworkProvider keys)
  Microsoft-Windows-SMBClient/Connectivity 30803, 30804, 30806
  Perimeter or EDR network events, TCP 445 to non-RFC1918 destinations

Mitigations that break the chain:
  Add high-value accounts to the Protected Users group
  Block outbound TCP 445 at the perimeter, local firewall and VPN

Scan mailboxes for the property:
  https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/

Exploitation of a named CVE almost always shows up first as ordinary behaviour in your existing telemetry. Browse the catalog by what you can actually collect: Windows rules or network rules.