Vulnerability in the Core RDBMS component of Oracle Database Server. Supported versions that are affected are 12.1.0.2, 12.2.0.1, 18c and 19c. Easily exploitable vulnerability allows low privileged at

Successful exploitation of CVE-2020-2731 allows an attacker with local logon privileges to gain unauthorized access to Core RDBMS data. This could manifest as unauthorized updates, insertions, or deletions of data within the database. The vulnerability also presents a risk of partial denial of service, potentially disrupting critical database operations. The ease of exploitation, combined with the potential for data compromise, makes this a concerning vulnerability, particularly in environments with sensitive data.

Organizations running Oracle Database Server versions 12.1.0.2, 12.2.0.1, 18c, and 19c are at risk, particularly those with lax local logon controls or environments where local accounts have excessive privileges. Shared hosting environments utilizing these versions are also at increased risk due to the potential for cross-tenant exploitation.

• linux / server:

journalctl -u oracle-db | grep -i "error" -i "exception"

• oracle:

SELECT * FROM v$version WHERE version LIKE '12.1.0.2%' OR version LIKE '12.2.0.1%' OR version LIKE '18c%' OR version LIKE '19c%';

• generic web: Review Oracle database server access logs for unusual login attempts or database modification activity originating from local hosts.

1. 2020-01-15Disclosure

   disclosure

2. 2020-01-15Patch

   patch

1. Réservé2019-12-10
2. Publiée2020-01-15
3. Modifiée2024-09-30
4. EPSS mis à jour2026-04-02

The primary mitigation for CVE-2020-2731 is to upgrade to Oracle Database Server version 19.0.1 or later. If an immediate upgrade is not feasible, consider restricting local logon privileges to the minimum necessary for users. Implementing robust access controls and monitoring database activity can help detect and prevent unauthorized access. While a direct workaround isn't available, regular security audits and patching are crucial for maintaining a secure database environment. After upgrading, verify the fix by attempting to reproduce the vulnerability with the original exploit steps and confirming that access is denied.