One of the aspects of vulnerability intelligence is monitoring various public sources for new vulnerabilities, especially ones with a Common Vulnerabilities and Exposures (CVE) ID. These numbers are designed to help communicate details about a specific vulnerability. “Hey, remember that remote code execution in Fortinet in May?” Unfortunately, that isn’t very specific as there were at least six of them. Instead, it is more common to see references such as “Remember that nasty Fortinet vulnerability, CVE-2024-23113?” That gives a level of specificity that removes any confusion as to which of the issues is being discussed.
Jumping back ten years now, the CVE program had a fairly significant change when it moved from static four-digit numeric identifiers to four+. At the time we had identifiers like CVE-2014-1234 but that was the limit. If there were to be more than 10,000 vulnerabilities in a year, MITRE would have to adapt. And so they did, allowing for as many digits as needed which would future-proof the identification scheme. The next year, we started seeing five-digit IDs like CVE-2015-10001.
Years ago in a last minute stand-in replacement for a speaker that couldn’t attend, I gave a presentation that briefly covered some of the problems we face running vulnerability databases. In that presentation I went into some detail about this scheme change and how it caused problems half a decade later. MITRE went though great lengths to help ensure that everyone got the message and that the change would not break any CVE implementations. For those that hardcoded the four-digit identifier, new five-digit IDs would be problematic in various ways. It didn’t take long to see that happen; worse, many of the CVE Numbering Authorities (CNA) had problems and didn’t realize it until I pointed it out.
One of the things MITRE did was reserve eight valid, but REJECTed 2014 IDs that were designed to intentionally break systems as a last minute warning to everyone. For those not prepared, the sudden appearance of CVE-2014-123456 might have caused havoc. For others though, they didn’t notice as their implementations just truncated the ID to CVE-2014-1234. Obviously, this is very bad and leads to a world of confusion. You can read more about all of this from the CVE Editorial Board (now just the CVE Board) mail list at the time.
Jump to today and what are we seeing? It seems most everyone has adapted to the five-digit+ scheme, which is great! However, I occasionally see projects decide to use arbitrary CVE IDs as “sample” IDs. Sometimes they conflict with a real ID which isn’t bad and doesn’t generally present an issue. But when a new ID is made-up that might become a legitimate CVE ID this year or last, it causes many vulnerability / PSIRT teams to chase it down.
One recent example is a new project on GitHub called “CVE_HUB”. In the readme.md file they decided to use CVE-2023-12345 and CVE-2023-12346. Neither of these are currently assigned, but they are actually still fair game to be used potentially. While this only took me a few minutes to track down, and a couple more minutes to create a pull request updating the IDs to use designated sample IDs, that was just me. There are many other teams that use similar methodologies as mine, and they too may have had to figure it out.
So please, if you are writing documentation and need to use ‘dummy’ CVE identifiers, please use one of the ones MITRE designated a decade ago. And MITRE, please create a few dummy IDs each year so people can reference IDs that look more recent. I am sure that would be a stylistic choice so as not to appear outdated. Reserving just CVE-YEAR-12345 and CVE-YEAR-54321 each year would be wonderful. Until then, here are the designated sample IDs to use:
- CVE-2014-10000
- CVE-2014-100000
- CVE-2014-123456
- CVE-2014-456132
- CVE-2014-54321
- CVE-2014-9999
- CVE-2014-99999
- CVE-2014-999999
Leave a Reply