Unauthenticated HTTP compromise in Oracle Database Server Clusterware

Vulnerability in the Portable Clusterware component of Oracle Database Server. Supported versions that are affected are 19.3-19.32, 21.3-21.23 and 23.4.0-23.26.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Portable Clusterware. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Portable Clusterware accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Portable Clusterware. CVSS 3.1 Base Score 9.1 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H).

The affected scope identified by Oracle and the CNA record is:

• Oracle Database Server, Portable Clusterware: 19.3 through 19.32, inclusive.
• Oracle Database Server, Portable Clusterware: 21.3 through 21.23, inclusive.
• Oracle Database Server, Portable Clusterware: 23.4.0 through 23.26.3, inclusive.

Oracle currently uses the name Clusterware in the risk matrix, while the record describes the component as Portable Clusterware. Oracle states that the patches in this program do not apply to client-only installations, meaning installations without Oracle Database Server. The supplied record and advisory do not provide an exact fixed release for each branch, so later releases must not be assumed safe solely because they fall beyond the listed boundaries.

The vulnerability affects the Portable Clusterware component of Oracle Database Server, which Oracle labels Clusterware in its current advisory. An attacker can reach the component over HTTP from the network; authentication, prior privileges, and user interaction are not required. Oracle characterizes exploitation as easy and the scope as unchanged. The available evidence does not disclose the vulnerable input type, endpoint, request format, parser, or code path. Oracle also states that an HTTP entry in its risk matrix implies that corresponding secure variants such as HTTPS are affected, so Clusterware services exposed through HTTPS should be reviewed as well.

• Reachability: Remote exploitation through the network-facing HTTP interface of Portable Clusterware.
• Preconditions: No authentication, privileges, or user interaction are required; the supplied assessment describes low attack complexity.
• Exposure to review: Deployments that provide the relevant service over HTTP or HTTPS should be checked, including services reachable only from internal networks.
• Public exploitation status: The supplied record does not identify a public exploit and does not confirm exploitation in the wild. That does not establish that exploitation is absent.

Successful exploitation may let an unauthenticated attacker create, delete, or modify critical data or all data accessible to Portable Clusterware. It may also cause Portable Clusterware to hang or crash repeatedly, producing complete denial of service for the component. Because no privileges or user interaction are required, the issue can affect systems where the relevant network service is exposed beyond the intended administrative boundary. The record does not establish an impact on confidentiality or access to other products, so claims about unauthorized reading or broader cross-component compromise remain unconfirmed.

The vulnerability directly threatens the integrity of data handled by Portable Clusterware and the availability of the component.

• An attacker may alter or delete critical data accessible to Clusterware, potentially causing incorrect operational state or requiring data recovery.
• Repeated hangs or crashes may interrupt services that depend on Clusterware and increase recovery time.
• The supplied assessment does not identify a confidentiality impact, so it should not be expanded into a claim of unauthorized data disclosure.
• Actual consequences depend on the data accessible to Portable Clusterware in each deployment and on how broadly the service is exposed to the network.

1. Apply the Oracle patch: Install the Oracle Critical Security Patch Update applicable to Oracle Database Server and the affected Clusterware component, using the patch availability documentation for the deployed branch. The available evidence does not state an exact fixed release, so confirm the correct package and patch for each branch before deployment.
2. Prioritize network-exposed systems: Remediate hosts that permit HTTP or HTTPS access to the Clusterware service from untrusted networks or broad network segments first.
3. Reduce exposure temporarily: If immediate patching is not possible, block the network protocols required for the attack or restrict access to the sources that genuinely require it. Oracle warns that these changes may disrupt functionality and should be tested on non-production systems.
4. Do not treat exposure reduction as a fix: Blocking HTTP or HTTPS is temporary mitigation and does not correct the underlying vulnerability.
5. Verify the result: Check the installed version, patch state, and service exposure for every affected branch. Do not infer a fixed release merely from the advisory's affected ranges.

1. Inventory Oracle Database Server installations and determine whether Portable Clusterware or Clusterware is installed.
2. Compare deployed versions with the affected branches in affected_summary rather than relying only on the product name.
3. Identify listeners, reverse proxies, and firewall rules that permit HTTP or HTTPS access to the Clusterware service. Oracle does not disclose a specific endpoint, so the review must follow the deployment architecture.
4. Review audit and operational data for unauthorized creation, deletion, or modification of data managed by Clusterware, as well as repeated hangs or crashes. These are precautionary review targets, not Oracle-confirmed indicators of compromise.
5. Do not treat the absence of suspicious logs or events as proof of safety; the available evidence does not provide a request signature, IOC, or log signature.