A researcher specializing in Software Supply Chain security named Dan Lorenc recently raised an interesting topic on LinkedIn. 138 new vulnerabilities in open-source projects were all entered the same day to the CVE database.

To understand what the problem is there are a few things you’ll need to know.

• CVSS – The Common Vulnerability Scoring System (CVSS) is a system widely used in vulnerability management programs. CVSS indicates the severity of an information security vulnerability, and is an integral component of many vulnerability scanning tools.
• CVE – Common Vulnerabilities and Exposures (CVE) is a list of publicly disclosed vulnerabilities and exposures that is maintained by MITRE.
• NVD – The National Vulnerability Database (NVD) is a database, maintained by the National Institute of Standards and Technology (NIST), that is fully synchronized with the MITRE CVE list.

The Common Vulnerabilities and Exposures (CVE) database is used to list publicly disclosed computer security flaws. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services).

The NVD provides enhanced information above and beyond what’s in the CVE list, including patch availability and severity scores. NVD also provides an easier mechanism to search on a wide range of variables.

The way it should work is that vulnerabilities are first discovered, then reported to the CVE Program. The reporter requests a CVE ID, which is then reserved for the reported vulnerability. Once the reported vulnerability is confirmed by the identification of the minimum required data elements for a CVE record, the record is published to the CVE List.

Details include but are not limited to affected product(s); affected or fixed product versions; vulnerability type, root cause, or impact; and at least one public reference.

When you register a CVE you typically get it with the year you request it and so new CVE IDs would start with CVE-2023. However, Lorenc says that an unknown party has submitted a bunch of CVEs which are backdated and have a high CVSS score.

For example, CVE-2020-19909 was listed as an integer overflow vulnerability in tool_operate.c in curl 7.65.2 via a large value as the retry delay.

In the screenshot you can see that the entry is “DISPUTED”

In his blog Daniel Haxx, a Swedish open source developer and curl maintainer, explains that this is not a security vulnerability. It was, in fact, a bug reported and fixed in 2019. Haxx criticizes the NVD for not trying very hard to actually understand or figure out the problem they grade.

As Lorenc pointed out, it looks as if a bot or AI has been scraping old issues and commits and filing them in an automated fashion, without ever getting maintainers involved.

The problem is that many have automated scanning for vulnerabilities or are using specialized vulnerability triage or management platforms. When no maintainers are involved or even notified about these non-issues, they may live on. Many of these scanners will not see or disregard the “DISPUTED” status and will end up wasting a lot of precious time that could have been spent on actual vulnerabilities.

The question that remains: Is there a fundamental problem with the CVE reporting process which allows for the automated submission of bogus vulnerabilities?

Let's say that the experts agree that any form of automated filing of CVEs without any previous contact with the developers/maintainers of the list completely misses the whole point of getting vulnerabilities fixed before they are made public. And filing vulnerabilities that are in fact bugs that were resolved long ago is a weird form of fear mongering.

Knowing this can happen, by accident or on purpose, warrants a more robust checking than looking for the minimum required data elements for a CVE record.

We don’t just report on vulnerabilities—we identify them, and prioritize action.

Cybersecurity risks should never spread beyond a headline. Keep vulnerabilities in tow by using Malwarebytes Vulnerability and Patch Management.