Vulnerability Notes Elements
Vulnerability Tracking ID
We track vulnerability reports and publish Vulnerability Notes using a "Vee-You-Pound" number, e.g., VU#647177. VU# numbers often, but not always, have six digits. An individual vulnerability within a Vulnerability Note may be identified with either a CVE ID or a VU# number followed by a "dot" serial number, e.g., VU#647177.1.
The title is a short description that summarizes the nature of the problem and the affected software components. 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.
We accept assertions from vendors that they are "Not Affected" unless we have strong evidence to the contrary.
This is the date that we notified the vendor of the vulnerability. In some cases, this may be the date that the vendor first contacted us, or it may be the earliest date when the vendor is known to have been aware of the vulnerability (for example, if the vendor published a patch or an advisory).
This is when the vendor first provided a Vendor Statement.
This is when the vendor information was last updated.
This is the vendor's official response to our queries about the vulnerability. Vendors can provide their own statements, which we reproduce verbatim (or very rarely with minor formatting and grammar edits). While we try to resolve disagreements and misunderstandings, we accept that a vendor may disagree with us, and the Vendor Statement provides a way to convey the vendor's position.
We suggest that the vendors include relevant information about correcting the problem, such as pointers to software updates and security advisories.
We are highly confident that this information in this comes from the vendor. Statements are usually authenticated through VINCE, PGP-signed, or published by the vendor.
References are URLs provided by the vendor or the CERT/CC. If there are no references then this element heading will not appear.
This element is provided by the CERT/CC and may include additional information or commentary on a specific Vendor Record.
Unless otherwise requested, we acknowledge individuals and organizations who report vulnerabilities to us. This element identifies who reported the vulnerability, anyone who was instrumental in the development of the Vulnerability Note or assisted significantly in the coordinated vulnerability disclosure process, and the primary author of the Vulnerability Note.
Other information included in a vulnerability noteThese elements provide additional information about the Vulnerability Note.
CVE ID is used by Common Vulnerabilities and Exposures (CVE) IDs are used to uniquely identify a vulnerability. The ID is also a link to additional information on the NIST National Vulnerability Database (NVD) web site about the vulnerability. While the . In some cases, a Vulnerability Note may not include CVE IDs. The mapping between CVE names and vulnerability IDs are usually IDs and VU# numbers may not be one-to-one, in some cases multiple vulnerabilities may map to one CVE ID, or vice versa.
If a US-CERT Alert was published for this vulnerability, this field will contain a pointer to the alert.
If a CERT Advisory was published for this vulnerability, this field will contain a pointer to the advisory. Beginning January 28, 2004, CERT Advisories became a core component of US-CERT Alerts.
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 Vulnerability Note was first published, when an exploit was first discovered, when the vendor first distributed a patch an update 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 datemade public.
Date First Published
This is the date when we first published the vulnerability note. This date should be the date public or laterVulnerability Note.
Date Last Updated
This is the date the vulnerability note 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 statementschanges.
This number is updated when the Vulnerability Note is modified and republished.
These elements appear in some older Vulnerability Notes.
If a US-CERT Alert was published for this vulnerability, this field will contain a reference to the alert.
If a CERT Advisory was published for this vulnerability, this field will contain a reference to the advisory. Beginning January 28, 2004, CERT Advisories became a core component of US-CERT Alerts.
Note: Vulnerability Notes published after March 27, 2012 will use CVSS metrics instead, and Vulnerability Notes published after May 2020 contain neither the Severity Metric nor CVSS metrics.
The metric value is a number between 0 and 180 that assigns an approximate severity to the vulnerability. This number considers several factors, including:
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. 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).
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 we notified the vendor of the vulnerability. In some cases, this may be the date that the vendor first contacted us, or it may be 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 provided a vendor statement.
This is when the vendor information was last updated. As vendors produce patches and publish advisories, vendor statement, vendor information or addendum fields may be updated, affecting this date.
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. We are highly confident that information in this field comes from the vendor. Statements are usually PGP signed or otherwise authenticated.
This is information we are reasonably confident is from the vendor. Typically this includes public documents (that were not sent to us by the vendor) and statements that are not strongly authenticated.
URL references to information from the vendor about the vulnerability. This field does not appear unless we have populated it with URL references.
This addendum is one or more paragraphs of text from us commenting on this vulnerability. These are not statements from the vendor, and they 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.
If you have additional questions about the fields contained in our database, please let us know.