↓ Skip to main content
A blog about stuff I do
A blog about stuff I do
  1. Posts/

How comes there is already a CVE-2026-21858, 20 days into 2026 ? A story of CVE Number attribution and the joys of decentralization

·581 words·3 mins
Lacroix Raphaël (Chepycou)
Author
Lacroix Raphaël (Chepycou)
I’m Raphaël LACROIX, a French computer scientist developping various applications in my free time ranging from definitely useless to somewhat usefull. I also do quite a lot of Capture the flag and cybersecurity challenges. I am currently looking for a Penetration Tester position in Toulouse (or in full remote).
Table of Contents

I was listening to the show made by the lads at @defenders_pod and in last week’s episode they were speaking about the Ni8mare CVE and one of the hosts said something along those lines

Somehow Chris, and maybe I’m not that good with numbers, but for some reason I thought that in the CVE - year - integer, I thought that final integer for some reason like reset at the beginning of every year. I don’t know why I thought that, but I did. But apparently it doesn’t.

I indeed though the same thing, but it’s hard to believe that in the few days between New Year’s Eve and the release of CVE-2026-21858 and CVE-2025-68613, that many vulnerabilities were found. So I decided to look into that. Spoiler : Decentralization is the reason behind this number chaos.

The Number actually “resets”
#

Indeed the number does not carry over from the last year. The last CVE of 2025 appears to be CVE-2025-69412, which luckily did not force us to start at 69413. So every new year there is a theoretical opportunity for every number to appear in the last integer of 2026’s CVE numbers/

Theoretical ? Why so ?

CVEs are not totally centralized
#

So for a brief history recap, CVE system is meant to provide a reference method for publicly known information-security vulnerabilities and exposures. By this standard it is clear that it needs at least some centralization. It is thus operated by The MITRE (and funded by the US).

But luckily for us, The MITRE is not the only one that can issue CVE numbers, else that juicy web vulnerability you just found could spend months before it is finally revealed and turned into a CV-Enhancer (pardon the joke, that was low). CVEs are assigned by a CVE Numbering Authority (CNA) which can be The MITRE of course, but can also be corporations (ex : Microsoft issuing CVEs on Microslopsoft-related products), or other entities (For instance YesWeHack recently joined the list of CNAs).

These delegated authorities are effectively only delegated ranges or blocks of CVE sequence numbers that they can draw from when assigning IDs. This is how numbers like 24026 (in CVE-2026-24026) can appear relatively early in the year without lower numbers being filled in sequentially across the entire list.

Some CVE numbers actually never exist
#

Another consequence of this decentralization is that the end of most range won’t get filled before the end of the year (and even if they did the CNA would kindly ask The MITRE to provide them with another range in case another CVE comes around, and they have to assign it). From what I could find about 48,185 CVEs were published with some IDs reaching at least around the 70.000s.

The N8nghtmare case
#

The CVE that sparked this blog post is even weirder since it was assigned by GitHub (maintainer security advisories) as can be seen here. Unlike the bigger CNAs that receive fixed, pre-allocated blocks or ranges of CVE IDs per year from the root CNA, GitHub’s seems to use on-demand reservation from the overall CVE pool via the CVE services/API.

I hope this non-technical blog post was as interesting to read as it was for me to write it. This being not my usual field of expertise, if you have some corrections or interesting pieces of information (idk, you may work in a CNA while I learned about them a week ago) don’t hesitate to contact me.