What Is a CVE: Common Vulnerabilities Explained

A CVE (Common Vulnerabilities and Exposures) is a unique, public and permanent identifier assigned to every security vulnerability documented in software or hardware that is used in the real world. It lets any vendor, researcher, defensive team or auditor refer to exactly the same flaw (CVE-2025-40652) without ambiguity, anywhere in the world and in any tool. It is the backbone of the global vulnerability management system: if a vulnerability has no CVE, in practice it does not exist for automated detection, patching and compliance systems.

This guide explains what a CVE is, how it gets assigned, how it differs from CVSS, CWE and EPSS, where it is officially published and how it impacts the day-to-day operation of any company.

What a CVE is: technical definition

A CVE is a public record in a centralised database that uniquely identifies a specific vulnerability in a specific product. The CVE system is coordinated by MITRE Corporation since 1999, with funding from the US Department of Homeland Security, and currently contains hundreds of thousands of accumulated identifiers.

The identifier structure is transparent:

• CVE-2025-40652 means: year of assignment 2025, sequential number 40652.
• The number is never reused. If an entry is rejected later, it is marked REJECTED but the ID is burned.
• Not every assigned CVE gets published: some stay in RESERVED state while the vendor prepares the patch and only become public on disclosure.

Each CVE entry includes at least: technical description, affected product and version, publication and modification dates, references to official sources (vendor advisory, NVD, INCIBE-CERT, GHSA), and flaw type classification (CWE).

What makes the CVE useful is not the technology (it is basically a database) but the global agreement: every actor in the ecosystem accepts it as a common reference, from the software vendor to the SIEM that detects the attack, through the vulnerability management tool, the WAF, the threat intelligence feed and the compliance frameworks.

How a CVE is assigned: the CNA role

A vulnerability gets a CVE when an entity accredited as a CNA (CVE Numbering Authority) assigns one. MITRE delegates this authority to hundreds of organisations: vendors (Microsoft, Cisco, Red Hat, Oracle), national CERTs (CISA, INCIBE-CERT, JPCERT/CC), cloud providers (AWS, Azure, Google), bug bounty platforms (HackerOne) and some independent researchers with recognised credentials.

The typical flow:

1. A researcher finds a flaw in a product. It can be internal to the vendor, an external independent or external via a bug bounty programme.
2. Reported to the vendor under responsible disclosure.
3. The relevant CNA reserves a CVE (RESERVED state). If the vendor is a CNA, they do it themselves. If not, the umbrella CNA or MITRE handles it.
4. The vendor develops and releases the patch within the agreed window (typically 90 days from the report).
5. The CVE is published with description, CVSS scoring and references to the advisory.
6. NVD enriches the entry with additional analysis: CVSS vector computed by NIST, CWE mapping, additional references.

In Spain, INCIBE-CERT acts as the umbrella CNA for researchers and vendors that do not have direct access to their own CNA. That is why several of our own advisories (for example CVE-2025-40652 and CVE-2023-3512) have identifiers assigned via INCIBE-CERT alongside the parallel registration in NVD.

Where a CVE lives: NVD, GHSA, INCIBE-CERT and friends

A CVE entry itself lives in the repository MITRE maintains at cve.org. But most of the operational work happens against derived sources that enrich the information:

• NVD (National Vulnerability Database). Run by NIST. Adds official CVSS scoring, CWE mapping, impact metrics and additional references. It is the source most commercial tools consume.
• GitHub Security Advisories (GHSA). Specialised in open source software. Each GHSA usually has an associated CVE and links affected packages (npm, PyPI, RubyGems, Maven).
• INCIBE-CERT. The Spanish CERT. Publishes Spanish-language advisories, maps international CVEs to products used in Spain and operates as a CNA for advisories discovered by Spanish teams.
• CISA Known Exploited Vulnerabilities (KEV) Catalog. Critical subset: CVEs that CISA has confirmed are being actively exploited. It is the feed most worth following if you have to prioritise patching.
• Vendor advisories. Each vendor (Microsoft Security Response Center, Red Hat Security Advisories, Cisco PSIRT, AWS Security Bulletins) publishes its own bulletins linking the CVEs.
• Specialised feeds. Tenable, Rapid7, Qualys, CVE Details, Vulners. Commercial or free depending on the case.

For a company, the sensible move is to automate consumption of NVD plus KEV plus advisories from vendors you use and leave the rest for ad-hoc research.

CVE, CVSS, CWE and EPSS: clearing the acronym soup

These four acronyms get mixed up routinely and they are not the same:

• CVE is the identifier. Just that. CVE-2025-40652.
• CVSS (Common Vulnerability Scoring System) is the severity score. The current version is CVSS v4.0; many CVEs still carry v3.1. It gives a 0-10 score and a vector with detailed metrics (AV:N/AC:L/PR:N/UI:N/...). It does not measure probability of exploitation, only theoretical impact.
• CWE (Common Weakness Enumeration) is the underlying flaw type. CWE-79 is Cross-Site Scripting, CWE-89 SQL Injection, CWE-22 Path Traversal. The same CWE can be associated with thousands of CVEs. It helps understand the pattern.
• EPSS (Exploit Prediction Scoring System) is the estimated probability that a specific CVE will be exploited in the next 30 days, based on a statistical model maintained by FIRST. Ranges from 0% to 100%. It is the metric that pays off most in prioritisation because CVSS does not distinguish between a critical that gets exploited and a critical nobody will ever weaponise.

Practical rule: use CVSS to understand theoretical impact, EPSS to prioritise actual patching and CISA KEV for immediate urgency (what is already being exploited).

How to read a CVE entry: practical example

Take CVE-2025-40652 (one of the advisories signed by our team). The fields that matter operationally:

1. Description: "Stored XSS in CoverManager that allows JavaScript execution in the victim user's session."
2. Affected product: CoverManager, versions before the vendor patch.
3. CVSS v4.0: 5.3 MEDIUM, vector AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N. Remote attacker, no authentication, passive user interaction.
4. CWE: CWE-79 (XSS).
5. Status: patched by the vendor.
6. References: NVD, INCIBE-CERT, technical advisory from the discoverer.

With that, a defensive team decides in 60 seconds: does it affect any product we use? Which version do we have? Is it patched? Is there a temporary mitigation while we update?

Why CVEs matter to your company

Three operational reasons that affect any organisation:

1. Compliance. NIS2, DORA, ENS, ISO 27001 and PCI DSS all require a documented vulnerability management process. Without CVE tracking, there is no process. The auditor will ask for evidence (monthly report of applicable CVEs, patch coverage, justification for outstanding ones).
2. Operational threat intelligence. Published CVEs are the public signal of "this thing you have in production just became exploitable". Without a process watching the flow, you depend on an attacker reminding you.
3. Communication with vendors and clients. When a B2B client asks "are you affected by CVE-XXXX-YYYY?", the answer should be immediate and verifiable. That responsiveness is part of commercial trust, not just technical security.

How to track CVEs that affect your stack

The minimum viable process any company with a CISO should have:

1. Software and version inventory. If you do not know what you have deployed, you cannot know if a CVE affects you. It is the zero of zeros. CMDB and SBOM (Software Bill of Materials) cover it.
2. Feed subscriptions. NVD JSON feed (free), CISA KEV (free), advisories from the vendors you use. For mid-market and enterprise, a commercial vulnerability management tool (Tenable, Rapid7, Qualys, Snyk for dependencies) automates the matching.
3. Triage and prioritisation. CVSS tells you severity, EPSS tells you real probability of exploitation, KEV tells you if it is happening now. Combine all three.
4. Documented remediation SLA. Criticals in CISA KEV: 24-72 hours. Criticals without active exploitation: 7-15 days. The rest: 30-90 days by severity. The important part is writing it down and meeting it.
5. SIEM and EDR integration. Modern SIEM and EDR correlate CVEs detected on assets against the KEV feed to alert when a vulnerable asset starts receiving anomalous traffic.

Common mistakes in CVE management

Four patterns that break otherwise well-intentioned processes:

1. Patching only the criticals. Works until an attacker chains medium plus medium plus low and gets what a critical would have delivered. Severity-based management in isolation underestimates the attack chain.
2. Ignoring indirect dependencies. Your app does not use Log4Shell directly, but the X library that you do use does. Without an SBOM or an SCA tool, you miss it.
3. Skipping triage out of constant urgency. If everything is critical, nothing is. Without a method to distinguish, the team burns out.
4. Trusting only NVD. NVD sometimes takes weeks to enrich a freshly published CVE. For urgent cases, complement with vendor feeds directly and with CISA KEV.

Frequently asked questions about CVE

Who decides what gets assigned as a CVE and what does not?

The relevant CNA decides. For vendors that are their own CNA (Microsoft, Cisco, Red Hat, etc.), they decide by their own criteria. For the rest, MITRE or the umbrella CNA decides. Official criteria require the flaw to affect a public product, be reproducible and have a security implication. Bugs without security impact or only in internal code do not receive a CVE.

How long does it take to assign a CVE?

It depends on the CNA and the urgency. For vulnerabilities reported to established vendors (Microsoft, Apple, Google), the CVE is usually assigned in a few days. For small vendors or indirect paths via the umbrella CNA, it can take several weeks. Public publication of the CVE waits for the patch or for the end of the 90-day responsible disclosure window, whichever comes first.

What is the difference between a rejected CVE and a disputed one?

REJECTED means the CVE was assigned but later determined not to be a real vulnerability (duplicate, not reproducible, no security impact). DISPUTED means the vendor or a third party questions the nature of the flaw, but the entry stays active. Worth reviewing the status before applying urgent patches.

Is it mandatory to publish a CVE for every vulnerability found?

No. A researcher can decide to report to the vendor without requesting a CVE; a vendor can patch without assigning one (though the responsible practice is to assign one for traceability). Internal bugs not exposed publicly stay outside the CVE system. The vast majority of bugs that affect a commercial product end up receiving a CVE.

How are advisories shared without an official CVE yet?

While the CVE is in RESERVED state, CNAs and vendors coordinate privately through channels like PSIRT-to-PSIRT, private mailing lists and, in the European space, EU-CSIRTs Network. Public details are only released when the patch is available and the CVE moves to PUBLISHED.

Where do I check if a specific CVE affects me?

Steps in order: (1) identify the exact product and version in your inventory; (2) look up the entry on cve.org or NVD; (3) review the official vendor advisory for exact affected versions (NVD sometimes oversimplifies); (4) if the product is on CISA KEV, top priority; (5) if your vulnerability management tool already did the matching, validate and patch.

What if I find a vulnerability myself? How do I request a CVE?

Three paths: (a) report to the vendor; if they are a CNA, they assign it directly. (b) If the vendor is not a CNA, contact the natural umbrella CNA (INCIBE-CERT in Spain, CISA in the US) or MITRE directly via the form. (c) If your organisation publishes research regularly, consider applying for your own CNA status. Responsible disclosure rules: nothing public before the patch.

Related resources

• Secra security research and advisories: the CVEs signed by our team with full technical detail.
• What is a SOC (Security Operations Center): how the SOC integrates the CVE feed into its daily operation.
• What is SIEM and how it works: how the SIEM correlates CVEs with asset telemetry.
• What is EDR (Endpoint Detection and Response): how the EDR uses the CVE feed to detect active exploitation.
• What is a penetration test: how pentesting validates whether patches really close the documented vector.

CVEs at Secra

At Secra we run an internal research programme that has published advisories on NVD and INCIBE-CERT (including CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB), always under responsible disclosure. If your organisation wants to strengthen vulnerability management with external technical audit or managed consumption of CVE feeds, get in touch through contact.