What Is a CVE? How Vulnerability IDs and CVSS Scores Work

A CVE is a unique ID number — formatted like CVE-2026-41089 — that the security industry uses as a shared name for one specific software or hardware flaw, and a CVSS score is a 0.0-to-10.0 number, backed by a standard formula, that estimates how severe that flaw is; together they're the two pieces of information you need to decide how fast you (or your IT team) should install a patch.

What Is a CVE Identifier?

CVE stands for Common Vulnerabilities and Exposures. It's a catalog, run by the nonprofit MITRE Corporation under the CVE Program, that assigns a single, standardized identifier to each publicly disclosed security flaw in software or hardware. Before CVE existed in 1999, different vendors and security tools often used their own private names for the same bug, which made it hard to tell whether two advisories were describing the same hole or two different ones. A CVE ID fixes that: it's the common language that a Microsoft advisory, a scanner report, and a news story about the same flaw can all point to.

Every CVE ID follows the pattern CVE-YYYY-NNNN, where YYYY is the year the ID was assigned (not necessarily the year the bug was found or fixed) and NNNN is a sequence number that can run to seven digits or more. The ID itself doesn't tell you anything about severity — a CVE from 2026 isn't automatically newer or worse than one from 2021. Log4Shell, one of the most damaging vulnerabilities of the last decade, is still tracked as CVE-2021-44228 even though fixes and advisories about it continued for years afterward.

Who Assigns CVE IDs: MITRE and CNAs

MITRE doesn't personally hand out every CVE ID. Instead, the CVE Program delegates that job to a network of organizations called CVE Numbering Authorities, or CNAs — vendors, open-source projects, security researchers, bug-bounty platforms, and national CERTs that have been authorized to reserve and publish CVE records for flaws in their own products or within their scope. When Apache Software Foundation disclosed Log4Shell, for example, it was Apache itself — acting as the CNA for its own projects — that reserved and populated the CVE-2021-44228 record, not a MITRE employee manually writing it up.

If a vendor isn't a CNA, or a researcher finds a flaw in a product with no clear CNA coverage, the request can go to MITRE directly, which also acts as a "CNA of Last Resort." CISA also operates as one of the program's small number of Top-Level Root organizations, alongside MITRE, coordinating the broader CNA hierarchy. This distributed model is why thousands of new CVE records can be published every week without a single bottleneck.

The CVE Lifecycle: Reserved to Published

A CVE record moves through a small set of states. It starts as RESERVED: a CNA sets aside an ID for a flaw it's investigating, often well before any public details exist, so the ID can be referenced in a future advisory without tipping off attackers early. Once the CNA has a description, affected products, and references ready, the record becomes PUBLISHED and the details go live on the CVE List. A smaller number of records end up REJECTED — typically because the report turned out to be a duplicate, not a real vulnerability, or withdrawn by the CNA.

You can see this lifecycle in a real record's own metadata. Log4Shell's CVE-2021-44228 entry shows a reservation date of November 26, 2021, and a publication date of December 10, 2021 — a two-week gap during which Apache was already working on a fix before the public record, and the wider warnings that followed, went live. That reserved-to-published gap is also why security teams sometimes see a CVE ID mentioned in a vendor's own release notes days or weeks before the full CVE record with technical details appears.

What Is CVSS and What Does It Measure?

CVSS — the Common Vulnerability Scoring System — is the standard formula the industry uses to turn a vulnerability's characteristics into a single comparable number from 0.0 to 10.0. It's maintained by FIRST.org (the Forum of Incident Response and Security Teams), and the current version in wide use is CVSS v4.0, alongside the still-common CVSS v3.1.

A CVSS Base Score combines two sub-scores: an Exploitability score (how easy the flaw is to reach and trigger — factors like whether it needs network access, how complex the attack is, whether the attacker needs any privileges or user interaction) and an Impact score (what happens to confidentiality, integrity, and availability if the attack succeeds). CVSS v4.0 adds further optional metric groups on top of the Base score — Threat (whether working exploit code is known to exist), Environmental (how the vulnerability affects a specific organization's actual systems), and Supplemental (extra context like whether the attack is automatable) — but the Base score is the number you'll see quoted in almost every news headline and vendor advisory.

It's worth being precise about what that Base number is not: FIRST's own specification describes it as reflecting a vulnerability's "intrinsic characteristics," assuming a reasonable worst case — it is explicitly not a full risk score, since it says nothing about whether a given organization actually runs the affected software, has it exposed to the internet, or has compensating controls in place. CVSS tells you how bad the flaw is in the abstract; your own exposure determines how bad it is for you.

CVSS Severity Ratings: None, Low, Medium, High, Critical

To make the 0–10 scale easier to talk about, FIRST also defines qualitative severity bands. These ranges are identical across CVSS v3.1 and v4.0:

In practice, most of the vulnerabilities that make headlines sit in the High or Critical bands, because those are the ones that tend to combine easy remote exploitation with serious impact. Log4Shell scored a perfect 10.0 (Critical) under CVSS v3.1, reflecting that it could be triggered remotely, needed no authentication or user interaction, and could lead to full system compromise. By contrast, a flaw that needs an attacker to already be logged in locally, or that only lets them crash a single process, will typically land in the Low or Medium band even if it's a genuine, patchable bug.

CVE vs. NVD vs. CVSS: What's the Difference?

These three terms get used almost interchangeably in headlines, but they're distinct pieces of a pipeline. CVE is the identifier and the baseline record — the "what is this flaw" catalog entry maintained by the assigning CNA. CVSS is the scoring formula itself, maintained by FIRST.org, independent of any single vulnerability. NVD, the National Vulnerability Database, is NIST's U.S. government database that ingests every published CVE record and enriches it — adding its own independently calculated CVSS score, mapping it to standardized weakness categories, and tracking affected product versions.

That enrichment step matters because a CNA's own CVSS score and NVD's score for the same CVE can differ. NVD analysts work through published records in stages — tagged internally as Received, Awaiting Analysis, Undergoing Analysis, and finally Analyzed, with some records marked Deferred or Rejected along the way — and when NVD finishes its own review, that score is recorded separately as the "Primary" NVD metric, distinct from whatever score the CNA originally published. So it's entirely normal to see one CVSS number quoted by a vendor and a slightly different one quoted by NVD for the same CVE ID; both are legitimate, they're just produced by different reviewers. When CISA flagged an upload vulnerability in Adobe Commerce as critical, for instance, that severity rating traced back to exactly this kind of CVSS scoring on the underlying CVE record.

CISA's KEV Catalog: Why "Is It Being Exploited?" Matters More Than the Score

A high CVSS score tells you a flaw is dangerous in theory. It doesn't tell you whether anyone is actually using it to break into real systems right now — and that second question is often more urgent. That's the gap CISA's Known Exploited Vulnerabilities (KEV) catalog fills. CISA describes it as "the authoritative source of vulnerabilities that have been exploited in the wild," and each entry lists the CVE ID, the affected vendor and product, and a required action and due date for remediation, with current entries tied to compliance under CISA's Binding Operational Directive BOD 26-04 on prioritizing security updates based on risk.

A CVE can be Critical-severity under CVSS and never appear in KEV, if no one has been caught exploiting it. Conversely, a comparatively modest Medium-rated bug can land in KEV the moment attackers start using it in real campaigns, which is exactly why security teams are told to treat KEV listing as an independent, often higher-priority signal than the CVSS score alone. A Critical-severity Windows Netlogon flaw, tracked as CVE-2026-41089 and scored 9.8 by NVD, is a good example of the pattern: the severity score alone already argued for urgent patching, and active-exploitation reporting is exactly the kind of evidence that can push a CVE onto the KEV list and shorten the realistic patching window further.

Patch Tuesday and Coordinated Disclosure

Most major vendors — Microsoft most famously, with its monthly "Patch Tuesday" release on the second Tuesday of each month — batch their security fixes into scheduled updates rather than shipping a patch the instant a bug is found. This is part of a broader practice called coordinated disclosure: the CNA, researcher, and vendor typically work together privately on a fix before the CVE record is published, so attackers don't get a head start exploiting a known, unpatched hole. That's also why CVE records are so often published, or substantially updated, on the same day a vendor ships its monthly or quarterly security update — the RESERVED-to-PUBLISHED gap described earlier is frequently timed to line up with the patch's release. A server-backdooring bug in Nextcloud or an authentication-token flaw in Microsoft Authenticator each followed this same rhythm: a CVE reserved during private remediation work, then published alongside the fix so defenders learn about the flaw and the patch at the same moment.

How to Use a CVE ID and CVSS Score When Deciding How Urgently to Patch

For an everyday reader or IT admin, the practical workflow is simpler than the mechanics behind it:

1. Find the CVE ID in the vendor advisory or news story, then look it up on cve.org or NVD to confirm what product and versions are actually affected — not every CVE in a headline touches every version of a product.
2. Check the CVSS Base Score and severity band. Critical and High scores generally deserve same-week (or same-day) attention; Medium and Low can usually wait for a normal patch cycle, unless other factors change that.
3. Check whether it's in CISA's KEV catalog. Active exploitation in the wild should override a lower CVSS score — if attackers are already using it, the patching clock is effectively already running regardless of the number.
4. Weigh your own exposure. A Critical flaw in software you don't run, or that's not reachable from the internet, is a lower practical priority than a Medium flaw in something internet-facing that you use every day.

What to Do Next

CVE IDs and CVSS scores aren't going away, and the volume of both keeps climbing — NVD alone processes thousands of new or updated records every month. The good news is that you don't need to track every one. Most people only need to act when a CVE affects software they actually use, scores High or Critical, or turns up in CISA's KEV catalog. Bookmarking cve.org and nvd.nist.gov, or following the advisories issued directly by the vendors of the software you rely on, is usually enough to catch the ones that matter. For the related but distinct question of what happens when a flaw is exploited before any CVE or patch exists at all, see our explainer on zero-day vulnerabilities.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage