For those who follow me on Twitter, you may notice a considerable number of my Tweets are related to pointing out or confirming CVE IDs that are typos. Recently I ran into an interesting edge case where a typo CVE ID gained life of its own. Typically such typos gain life through aggregation blogs that simply regurgitate content solely based on keywords it looks for, in an effort to capture ad revenue. This time was different.
What should have been CVE-2017-17479 gained an unintentional extra digit and became 2017-171479. Normally this could be easily dismissed as 2017 had no CVE IDs with a six digit ID. Ignoring the DWF project, which used seven digit IDs, until recently there had been no IDs in the history of the CVE program using more than five digits. So 2017-171479 becomes easy to dismiss, right?
Unfortunately, no. On June 19, 2022, the VulDB CNA (not to be confused with RBS/Flashpoint VulnDB) assigned eight IDs to older 2014 FFmpeg issues that each had a six digit ID. For example, CVE-2014-125018 covers a memory corruption from February 2014. I don’t know why they deviated and used a six digit ID but it certainly stands out. It also tells me that 2017-171479 could be a valid assignment.
Adding to the confusion, not only could 2017-171479 be valid, but it had a full-blown advisory page from a reputable company. Despite that, everything still suggested this was a duplicate / typo of CVE-2017-17479. I emailed SUSE on June 28 and within minutes had a reply from their security team confirming it was indeed a typo and that they would “adjust the metadata so this typo page goes away“. That kind of swift reply and attention is awesome to see.
Typos happen. In the world of CVE IDs they can cause a lot of headache as security teams scramble to determine what an ID represents and if it impacts their organization. When working with such IDs, I strongly recommend cutting and pasting from the original source rather than typing it out. This helps cut down on those pesky typos. But when they do happen, quick attention to these cases is important and can stave off a lot of hassle.
A big thanks to SUSE for such prompt attention in this case!