Risk Matrix Glossary – Terms and Definitions for Critical Patch Update Risk Matrices

Revised October 2020.


This page explains the information presented in Critical Patch Update Advisory risk matrices published since October 2016. Several changes to the format of these matrices have been made over the years, the most significant of these changes being the adoption of new versions of the Common Vulnerability Scoring System (CVSS) as follows:

  • CVSS version 3.1 - from July 2020
  • CVSS version 3.0 - from April 2016 to April 2020
  • CVSS version 2.0 - from October 2007 to April 2016
  • CVSS version 1.0 - from October 2006 to July 2007

Scope and Application

The column headings are listed below in the order they appear in the risk matrices. A summary of their purpose is also provided.

Starting with the October 2020 Critical Patch Update, Oracle will list in a separate section beneath each risk matrix, the vulnerabilities in third-party components which are non-exploitable in the context of the Oracle products in which they are included. See Announcements of Third-Party Component Updates for details.


The unique identifier for 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 use of CVE identifiers, Oracle used a proprietary identification where 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. As a result, the vulnerability identifiers were unique only within a single Critical Patch Update Advisory.


The Oracle product containing the vulnerability.


The product component containing the vulnerability. It typically identifies the subsystem or functionality with the issue, such as an administrative interface, web listener or cryptography service.

If the vulnerability is in a third-party component, or another Oracle product, that is included in this Oracle product its name is given in parentheses. For example, a component of “LDAP Gateway (Spring Framework)” indicates that the Oracle product’s LDAP Gateway component contains vulnerable code from the Spring Framework third party component.


The protocol used to communicate with the component that contains the vulnerability. It may be possible to reduce the risk of attack by limiting access to this protocol. For example, the risk posed by a vulnerability in a database component that communicates using the Oracle Net protocol could be reduced by preventing network connections using this protocol, or by limiting access to only trusted machines. Such restrictions are typically achieved using firewalls or managed switches.

Package and/or Privilege Required

Packages, privileges, roles, responsibilities or other preconditions required by an attack for it to potentially be successful. 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 whether the vulnerability may be exploited by a remote attacker who does not have authentication credentials for the targeted system. Vulnerabilities which may be exploitable from a remote network and without authentication are higher risk and are marked with a Yes. Vulnerabilities that 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:

  • For CVSS versions 3.0 and 3.1, Attack Vector is Network and Privileges Required is None and Base Score is > 0.0;
  • For CVSS version 2.0, Access Vector is Network and Authentication is None and Base Score is > 0.0;
  • For CVSS version 1.0, Attack Vector is Remote and Authentication is Not Required and Base Score is > 0.0;

CVSS Version 3.1 Risk

The CVSS Base Score, an assessment of risk defined by the Common Vulnerability Scoring Standard (CVSS). The CVSS Base Metrics is defined in CVSS v3.1 specification. 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 https://www.first.org/cvss.

The CVSS Base Score is a numeric value between 0.0 and 10.0 which indicates the relative 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.

Supported Versions Affected

This column lists the versions of the product that are affected by the vulnerability. Product versions that are no longer supported are not tested for the presence of the vulnerability and are excluded.

In the case of products that follow a patch set model, the column lists the last patch set in the release that is affected. Patch sets preceding the one listed should be assumed vulnerable.

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.


This column refers to comments in a Notes section immediately below the risk matrix when additional information is provided.