How to Read a CVE Advisory: Records, NVD, CSAF and KEV

Most teams react to a CVE by reading its severity score, when the facts that decide what to do sit in fields they skip: the affected version ranges, who supplied which data, whether exploitation is confirmed, and what the fix leaves behind. A single vulnerability now produces several documents: the CVE record published by the CNA, enrichment from CISA and other publishers, the NVD entry, one or more vendor advisories, machine-readable CSAF and VEX files, and exploitation signals such as the KEV catalog and EPSS. They often disagree. This guide walks through each field by field: version ranges, workaround versus fix, and the advisories that also require rotating keys, tokens and service account credentials. It is for vulnerability analysts, SOC and platform engineers, and ends with a worked KEV example.

Key takeaways

Read the record, not the headline score. The affected versions, conditions in the description and the exploitation status decide your action far more often than the CVSS number does.
Know who said what. A CVE record has one CNA container and possibly several ADP containers; NVD adds its own score and CPE data. When scores differ, the source label tells you why.
Version ranges have exact semantics. In CVE JSON 5, a range runs from version inclusive to lessThan exclusive, so the lessThan value is normally the first fixed build.
Exploited-in-the-wild beats predicted. A KEV listing or an SSVC Exploitation value of "active" moves a CVE ahead of anything scored higher but unexploited; EPSS ranks the rest.
Patching does not undo theft. When the flaw can leak memory, configuration or keys, the advisory's real instruction is to kill sessions and rotate secrets, and that step is where non-human identities get missed.

The documents behind one vulnerability

Each document has a different author and purpose; expect to consult at least three for any vulnerability that matters. The background on how the CVE programme and NVD are organised is covered in the CVE Programme and NVD Backlog Guide, and the identifier schemes themselves in the CVE, CWE and CPE Guide.

Document	Who writes it	What it is best for	Main limitation
CVE record (CVE JSON 5)	The assigning CNA (often the vendor), plus ADP enrichers such as CISA	Canonical identifier, description, affected versions, CWE, references	Content quality varies by CNA; remediation detail is often only a link
NVD entry	NIST, from the CVE record plus its own analysis	NIST CVSS score, CPE match criteria for scanners, KEV dates	Enrichment can lag publication; NIST score may differ from the CNA's
Vendor advisory	The product vendor's PSIRT	Fixed builds, workarounds, configuration conditions, post-upgrade steps	Formats differ by vendor; revised silently or with minor notices
CSAF advisory or VEX	Vendor or supplier, machine-readable	Automated product matching and "not affected" statements with justification	Coverage depends on the vendor publishing it
Exploitation signals (KEV, EPSS, vendor exploitability ratings)	CISA, FIRST, vendors	Whether to act now	KEV is confirmed-only and lagging; EPSS is a probability, not a fact

Reading the CVE record field by field

The CVE Record Format (CVE JSON 5, the schema maintained in the CVEProject cve-schema repository) is what CVE Services publishes and what every downstream feed copies. A published record has cveMetadata and containers. Records are PUBLISHED or REJECTED; a rejected ID should not be used.

cveMetadata

cveId and assignerShortName: the identifier and the CNA that assigned it. If the assigner is the vendor, the vendor's own advisory is the primary source for fixes.
dateReserved, datePublished, dateUpdated: reservation can precede publication by weeks. A recent dateUpdated on an old CVE is a cue to re-read: ranges, scores or ADP data may have changed.

The CNA container

There is exactly one CNA container per record. The schema requires providerMetadata, descriptions, affected and references; everything else is optional.

descriptions: read every clause. Phrases such as "when configured as" or "authenticated" are exposure conditions the CVSS vector only partly captures.
affected: one entry per product, with vendor and product (or collectionURL and packageName for open source packages), optional platforms, modules, programFiles and cpes, and a versions list with a defaultStatus.
problemTypes: usually a CWE ID. It tells you the weakness class, which helps decide whether the flaw can disclose secrets (memory or information disclosure CWEs) or execute code. See the CWE Top 25 Guide.
metrics: the CNA's own scores, in cvssV4_0, cvssV3_1, cvssV3_0, cvssV2_0 or other format, each with a scenario. How to read the vectors is in the CVSS v4 Guide.
workarounds, solutions, exploits, timeline: optional; when empty, follow the vendor reference.
references: URLs, sometimes tagged (vendor advisory, patch, exploit).

ADP containers and CISA Vulnrichment

Authorized Data Publishers add their own containers; there can be several, and each names its provider. Two appear on most records today: the "CVE Program Container", which typically adds references, and "CISA ADP Vulnrichment". CISA's Vulnrichment programme adds three SSVC decision points to the CVEs it analyses: Exploitation (none, poc or active), Automatable (yes or no) and Technical Impact (partial or total). KEV-listed CVEs also get a KEV block with the date added. CISA may add CWE and CVSS where evidence supports it, but it never overwrites the CNA's data, and if the CNA later supplies those fields CISA removes its own. CISA stopped adding CPE strings on 10 December 2024, so older records may carry ADP CPEs that newer ones lack. Check the SSVC version string (for example 2.0.3) before parsing. How to turn those decision points into a priority is in the SSVC Guide.

Reading version ranges and fixed versions

Version data is where most triage errors happen. In CVE JSON 5 each entry in versions is either a single version with a status, or a range with a versionType (the numbering scheme: semver, a package ecosystem, or a vendor-specific type such as "patch").

Field	Meaning	How to read it
`status`	affected, unaffected or unknown	"unknown" is not "safe": treat it as unverified
`version` with `lessThan`	Range from `version` inclusive to `lessThan` exclusive	The `lessThan` value is the least version not in the range, usually the first fixed build
`version` with `lessThanOrEqual`	Inclusive upper limit	The named version is still affected; the fix is in a later build
`lessThan: "1."` or `""`	Wildcard upper limit	Covers a whole branch, or every version from the start point on
`changes`	Status changes inside a range, each with `at`	Used for backported fixes: a later build in the range becomes unaffected
`defaultStatus`	Status for versions not listed	If omitted it defaults to unknown; "unaffected" means only listed ranges are vulnerable

NVD expresses the same information as CPE match criteria: a CPE 2.3 string with versionStartIncluding and versionEndExcluding (or the inclusive and exclusive variants). Scanners match on these, so if NVD's CPE data is missing or late, a scanner may report nothing even though the CVE record lists your product. Compare both.

Branches: a fix is per release train: on 13.1 you need the 13.1 fixed build.
Product variants: FIPS, government or long-term-support editions often have their own ranges and fix numbers.
End-of-life branches: an EOL branch may be listed as affected with no fixed build. The answer is upgrade to a supported train, not wait.

Reading the NVD entry

The NVD page for a CVE combines the CNA's data with NIST's analysis. Read three things.

Score source: NVD shows scores labelled Primary (NIST) and Secondary (the CNA or another source). Large gaps are common and usually come from different readings of impact. For CVE-2023-4966 the CNA scored 9.4 (C:H/I:H/A:L) while NIST scored 7.5 (C:H/I:N/A:N), treating it as pure information disclosure.
Analysis status: NVD statuses include Received, Awaiting Analysis, Undergoing Analysis, Analyzed, Modified, Deferred and Rejected. Only Analyzed (or Modified after analysis) entries reliably carry NIST CPE configurations. An entry awaiting analysis has no NIST CPEs, which is why the NVD backlog matters to scanner coverage.
KEV fields: KEV-listed entries show the date CISA added the CVE, the action due date and the required action text.

Reading vendor advisories

The vendor advisory is the primary source for what to install and what else to do. Formats vary, but the same questions apply to each.

Vendor pattern	Fields to find	Reading tip
Microsoft Security Update Guide	Per-CVE entry with affected products, KB and build numbers, CVSS, Exploitability Index and exploited or publicly disclosed indicators	Exploitability Index: 0 Exploitation Detected, 1 More Likely, 2 Less Likely, 3 Unlikely; the rating reflects the highest risk across affected versions. See the Patch Tuesday Guide
Cisco PSIRT advisories	Security Impact Rating, affected and fixed releases, workarounds, Bug IDs, Interim or Final status, Last Updated	SIR maps from CVSS base score (Critical 9.0 to 10.0, High 7.0 to 8.9, Medium 4.0 to 6.9) but PSIRT may adjust it; Interim means investigation continues
Other enterprise vendors (for example VMware VMSA, Citrix and Ivanti bulletins)	Advisory ID, response matrix of product, version and fixed version, workaround KB, revision history	Read the revision history; advisories are often re-issued with new CVEs, new affected versions or new post-patch steps

In every case look for four items: the configuration conditions under which the product is exposed, the fixed build for each branch you run, the workaround with its stated limits, and any post-upgrade actions. Advisories are point-in-time documents and are revised, so a day-one decision needs a re-check.

CSAF and VEX: the machine-readable advisory

CSAF 2.0, an OASIS Standard since November 2022 and the successor to CVRF 1.2, is a JSON format for advisories. A document has a document section, a product_tree and vulnerabilities. Profiles include csaf_security_advisory and csaf_vex. Products are identified with helpers such as CPE, PURL, hashes and SBOM URLs, and version ranges can be expressed in the vers format. Providers publish a provider-metadata.json for discovery, with ROLIE feeds or directory indexes for retrieval.

product_status: known_affected, known_not_affected, fixed, first_fixed, first_affected, last_affected, recommended and under_investigation.
remediations: category vendor_fix, workaround, mitigation, fix_planned, no_fix_planned or none_available. These categories make the workaround versus fix distinction explicit.
flags (VEX justifications): component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist. A "not affected" VEX statement without one of these is an assertion, not evidence.
threats: categories exploit_status, impact and target_set carry exploitation and impact context per product.

VEX is what lets an SBOM-driven scanner suppress findings for components that are present but not exploitable in a given product. See the SBOM Guide.

Exploited-in-the-wild signals

Signal	What it says	How to use it
CISA KEV listing	Exploitation confirmed; includes date added, required action, due date (binding on US federal agencies under BOD 22-01) and known ransomware campaign use	Treat as act-now. Read `requiredAction` word by word: it often contains steps beyond patching
SSVC Exploitation (CISA ADP)	none, poc or active, at the timestamp of analysis	"active" without a KEV listing yet still means act; "poc" raises urgency for internet-facing assets
EPSS	Probability (0 to 1) that exploitation activity is observed in the next 30 days, recalculated daily, plus a percentile	Report as probability with percentile, for example "15.3% (92nd)". FIRST publishes no thresholds; a 10% score already sits around the 88th percentile
Vendor ratings	For example Microsoft "Exploitation Detected"	Act on it as confirmed exploitation
References	Public proof-of-concept or exploit links in the record	Raises urgency for exposed assets

EPSS measures attempted exploitation activity, not success, and absence from KEV is not evidence of safety. Combining these signals into a ranked queue is the subject of the Vulnerability Prioritisation Guide and, for CVEs already under attack, the Zero-Day and Exploited Vulnerabilities Guide.

Workaround, mitigation or fix

Fix (vendor_fix): code that removes the flaw; confirm by build number.
Workaround: configuration that blocks the vulnerable path, such as disabling a feature or applying a filter. Note what it breaks and whether the vendor says it is complete.
Mitigation: reduces likelihood or impact (network restriction, WAF rule) without removing the flaw. Record it as an exception with an expiry; see the Remediation SLAs and Vulnerability Exceptions Guide.
Post-remediation actions: anything the advisory says to do after upgrading: terminate sessions, rotate keys, reset credentials, run an integrity check, hunt for indicators. These are part of the fix, not optional extras.

Where identity fits: does the fix require rotating secrets?

An advisory for an internet-facing gateway, identity provider, CI system or collaboration server should prompt one specific question: could an attacker have obtained a credential before you patched? If yes, patching leaves the stolen key working. Check the CWE for disclosure or code execution, and the advisory and KEV requiredAction for sessions, keys, credentials or certificates.

Signal in the advisory	Non-human identity exposed	Action beyond the patch
Memory or information disclosure on a gateway (MITRE ATT&CK T1539 Steal Web Session Cookie)	Session cookies and tokens	Terminate all active and persistent sessions; watch for session reuse (T1550.004 Web Session Cookie)
Code execution on an appliance that stores configuration (T1190 Exploit Public-Facing Application)	Service accounts, LDAP bind credentials, API keys, certificates	Rotate every stored credential, revoke and reissue certificates (T1552 Unsecured Credentials)
Code execution on a web application server	Signing or machine keys, connection strings	Rotate keys after patching, restart services so old keys are dropped
Flaw in a CI/CD or secrets platform	Pipeline tokens, cloud keys, deploy keys	Rotate all secrets the platform held; review audit logs for use

Three incidents show the pattern. In CitrixBleed, memory disclosure leaked valid session cookies, and organisations that patched without running kill aaa session -all and clear lb persistentSessions stayed exposed. In the Ivanti Connect Secure exploitation, CISA told agencies to assume that user and service account credentials stored on affected appliances were likely compromised and to reset them, and to revoke and reissue certificates and keys. In ToolShell, attackers read SharePoint's ASP.NET ValidationKey and DecryptionKey, so Microsoft's guidance was to rotate machine keys and restart IIS on every SharePoint server after updating. Prepare for this before the advisory arrives: the Secrets Rotation Runbook Template and the Token and Session Security Guide cover the mechanics.

Worked example: CVE-2023-4966 (CitrixBleed)

This walk-through uses the published CVE record, the NVD data and the CISA KEV entry (catalog version 2026.10.21).

Metadata: assigner Citrix (so the vendor bulletin, CTX579459, is primary), reserved 14 September 2023, published 10 October 2023, and still being updated years later through ADP data.
Description: "Sensitive information disclosure in NetScaler ADC and NetScaler Gateway when configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server." The condition matters: an ADC used only for load balancing is outside the stated exposure, so first query which appliances have those virtual servers.
Affected versions: ranges with versionType "patch" and defaultStatus "unaffected": 14.1 before 14.1-8.50, 13.1 before 13.1-49.15, 13.0 before 13.0-92.19, 13.1-FIPS before 13.1-37.164, and 12.1-FIPS and 12.1-NDcPP before 12.1-55.300. Each lessThan value is the fixed build for that train.
Problem type and scores: CWE-119. CNA CVSS 3.1 9.4; NIST 7.5. The score gap is a reading of integrity impact, not a disagreement about urgency.
CISA ADP: SSVC 2.0.3 with Exploitation active, Automatable yes, Technical Impact total; KEV added 18 October 2023. A proof-of-concept link appears in the references.
KEV entry: required action "Apply mitigations and kill all active and persistent sessions per vendor instructions", due 8 November 2023, known ransomware campaign use: Known.
Decision: internet-facing gateway, active exploitation, automatable, total impact: patch immediately to the branch's fixed build, then terminate all sessions, then review session logs for reuse from unexpected addresses during the exposure window. Treat service accounts that authenticate through the gateway as exposed.

The pattern repeated in 2025 with CitrixBleed 2.

A repeatable reading workflow

Identify: open the CVE record and note the assigner, dates and whether it is REJECTED or a duplicate.
Scope: match affected products, branches and variants against your inventory, including configuration conditions from the description.
Confirm exploitation: check KEV, the CISA ADP SSVC values, vendor exploitability ratings and EPSS.
Find the fix: read the vendor advisory for the fixed build per branch, workarounds and their limits, and post-upgrade steps.
Check identity impact: ask whether credentials, tokens or keys could have leaked; if so, plan rotation alongside the patch.
Test and roll out: stage the fix on a non-production or pilot node, verify the build number, then roll out; for appliances keep the previous image and configuration backup ready for rollback.
Verify and hunt: rescan, confirm the version, and search logs from before the patch for exploitation indicators.
Re-check: re-read on any advisory revision or change to dateUpdated.

For small organisations without a vulnerability team, the minimum is steps 2, 3, 4 and 5 for every KEV-listed CVE affecting internet-facing systems. Larger organisations should automate matching from CVE JSON 5 and CSAF feeds. Day-to-day remediation operations sit in the Patch Management Guide.

Measuring triage quality

Time to triage: hours from KEV listing or vendor advisory to a recorded affected or not-affected decision.
Version accuracy: percentage of triage decisions later overturned because a branch, variant or condition was misread.
Post-patch action completion: share of advisories with session-kill or rotation steps where those steps were evidenced as done.
Scanner gap rate: CVEs affecting your products that your scanner did not flag, often caused by missing CPE data.

Common failure patterns

Prioritising by NVD base score alone: a 7.5 information disclosure was the CitrixBleed score from NIST, and it leaked credentials that bypassed MFA.
Reading "fixed in latest" instead of per branch: teams upgrade to a build on the wrong train, or miss the FIPS variant with its own fixed build.
Treating "unknown" or missing CPE data as not affected: scanners relying on NVD CPEs miss CVEs still awaiting analysis.
Closing the ticket on a workaround: keep the finding open until the fix is installed.
Skipping post-upgrade steps: sessions not killed, appliance service accounts and certificates not rotated, machine keys left in place, as in the Ivanti and ToolShell cases.

Framework mapping

Framework	Reference	Relevance to reading advisories
NIST CSF 2.0	ID.RA-01, ID.RA-02, ID.RA-05, ID.RA-08	Identify and record vulnerabilities, receive threat intelligence, use likelihood and impact to prioritise, handle disclosures
NIST CSF 2.0	PR.PS-02, RS.MI-02	Maintain software commensurate with risk; eradicate incidents (session and credential clean-up)
NIST SP 800-53 Rev. 5	RA-5, SI-2, SI-5, CM-8, PM-15	Vulnerability monitoring, flaw remediation, receiving security alerts and advisories, component inventory for matching, security groups and associations
CIS Controls v8.1	Control 7 Continuous Vulnerability Management	Process for receiving and remediating vulnerabilities
ISO/IEC 27001:2022 Annex A	A.8.8 Management of technical vulnerabilities; A.5.7 Threat intelligence	Obtaining vulnerability information and acting on it
MITRE ATT&CK v20	T1190, T1539, T1550.004, T1552	Exploitation of public-facing applications and the credential theft that outlives the patch

Practitioner checklist

Pull the CVE JSON 5 record, not just a scanner summary, for every KEV-listed CVE affecting your estate.
Record the assigner, the CNA and NIST scores with their sources, and the CISA SSVC values.
Translate each affected range into the exact fixed build for every branch and variant you run.
Read the vendor advisory and KEV requiredAction for post-upgrade steps, and track them as separate tasks.
For gateways, identity systems and CI platforms, decide explicitly whether sessions, service account credentials, keys and certificates must be rotated.
Ingest CSAF and VEX where vendors publish them, and require a justification flag for every "not affected" suppression.
Report EPSS as probability with percentile, and never as the only reason to defer.

How to Read a CVE Advisory Guide: Turning Vendor and CVE Records Into Action