CVEbuzz displays public domain information regarding security flaws in hardware, operating systems and software application. This information is collected from external sources, in particular the (American) National Vulnerability Database (NVD). Accordingly, this website takes no responsibility for the content displayed herein, nor for any consequences that may occur as a result of relying on it, regardless of the reason for possible errors, inaccuracies or other flaws.
The website’s purpose is to organize this information in a user-friendly manner, making it more usable, accessible and easier to understand. To achieve this, it translates some data that is represented in numeric or other encoded formats into short verbal summaries of its meaning. For example, the “Damage” and “Attack conditions” sections for each CVE record are verbal translations of the metric vector strings which are attached to each CVE.
As the accurate meaning of this encoded data is typically more detailed than a few words, these translations are somewhat inaccurate at times. However inaccuracies in these verbal descriptions are by far more often a result of the information source, rather than its translation.
This principle holds true for other peculiarities which may be observed in this website. By making the information easier to comprehend, and organizing it in a structural manner, obvious flaws in the original information are often easily spotted. The rest of this page is dedicated to explaining the processing chain of the information, mainly for the sake of understanding the reason of errors in specific cases, and help reporting them correctly.
Security flaws are detected and reported by various actors, which may be the product vendors themselves, or other entities or persons. The original reports may vary in form and medium, going from official bug reports issued by vendors, through academic papers, bug reporting web interfaces, posts in commercial or personal blogs, to possibly anonymous posts in news groups. This variety of sources and formats makes it difficult for end users to keep track of security issues, and take action to prevent attacks.
The US government supports two non-profit organizations for the purpose of collecting and organizing security reports: MITRE, which handles the administrative part, and NVD, which analyses the reports and adds crucial information to each CVE record.
MITRE coordinates the reports by creating a record for each security issue and assigning it with a unique identifier. This record contains the identifier (e.g. CVE-2017-18037), a verbal description of the security issue (typically a paragraph), and links to references (ftp, http, https). The CVE record is modified several times after being created. In fact, most CVE records start off as empty for the sake of allocating the identifier, and are populated with information in the course of time.
MITRE publishes all CVE records in human-readable format as well as data feeds for processing by machine, however this information source is practically useless, as NVD’s data feeds contain more information (or just the same in the worst case) and are constantly synchronized with this data. Hence the latter’s data sources are preferred.
Even though the CVE records from MITRE contain a verbal description and links to references, significant human effort is typically required to answer simple and important questions: What hardware and/or software products are affected by the security problem? Which versions and releases? How serious is the problem? What kind of bug caused the problem?
This is where the National Vulnerability Database (NVD) comes in. This entity analyses the CVE information, adds pieces of information to each CVE record, and publishes the enriched CVE records on their web site in human readable format as well as machine friendly ones. There are several components added by NVD. A brief and incomplete outline is given next.
The most important piece of information is which products the CVE record is related to. The challenge with this information is to make it readable by machine. For this purpose, NVD publishes a dictionary (as an XML file), which is a list of all products which NVD relates or might relate to in their CVE records. Each product is listed with several attributes for each product, with two of particular importance: A human readable title (e.g. “Microsoft Windows 10 1607 64-bit”) and a Common Platform Enumeration (CPE) string, e.g. “cpe:2.3:o:microsoft:windows_10:1607:*:*:*:*:*:x64:*”.
The CPE strings in the dictionary are matched against specification of product ranges in NVD’s CVE records. For example, CVE-2020-1395 is listed with a match string “cpe:2.3:o:microsoft:windows_10:1607:*:*:*:*:*:*:*”, which includes the CPE string mentioned above, as a “*” wildcard matches against the “x64″ part. CPE matching in CVE records often involves a version range attribute rather than pin-pointing each affected version.
Another, more high-profile piece of information, is scoring: Each CVE record is given a number between 0 and 10, essentially estimating how bad things are. For the purpose of this assessment, a predefined list of questions are asked about the CVE, regarding the difficulty to exploit the security flaw as well as the damage it may cause. Based upon these criteria, a score is calculated with a heuristic formula. The idea is that a security flaw which requires physical access with administrative privileges and can only cause a reduction of performance should get a low score. On the other hand, if the exploit can be made by anyone from anywhere on the network, and obtain full control of the system, the score should go towards 10.
There are two main scoring methods currently used: CVSS v2.0 and CVSS v3.1. Some CVE records supply one of these, some both. They differ somewhat in the specific criteria as well as their heuristic formula. It’s not unusual that CVEs have completely different CVSS scores between the two versions.
Generally speaking, scoring should be taken with a grain of salt.
Last, NVD also maintains a dictionary of common bugs that cause vulnerabilities, referred to as Common Weakness Enumeration (CWE). CVEs are often assigned one or a few references to this dictionary.
This website is the third part in the CVE processing chain: It regularly collects the data feeds provided by NVD, and maintains an updated database of the aggregated information. As mentioned above, it translates some encoded information into concise verbal format, with a possible slight loss of accuracy.
The data feeds are collected several times a day, however a full synchronization with NVD’s feeds is assured only within 24 hours.
This website also makes several heuristic decisions to mitigate inconsistencies in the data sources, in particular for tackling duplicates and poor assignment of product names and versions. While rare, these heuristics may fail, and cause incorrect display of information.
The website provides several lists of information:
Even through the maintenance of a CVE record is formally structured, there is room for inconsistencies as well as errors regarding translating real-life information into machine-readable data. This applies in particular to formation of CPE strings in the dictionary, as well as properly defining the match strings for the product versions that are affected by a CVE. A few common issues are listed below.
This website plays the role of making raw information that is available from external sources more accessible. It does so in line with the terms and conditions of those publishing that raw information, and in accordance with the purpose for publishing it.
Displaying information in a concise way opens for spotting errors and inconsistencies. As this site contains a vast number of pages, it’s impossible to track and report these. Users are encouraged to rectify these issues by reporting them directly to NVD and MITRE, as explained on this separate page.
General inquiries can be sent to .