Risk Matrix Glossary – Terms and Definitions for Critical Patch Update Risk Matrices
Revised April 2016.
This page explains the information presented in Critical Patch Update Advisory risk matrices from October 2006 on. Several changes to the format have been made over the years, the most significant being the adoption of new Common Vulnerability Scoring System (CVSS) versions as follows:
Scope and Application
The column headings are listed below in the order they appear in the risk matrix. A summary of their purpose is also given.
CVE# (or Vuln# in older advisories)
The unique identifier of a vulnerability.
Since the July 2008 Critical Patch Update, Oracle has used industry standard Common Vulnerabilities and Exposure (CVE) identifiers. These simplify the identification of Oracle vulnerabilities when referenced in external security reports, such as those produced by security researchers and vulnerability management systems.
Prior to the July 2008 Critical Patch Update, the vulnerability identifier was composed of a two to four character prefix identifying the product suite containing the affected product, and a two character suffix that created a unique identifier within the product suite. Such vulnerability identifiers were unique only within a single Critical Patch Update Advisory.
A vulnerability identifier in italics indicates that it has been copied from another risk matrix. This occurs when code from one product suite is included in another. For example, the Oracle HTTP Server is a core part of the Oracle Fusion Middleware suite, but ships with the Oracle Database as an optional component. In this example, the CVE# for an Oracle HTTP Server vulnerability would be italicized when included in the Oracle Database risk matrix.
The Oracle product that contains the vulnerability.
The product component that contains the vulnerability.
The protocol required to attempt to exploit the vulnerability. It may be possible to reduce the risk of attack by limiting access to this protocol. For example, limiting the machines that can form a direct connection to a database using the Oracle Net protocol limits the potential for attack. This is typically achieved using firewalls or managed switches.
Package and/or Privilege Required
Packages, privileges, roles, responsibilities or other preconditions required to attempt to exploit a vulnerability. It may be possible to reduce the risk of attack by changing a required precondition. For example, if a vulnerability may be exploited only by users with access to a certain database package, revoking untrusted users' access to that package will reduce the number of people who can exploit the vulnerability. Oracle strongly recommends that such changes are first made on a test system as some changes may cause loss of functionality or other unwanted side effects in custom code or other Oracle software.
Remote Exploit Without Authentication?
Indicates if the vulnerability may be exploited by a remote attacker who has on authentication credentials for the targeted system. Vulnerabilities which may be exploitable from a remote network and without authentication are higher risk and marked with a Yes. Vulnerabilities which cannot be exploited remotely or which require authentication are marked with a No.
The value in this column is derived from CVSS information presented in the risk matrix. This column is Yes only if:
CVSS Version Base Risk
The CVSS Base Score, an assessment of risk defined by the Common Vulnerability Scoring Standard (CVSS). The "Oracle's Use of CVSS Scoring" page explains Oracle's implementation of the CVSS standard. Full details of all versions of the CVSS standard, as maintained by the Forum of Incident Response and Security Teams (FIRST), can be found on FIRST's web site at http://www.first.org/cvss.
The CVSS base score assign a numeric value between 0.0 and 10.0 to indicate the severity of the vulnerability, where 10.0 represents the highest severity. Each risk matrix is ordered using this value, with the most severe vulnerability at the top of each risk matrix.
Earliest Supported Release Affected
The earliest supported release vulnerable to a given issue. Supported releases before the one listed are not affected. Unsupported versions before the one listed have not been tested, but may also be affected by a given vulnerability.
This column was used for all risk matrices in Critical Patch Update advisories up to October 2007. It was removed in later advisories as its contents can be derived from the information in the Last Affected Patch Set (per Supported Release) column, which is explained below. This can be done by reviewing the Last Affected Patch Set (per Supported Release) column entry to determine which is the earliest Release associated with a patch set that has an entry in this column. For example, DB05 in the January 2008 Critical Patch Update has 18.104.22.168, 10.1.0.5 and 10.2.0.3 in the Last Affected Patch set (per Supported Release) column. These patch sets are from Oracle Database 9iR2, 10gR1 and 10gR2, respectively. Since Oracle Database 9iR2 is the earliest release, 9iR2 is the entry that would have been placed in the Earliest Supported Release Affected column if it had been retained.
Supported Versions Affected (or Last Affected Patch set (per Supported Release) in older advisories)
For each supported release of a product, the last patch set affected by the vulnerability is listed. If the patch set for a specific release is not listed, no supported versions of that release are affected. Patch sets later than the one listed for a specific release are not affected. Products that do not have the concept of a patch set, have product version listed instead.
In January 2011, the column name was changed from Last Affected Patch set (per Supported Release) to Supported Versions Affected. No other changes were made to the definition of this column or its values.
Vulnerabilities requiring additional notes use this column to refer to comments in a Notes section immediately below the risk matrix.