Category: Vulnerability and Software Security
Common Vulnerabilities and Exposures
Also known as: CVE, CVE list, CVE program, CVE identifier
Simply put
Common Vulnerabilities and Exposures (CVE) is a publicly available list that gives each known security flaw in software or hardware its own unique identification number, along with a short description and at least one public reference. This shared naming system lets security teams, vendors, and tools all refer to the same vulnerability in a consistent way. It is a catalog for identifying vulnerabilities, not a rating of how severe or exploitable they are.
Formal definition
CVE is a program and associated list that uniquely identifies publicly known cybersecurity vulnerabilities, associating each with an identification number (CVE ID), a description, and at least one public reference. Each entry is intended to pin a specific vulnerability to affected code or product versions, providing a common identifier that supports correlation across advisories, scanners, and databases such as the NVD. CVE identification is distinct from vulnerability scoring, prioritization, or exploitation status; for example, catalogs such as CISA's Known Exploited Vulnerabilities Catalog reference CVE IDs but track exploitation separately, and severity is assigned by scoring frameworks rather than by the CVE entry itself.
Why it matters
CVE provides a shared vocabulary for talking about software and hardware vulnerabilities. Without a common identifier, the same flaw might be described differently across vendor advisories, scanner outputs, threat intelligence feeds, and internal tickets, making it difficult to correlate findings or confirm whether a given weakness has been addressed. By assigning each publicly known vulnerability a unique CVE ID with a description and at least one public reference, the CVE list lets security teams, vendors, and tools all point to the same issue without ambiguity.
Who it's relevant to
Security engineers and vulnerability management teams
These teams use CVE IDs to correlate scanner output, vendor advisories, and patch information for the same flaw. Because CVE identification is distinct from severity, teams typically pair CVE IDs with a scoring framework and exploitation intelligence to decide what to fix first rather than relying on the CVE entry alone.
Compliance officers and QSAs
PCI DSS addresses identifying and ranking vulnerabilities and applying security patches, though requirement numbering and wording differ between versions, so confirm details against the current published standard. CVE IDs give assessors and compliance teams a consistent reference when documenting which vulnerabilities affect in-scope systems and whether they have been remediated. Note that CVE identifies a vulnerability but does not itself rank or score it.
Payment software vendors and product security teams
Vendors reference CVE IDs when disclosing flaws in their products and mapping them to affected code or product versions, which helps customers determine whether a given release is impacted. This supports coordinated communication across advisories and downstream databases such as the NVD.
Incident responders and threat intelligence analysts
Analysts use CVE IDs to tie together advisories, exploitation reports, and catalogs such as CISA's Known Exploited Vulnerabilities Catalog, which references CVE IDs but tracks exploitation separately. This lets responders distinguish a vulnerability's existence from evidence that it is being actively exploited.
Inside CVE
CVE Identifier (CVE ID)
A unique, standardized identifier assigned to a publicly disclosed vulnerability, formatted as CVE-YYYY-NNNNN. It provides a common reference point so that different tools, vendors, and teams can refer to the same vulnerability unambiguously.
Vulnerability Description
A brief summary of the flaw, typically identifying the affected product or component and the nature of the weakness. The description is intended to help practitioners determine relevance, not to serve as complete remediation guidance.
Affected Products and Versions
Information indicating which software, hardware, or component versions are subject to the vulnerability, used to assess whether an organization's environment is exposed.
References
Links to advisories, vendor bulletins, patches, or third-party analysis that provide additional detail. References support investigation but the CVE record itself is not a full technical report.
Associated Severity Scoring (external)
CVE records are frequently paired with severity scores such as CVSS supplied by databases like the National Vulnerability Database. The scoring is a separate system from the CVE identifier and reflects a base assessment that may not account for an organization's specific context.
Common questions
Answers to the questions practitioners most commonly ask about CVE.
Does a CVE identifier tell you how severe or exploitable a vulnerability is?
No. A CVE identifier is only a unique label that identifies a specific vulnerability; it does not by itself convey severity, exploitability, or risk. Severity scoring is a separate function typically expressed through systems such as CVSS, and even a CVSS score does not fully capture exploitability or the contextual risk within your specific environment. You should assess the impact of a given CVE against your own systems, compensating controls, and exposure rather than inferring risk from the CVE number alone.
Is a CVE the same thing as a patch or a fix?
No. A CVE is an identifier for a publicly disclosed vulnerability, not a remediation. The existence of a CVE does not guarantee that a patch is available, and remediation may involve vendor patches, configuration changes, compensating controls, or accepting and documenting residual risk. Tracking a CVE is the starting point for triage and remediation decisions, not the conclusion of them.
How do CVEs relate to PCI DSS vulnerability management expectations?
PCI DSS includes requirements addressing identifying and ranking vulnerabilities and applying security patches within defined timeframes, and CVEs are a common reference point for identifying and tracking those vulnerabilities. However, PCI DSS does not require you to act on the CVE label alone; it expects a risk-ranking process and timely remediation. Requirement numbering and wording differ between PCI DSS versions, so confirm the specific obligations against the current published standard rather than assuming a fixed requirement number.
How should we prioritize which CVEs to remediate first across our cardholder data environment?
Prioritization generally combines a severity score, such as CVSS, with contextual factors including whether the affected system is in or connected to the cardholder data environment, whether the vulnerability is known to be actively exploited, its exposure to untrusted networks, and any compensating controls in place. A CVE that is high-scoring but on an isolated, mitigated asset may be a lower practical priority than a moderate CVE on an internet-facing system handling account data. Document your ranking rationale so remediation decisions are defensible.
How do we map CVEs identified in a vulnerability scan to our in-scope assets?
Effective mapping depends on an accurate asset inventory that identifies which systems are in scope, connected to, or could impact the security of the cardholder data environment. Scan output referencing CVEs should be correlated to that inventory so each finding is tied to an owner, a system classification, and a remediation timeline. Gaps or inaccuracies in the inventory can cause in-scope systems to be missed, so reconciliation between scan results and the asset inventory is an ongoing operational task.
What should we do when a CVE affects our environment but no vendor patch is yet available?
When no patch exists, common approaches include applying vendor-recommended workarounds, tightening configuration, restricting network access to the affected component, increasing monitoring, or otherwise implementing compensating controls intended to reduce exposure until a fix is released. These measures may mitigate but do not necessarily eliminate the underlying risk, so document the residual risk, the interim controls, and a plan to apply a permanent remediation once one is available.
Common misconceptions
A CVE identifier includes a severity rating.
The CVE identifier itself is a naming reference for a vulnerability. Severity scoring, such as CVSS, is applied separately by databases and vendors. A single CVE may be scored differently depending on the source, period, and contextual assumptions used.
Having no CVEs listed for a product means it is secure and that addressing all CVEs satisfies PCI DSS.
A CVE record only exists for publicly disclosed and cataloged vulnerabilities, so absence does not imply security. PCI DSS addresses vulnerability management, secure configuration, and patching as broader processes; confirm the specific applicable requirements against the current published standard, as numbering and wording differ between versions.
Assigning a CVE fixes or mitigates the vulnerability.
A CVE only names and describes a vulnerability to enable coordinated tracking. Remediation depends on applying vendor patches, configuration changes, or compensating controls. Cataloging a CVE helps organizations identify and prioritize but does not by itself reduce risk.
Best practices
Use CVE identifiers as a common reference to correlate findings across scanners, vendor advisories, and internal tracking, rather than relying on any single tool's proprietary naming.
Treat external severity scores such as CVSS as a starting point and adjust prioritization based on your own environment, exposure, and the sensitivity of systems handling cardholder data.
Cross-reference CVE records against your inventory of affected products and versions to determine actual applicability before scheduling remediation.
Follow the linked references and vendor advisories for authoritative patch and mitigation details, since the CVE record itself is a summary and not full remediation guidance.
Integrate CVE tracking into your ongoing vulnerability management and patching processes, and confirm the specific PCI DSS requirements that apply against the current published standard rather than assuming fixed requirement numbers.
Where an immediate patch is unavailable, document and apply compensating controls, and revisit the item as new information or scoring updates emerge.