CVE and the matter of “unique” ID numbers

Common Vulnerability Enumeration, now known as Common Vulnerabilities and Exposures (CVE) is a vulnerability database (ignore their silly claim to be a ‘dictionary’) that the information security industry relies on heavily, unfortunately. Per MITRE’s CVE page, “CVE® is a list of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities.” Great, digging a bit deeper into their ‘About‘ page, we get a better definition:

Use of CVE Entries, which are assigned by CVE Numbering Authorities (CNAs) from around the world, ensures confidence among parties when used to discuss or share information about a unique software or firmware vulnerability, provides a baseline for tool evaluation, and enables data exchange for cybersecurity automation.

Please take note that a CVE Entry, or ID number, “ensures confidence” when discussing or sharing information about a vulnerability. Basically, it is supposed to be a unique ID to ensure that confidence. Despite that, any of my dozen loyal Twitter followers will see me constantly pinging researchers, vendors, and the media pointing out that they are using the wrong CVE number to reference a vulnerability. Often times it is a case of not copying and pasting, rather typing it out manually. It is also why in the vulnerability database (VDB) world, we strongly emphasize that copy/paste is the best thing to do in order to prevent transcription errors on an ID that is supposed to be unique.

Sure, it seems pedantic to a degree, but imagine if your doctor decided to manually transcribe a diagnosis code after your visit and you get a call saying you were diagnosed with something completely different. In the vulnerability world, it means you might be vulnerable to something and have no idea if so. If you are, you aren’t sure if there is a solution. Maybe a bit of a dramatic analogy? But.. it holds water, has a bit of recent history, and is the kind that helps administrators better understand the underlying issue.

Instead of sending out a series of Tweets on the latest example, I decided to write a blog to show how these little typos can snowball quickly. Any mature VDB will have a variety of processes to catch wind of a CVE ID that they haven’t seen before. It can be as simple as a live search on Twitter for ‘CVE’ (super noisy) or more technical means. If you run across an unknown CVE you Google it to start, that simple. Today’s example was CVE-2019-0895, which appeared to be a “new windows zero-day”. Exciting in the world of VDBs!

Let me go ahead and spoil things, to make this easier. These articles call it “2019-0895”, but in reality, they actually mean “2019-0859”. A simple transposition of numbers, which is all too common in prior cases. Based on ten-second review, it appears that Fossbytes was the first to transcribe these numbers (Unverified @fossbytes14 on Twitter?). A day later, extremely similar articles appeared on Prodefense (no Twitter and broken Contact form?) and “In Depth IT News / SecNews” which has some serious rendering issues in Chrome. The day after that, Tech Rights references it via a weird embedded link below in an unrelated article [1], and Tux Machines posted about it with key quotes cribbed from other articles, the Fossbytes article in this case.

In each case, it is clear that the offending typo came from Fossbytes. The “In Depth IT News” site even links to https://securelist.com/new-win32k-zero-day-cve-2019-0859/90435/ which has the correct CVE ID in the URL. It is absolutely clear that most of these sites are using automated crap to aggregate content and have no real desire to share accurate news. Each one of them are evidence to the damage caused by a single transposition error from Fossbytes, a “leading source of technology news with a focus on Linux distro releases” … that decided it was important to write about this critical Windows zero day? A critical zero day that is actually ten days old at the time of their article.

OK, hopefully we’re all on the same page here. My Twitter feed is a small graveyard of similar examples from the past few years. Each and every time, the “news” organizations that spread these bad IDs and introduce confusion and questions into the equation, and are the antithesis of a “news” site. Finally, I would like to go on the record about one more bit regarding CVE, which will come as no surprise. On the CVE ‘About’ page, it says CVE is:

Industry-endorsed via the CVE Numbering Authorities, CVE Board, and numerous products and services that include CVE

As a former ten-year veteran of the CVE Board, I do not endorse CVE.


[0] Note: If any of my links show a fixed version of the CVE, good! You can see the originals on archive.today.
[1] This should really be a separate blog post, but it would mostly be cursing around a simple concept; this is the problem with content/link aggregation sites… which are a plague on the Internet. In 2019, they aren’t trying to help, they are desperate attempts to make a few bucks. Disagree? They would have caught this error when they did a quick tech edit pass on the article. But they didn’t, because it is all automated and centered around ‘SEO’ (search engine optimization) so it appears in Google results and you click and see the ads they are serving. I bet if anyone dug deep on such sites, the amount of questionable traffic or malware they delivered might be enlightening. Go back to where this is linked from and notice the URL of the article (/2019/04/18/libreoffice-6-2-3/) and how far you have to scroll to get to the bottom of the page, past all the “content”.