Vulnerability Notes Field Descriptions

The Vulnerability Notes database contains two types of documents. Vulnerability Notes, which generally describe vulnerabilities independent of a particular vendor, and Vendor Information documents, which provide information about a specific vendor's solution to a problem. The fields in each of these documents are described here in more detail.


Vulnerability Notes

Vulnerability ID

Vulnerability ID numbers are assigned at random to uniquely identify a vulnerability. These IDs are four to six digits long, and are usually prefixed with "VU#" to mark them as vulnerability IDs.

The vulnerability name is a short description that summarizes the nature of the problem and the affected software product. While the name may include a clause describing the impact of the vulnerability, most names are focused on the nature of the defect that caused the problem to occur.

The overview is an abstract of the vulnerability that provides a summary of the problem and its impact to the reader. Please note that the overview field is a recent addition to this database, so earlier documents may not include this information.

The vulnerability description contains one or more paragraphs of text describing the vulnerability.

The impact statement describes the benefit that an intruder might gain by exploiting the vulnerability. It also frequently includes preconditions the attacker must meet to be able to exploit the vulnerability.

The solution section contains information about how to correct the vulnerability. While vendor-specific patch information will be published in the appropriate vendor information document, the solution section will provide more general workarounds or solutions like "Apply a patch," or "Disable the service."

This section includes a list of vendors who may be affected by the vulnerability. In most cases, vendors listed here have been notified and given technical information about the vulnerability. The vendor name is a link to more detailed information from the vendor about the vulnerability in question. Additional summary information is provided for each vendor as well, including a status field indicating whether the vendor has any vulnerable products for the issue described in the Vulnerability Note, and an updated date showing when the vendor information was last updated.

The references are a collection of URLs at our web site and others providing additional information about the vulnerability.

This section of the document identifies who initially reported the vulnerability, anyone who was instrumental in the development of the document, and the primary author(s) of the document.

This is the date on which the vulnerability was first known to the public, to the best of our knowledge. Usually this date is when the Vulnerability Note was first published, when an exploit was first discovered, when the vendor first distributed a patch publicly, or when a description of the vulnerability was posted to a public mailing list. If you're aware of a public reference to the vulnerability that appeared prior to our date, please let us know. By default, this date is set to be our Vulnerability Note publication date.

This is the date when the Vulnerability Notes was first published. This date should be the date public or later.

This is the date the Vulnerability Note was last updated. Since each Vulnerability Note is updated as we receive new information, this date may change frequently. This date is also updated when a vendor information document changes for the Vulnerability Note so that you can easily locate notes with new information in the vendor statements.

If a CERT Advisory was published for this vulnerability, this field will contain a pointer to that advisory.

The CVE name is the 13 character ID used by the "Common Vulnerabilities and Exposures" group to uniquely identify a vulnerability. The name is also a link to additional information on the CVE web site about the vulnerability. While the mapping between CVE names and vulnerability IDs (VU#s) are usually pretty close, in some cases multiple vulnerabilities may map to one CVE name, or vice versa. CVE and VU# IDs are assigned using different criteria.

The metric value is a number between 0 and 180 that assigns an approximate severity to the vulnerability. This number considers several factors, including


• Is information about the vulnerability widely available or known?
• Is the vulnerability being exploited in the incidents reported?
• Is the Internet Infrastructure at risk because of this vulnerability?
• How many systems on the Internet are at risk from this vulnerability?
• What is the impact of exploiting the vulnerability?
• How easy is it to exploit the vulnerability?
• What are the preconditions required to exploit the vulnerability?

Because the questions are answered with approximate values that may differ significantly from one site to another, users should not rely too heavily on the metric for prioritizing vulnerabilities. However, it may be useful for separating the very serious vulnerabilities from the large number of less severe vulnerabilities described in the database. Typically, vulnerabilities with a metric greater than 40 have been candidates for an Advisory or Technical Alert. The questions are not all weighted equally, and the resulting score is not linear (a vulnerability with a metric of 40 is not twice as severe as one with a metric of 20).

NOTE: This metric is primarily designed to help decide whether or not to publish an Advisory or Technical Alert. The metric and the factors it considers may or may not be meaningful to the reader - in other words, the metric may not accurately convey severity to different readers. The metric may provide some relative severity of vulnerabilities as they affect the entire Internet, but the metric does not necessarily apply to individual sites.

This field contains the revision number for this document. You can use this field to determine whether the document has changed since the last time you viewed it.

This is the date that the vendor was notified about the vulnerability. In some cases, this may be the date that the vendor first contacted CERT, or the earliest date when the vendor is known to have been aware of the vulnerability (for example if they published a patch or an advisory).

This is when the vendor information was last updated. As vendors produce patches and publish advisories, the vendor statements or addendums may be updated, affecting this date.

This field indicates in broad terms whether the vendor has any products that we consider to be vulnerable. In many cases, the relationship between a vendor's products and a vulnerability is more complex than a simple "Vulnerable" or "Not Vulnerable" field. Users are encouraged to read the detailed vendor statements and to use this field only as a broad indicator of whether any products might be vulnerable.

This is the vendor's official response to our queries about the vulnerability. With little more than typographical edits, this information is provided directly by the vendor and does not necessarily reflect our opinions. In fact, vendors are welcome to provide statements which contradict other information in the Vulnerability Note. We suggest that the vendors include relevant information about correcting the problem, such as pointers to software patches and security advisories.

This addendum contains CERT/CC comments on this vulnerability. These are not statements from the vendor, and are usually present when we disagree with the vendor's assessment of the problem, when the vendor did not provide a statement, or when we believe that we can contribute something in addition to the vendor-supplied statement.