CVE Lookup

A CVE number is a name, and names are the point. Without a shared name, two security teams can discuss the same bug under different labels and never notice. The CVE system, launched for the public in September 1999, gives each publicly disclosed vulnerability one identifier that everyone can quote, so that people and tools know they are talking about the same thing.

Everything else on a CVE page is commentary attached to that name. Some of it comes from the organisation that assigned the number, some from the US National Vulnerability Database, some from government agencies with their own priorities. Reading a record well starts with knowing which voice wrote which part.

Who gives a flaw its number

The CVE Program describes its mission as identifying, defining and cataloguing publicly disclosed cybersecurity vulnerabilities, with one CVE Record for each vulnerability. The program is maintained by the MITRE Corporation and sponsored by the US Department of Homeland Security and its Cybersecurity and Infrastructure Security Agency, CISA.

MITRE is not the only source of numbers. CVE IDs are also assigned by CVE Numbering Authorities, CNAs: vendors, researchers, open source projects, CERT teams, hosted services, bug bounty providers and consortia that the program has authorised to assign IDs and publish records within their own scope. When the program’s page was read for this essay it listed 557 CNAs from 43 countries. Joining costs no fee and needs no contract.

A record moves through a short life. A reporter asks for an ID and it is reserved, which lets the people coordinating a fix refer to the bug before it is public. Once the minimum facts exist, including the affected product, the kind of flaw and at least one public reference, the responsible CNA publishes the record. A record can later be rejected, and a vendor can dispute it, in which case it carries a disputed tag.

The identifier itself has a fixed shape: the letters CVE, the year, and a sequence number. Since 13 January 2015 that number has had at least four digits and no fixed length, a change made so that a year could hold more than 9,999 IDs. So CVE-2019-1010218, with seven digits, is perfectly ordinary.

Who scores it, and why there can be two numbers

Start with a fact that is easy to miss: the CVE Program does not score anything. The program lists the idea that it assigns severity scores among the myths it corrects. A bare CVE record is a description and a set of references.

Scores arrive from elsewhere. The NVD, run by NIST, takes each new CVE, usually within an hour of publication, and enriches the ones within its scope of coverage. That scope starts with every CVE in CISA’s Known Exploited Vulnerabilities catalog, enriched within one business day of being added, and extends to software used by the federal government and to critical software as defined by Executive Order 14028.

Enrichment means four things: reference tags such as Patch or Vendor Advisory, a weakness class from the CWE list, a CVSS 3.1 assessment, and a configuration that says, in a machine-readable form called CPE, which products and versions are affected. The weakness classes come from CWE view 1003, a subset of the full CWE list that MITRE’s team built with the NVD so that published vulnerabilities map onto a manageable set of names.

The CNA may have scored the flaw too, so a record often carries two CVSS entries for the same version. The NVD’s API marks them as Primary and Secondary sources. They can disagree, and when they do neither is automatically right: each is one analyst’s reading of the same public facts. Older records may also carry a CVSS 2.0 score, which the NVD stopped producing for new records in July 2022.

Reading the vector instead of the number

The score is a summary, and the vector string is the evidence behind it. FIRST, which owns and maintains CVSS, makes it a condition of use that anyone publishing a score also publishes the vector, so that others can see how the number was reached.

Take the example the NVD’s own API documentation uses, CVE-2019-1010218, a buffer overflow in the Cherokee web server up to version 1.2.103 that crashes the program when its command name is overwritten with a very long string. The NVD gives it the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Read left to right, it says the attack works over a network, needs no special conditions, no account and no help from a user, stays within one security boundary, and leaks nothing and changes nothing, but can stop the service completely.

The CVSS 3.1 specification turns those letters into numbers in three steps. The impact sub-score is one minus the product of one minus each impact weight; with only Availability set to High, whose weight is 0.56, it is exactly 0.56. Because Scope is Unchanged, the impact is 6.42 times that, or 3.5952. Exploitability is 8.22 times the four exploitability weights: 0.85 for a network attack, 0.77 for low complexity, 0.85 for no privileges and 0.85 for no user interaction, which comes to 3.8870. The two add up to 7.4822, and the specification’s Roundup function takes it to the next tenth: 7.5, rated High.

Small changes in the letters move the number a long way. Mark the same flaw Scope Changed and the impact formula switches to a steeper curve, the sum is multiplied by 1.08, and the score becomes 8.6. Make it a local attack instead and it falls to 6.2. The same bug under the older CVSS 2.0 formula scored 5.0, Medium. None of these numbers is wrong; they answer slightly different questions.

Roundup sounds trivial and is not. The specification warns that floating point arithmetic can turn 0.1 plus 0.2 into a hair over 0.3, which a careless implementation would round up to 0.4, and it recommends doing the rounding in whole numbers instead. The result is a scale of just 101 scores, from 0.0 to 10.0. FIRST accepts that the formula is an approximation of a ranking made by people, and that some combinations land up to half a point outside their intended severity band.

CVSS 4.0, published in November 2023, goes further from a formula. Its scores come from groups of similar vectors whose values were set by an expert ranking and published as a lookup table, with interpolation inside each group. You can still read every metric of a 4.0 vector, but recomputing its score by hand means consulting that table.

A base score describes the flaw, not your situation

The NVD states it plainly: CVSS is not a measure of risk. The base score describes the intrinsic character of a vulnerability, and the 4.0 specification adds that it assumes the reasonable worst case across every place the software might run. It knows nothing about whether the vulnerable program runs on any machine you own, whether that machine faces the Internet, or whether anyone is attacking it.

CVSS has always had metrics for those questions. Temporal or threat metrics capture whether exploit code exists, and environmental metrics capture how much the affected system matters to you. The NVD supplies neither; it scores only the base. The 4.0 specification asks consumers to add both before treating the result as an input to their own risk assessment.

Evidence of real attacks is often the better signal. CISA keeps the Known Exploited Vulnerabilities catalog as the authoritative list of flaws exploited in the wild and tells organisations to use it as an input to prioritisation. In June 2026 its directive for US federal agencies, BOD 26-04, set remediation deadlines from four questions: is the vulnerable asset exposed to the public, is the CVE in the catalog, can an attacker automate the exploit, and does exploitation give partial or total control. The directive compares that last question to the CVSS idea of severity, which makes the point neatly. The score is one input among several.

Where to look for the fix

The references at the bottom of a record are where action lives, and their tags help you choose which to open first. Tags such as Patch, Vendor Advisory and Mitigation name the links that point toward a fix; Exploit, Issue Tracking and Third Party Advisory describe the problem from other angles. The NVD assigns these tags during enrichment, after reviewing the reference material that came with the record.

The configuration tells you whether you are affected at all. Each entry is a CPE name, a structured string defined by NIST with eleven fields after the version prefix: part, vendor, product, version and seven more. The part is a for an application, o for an operating system and h for hardware. A range such as versions up to and including 1.2.103 is the NVD’s statement of what is vulnerable, and an AND between two entries means the product is vulnerable only when running on the listed platform. For the Cherokee example the submitter wrote that there was no fix yet, which is itself useful: it tells you that waiting for an update is not a plan.

A lookup tool can only show what the record holds. Descriptions come from the CVE side and the NVD has no control over them; how long enrichment takes varies, so a new record may show no score at all; and a quiet record is not proof that a product is safe. The NVD also limits public use of its API to five requests in a rolling 30 seconds and asks programs to pause about 6 seconds between calls, so a careful tool waits between requests rather than hammering it.

Used that way, a CVE page stops being a red or orange badge and becomes what it was meant to be: a shared name, a set of claims you can check, and directions to the fix.