CVE: what the identifier of a vulnerability means

The identifier has three parts: the prefix CVE, a year, and a sequence number. The year is the year the identifier was assigned, or the year the flaw became public if that happened before assignment. It is not the year the flaw came into existence. The sequence number has at least four digits and no upper limit on length, so a single year can hold any number of records.

Nothing more can be read from the identifier. It doesn’t say how serious the flaw is, whether an exploit exists, or which product it concerns. All of that is the content of the record the identifier points to, and it changes over time.

An identifier is first reserved and only published later. The authorized organization reserves it when it accepts the finding, and between reservation and publication the fix is being worked on. A record can therefore exist for weeks as nothing but a number without a description, which is the state that causes the most confusion. With our CVE-2026-39042, 98 days passed between the reservation on April 6, 2026, and publication on July 13, 2026.

After publication the record keeps changing: the range of affected versions, links to the fix, the flaw category, and the score get added. The description you read in the morning can look different in the afternoon. A contested record can also be marked as disputed, and a wrongly assigned one gets rejected, so not every number you see somewhere describes a live vulnerability.

A CVE can be verified in two databases, and it pays to know how they differ. The CVE List, the program’s own catalog, holds the record as the authorized organization submitted it. The National Vulnerability Database (NVD) adds a severity rating, a flaw category, and a machine-readable list of affected versions on top of the same record, so it answers faster whether your version is affected.

The type of flaw is described by a third catalog, and that one gets confused with CVE most often. Whereas a CVE denotes one occurrence in one product, CWE describes a class of flaw, for example integer overflow under number 190. One class of flaw thus covers thousands of different CVE records.

CVE doesn’t cover what you wrote or configured yourselves. Identifiers go to flaws in finished software and firmware, meaning what you bought or downloaded. An authorization flaw in your own application, permissions handed out in Active Directory, and an order form that grants a discount without checking will never get a number.

The practical consequence: the list of CVEs on your network and the list of your risks aren’t the same thing. A scanner compares versions against a database and finds only what is in it. The rest has to be tried by hand, and that tends to be exactly the part an attacker uses. What a scanner can’t recognize on its own is covered in the comparison of the two approaches.

The score isn’t part of assigning the identifier; it’s added to the record separately. Most often it’s CVSS, a value from 0 to 10 with a level from Critical to Low. For one record you may therefore run into two different numbers, one from the vendor and one from the database analyst.

What exactly goes into that value, and why the same flaw is rated differently elsewhere, are covered in the entry on how a severity score is added to the identifier. For a first decision, it’s enough to know that the score describes the flaw, not your system.

We have one example of our own: a vulnerability our team found in MikroTik RouterOS. It went through disclosure to the vendor and received the identifier CVE-2026-39042.

The public CVE-2026-39042 record in the NVD is dated July 13, 2026, and carries a rating of 7.5 (High). The write-up of what the flaw does and where in the system it sits belongs to the infrastructure testing page, where the finding originated.

When a CVE applies to your systems, go through four steps, and the order matters. Panic from the morning newsletters ends at the first step every time the reported version and yours don’t match. Only when they do is it worth dealing with the rest.

• Verify the version and configuration against the record, including whether the vulnerable feature is even enabled.
• Find out where the system is reachable from: the internet, the user network, or only the administrative segment.
• Deploy the fix. If there is none, restrict access or disable the feature the flaw abuses.
• Verify the result. A changed version number isn’t proof that the flaw is gone.

Step two decides whether the fix happens tonight or in the next maintenance window. Without an inventory of what you run, though, none of those steps can be done in time.