The year in a CVE ID is not a trustworthy date for when a flaw was found or made public. The CVE record format stores real dates in separate fields, including when the ID was reserved and when the record was published. Read those, not the year in the name.
What the ID format is
The CVE record format defines an ID with the pattern CVE-YYYY-NNNN, where the number part has four to nineteen digits. The pattern allows long sequence numbers, so a parser that assumes five digits will eventually break. Treat the ID as an opaque label.
Which dates a record carries
The CVE record schema holds metadata the CVE services control. Three dates matter for most readers:
| Field | What it records |
|---|---|
| dateReserved | When the ID was reserved in the CVE services system |
| datePublished | When the record was published |
| dateUpdated | When the record last changed |
The schema carries a warning on the reserved date. It says that date reflects when the ID was reserved and does not necessarily indicate when the vulnerability was discovered, shared with the vendor, publicly disclosed or updated.
A worked example
Take CVE-2021-44228. The record's metadata, fetched from the CVE services API on 18 October 2026, shows a reserved date of 26 November 2021 and a published date of 10 December 2021. The year in the ID matches both here, but two weeks separate the reservation from publication. For an ID reserved in late December and published in January, the year in the name and the year of publication would differ.
The same record shows a last updated date in October 2025, nearly four years after publication. A CVE is a living record.
Why this matters for your work
- Sorting by ID year is not sorting by disclosure date.
- A report that says "CVEs from 2026" can mean reserved in 2026 or published in 2026, depending on the tool.
- Age based policies, such as "fix anything older than 30 days", should start from the published date or from the date your tool first saw the record.
Steps to read the right date
- Open the CVE record JSON for the ID.
- Read
cveMetadatafor reserved, published and updated dates. - Note which organisation assigned the ID, shown as the assigner short name.
- In your own tracker, store the date you first saw it, because that is the clock your team lives by.
Safeguard offers SBOM and dependency scanning plus policies and gates, so an age based rule can be enforced in a pull request. A free scan shows your dependencies today.
Quick check
Can a CVE be published in a different year than its ID?
Yes. The ID year does not bind the publication date, and the record stores the published date separately.
Is the reserved date the date the bug was found?
No. The schema itself says the reserved date does not necessarily show discovery, disclosure to the vendor or public disclosure.
Sources
Last reviewed: 19 October 2026.
