As explained in the About page, CVEbuzz displays information that is collected from external sources. Errors that appear on this website are therefore most likely a result of errors in the data arriving from those sources, including errors that may appear obvious or trivial. Accordingly, they should be reported to those maintaining the relevant data, and not to this website.
This website attempts to display information in a human-friendly manner. By doing so, it often reveals errors and contradictions that are difficult to spot when the information is rendered as common in other places.
In order to investigate the reason of a displayed error, it’s recommended to visit NVD’s web page for the specific CVE advisory, by clicking the CVE identification code at the top of the advisory item on this website. As NVD’s presentation of the information is closer to the original data representation, it’s more useful for spotting inconsistencies, however a deeper technical understanding of the CVE processing mechanism is required.
The About page also outlines the roles of MITRE and NVD in maintaining CVE records, as well as outlines some common issues. It’s recommended to read through that part, and possibly refer to other sources for a better understanding of errors and inconsistencies in the content of this website.
Unfortunately, errors and inconsistencies in the external data feeds are quite common. This is an incomplete list of issues that may be encountered, along with suggestions on how to respond to them.
Sometimes it’s evident that a CVE isn’t listed for a product version it should, or vice versa. In particular, in lists of affected versions for a CVE, it’s quite common to find small islands of one or a few versions which stand out from a group: A few lines on green (non-affected) versions among a lot of red (affected versions), or vice versa. This is virtually always a result of the CVE record having poorly written version matching expressions.
A common reason is that the matching relies on listing the affected versions one by one rather than defining a range (and hence missing a few versions that are listed in the dictionary). Also, the CPE strings for some of the products may be malformed, and may therefore not match when they should or vice versa.
Sometimes the CPE strings for certain products are changed, and the old ones are deprecated, resulting in partial or no match between the CVE record and the products it relates to.
There are also a CVE records with completely malformed matching. For example, CVE-1999-0236, which oddly enough matches all versions of Apache’s web server, even though the problem has surely been solved since then. Consequently, this CVE appears for all versions, for example this one.
For analysis of problems of this sort, note that the CPE string or strings are shown at the top of the page. CVEs that match any of some of these are listed on that page, including CPE strings shown with a strike-through line (indicating that they are deprecated, but nevertheless matches against for that page). The match rule CPE or CPEs for each listed CVE is also shown.
Visiting NVD’s page for the problematic CVE may also be helpful, as it outlines both the matching rules as well as the matched product CPEs.
Whether the problem turns out to be the matching rules or the CPEs of products, it should be reported to NVD, as they maintain both.
Errors should be reported to where they can be fixed: In most cases, it’s NVD, but issues with CVEs’ descriptions and references should be reported to MITRE. Either way, it doesn’t help reporting errors to this website, as it doesn’t maintain the records, but only displays it.