CVE-2021-35593

What it actually does

This is a memory-corruption vulnerability in Oracle MySQL Cluster, specifically the Cluster general component. An attacker who already has high privileges and access to the adjacent physical communication segment used by the MySQL Cluster can, under high-complexity conditions and with required interaction from another user, trigger unsafe memory handling that may allow compromise of the cluster. Successful exploitation can affect confidentiality, integrity, and availability, up to full takeover of the MySQL Cluster environment.

Why it matters to the business

A successful attack could allow an already well-positioned attacker to take control of a MySQL Cluster, potentially exposing sensitive data, altering business records, or disrupting database-backed services. The attack is not trivial because it requires high privileges, adjacent network access, and user interaction, but the impact is severe for organizations that rely on MySQL Cluster for critical applications. The EPSS score indicates meaningful exploitation likelihood despite no CISA KEV listing, so internet-adjacent, shared-network, or poorly segmented cluster deployments should be treated with elevated priority.

How an attack unfolds

An attacker first gains high-privileged access to a system or network location on the same physical communication segment used by MySQL Cluster nodes. The attacker then positions themselves to interact with cluster communication paths or cluster-facing services. Because the vulnerability requires user interaction, the attacker must induce or wait for a legitimate user or administrator action that causes vulnerable cluster functionality to process attacker-influenced data or state. If the memory-corruption condition is reached successfully, the attacker may corrupt process memory in a way that enables control over MySQL Cluster behavior. In the worst case, this can result in takeover of cluster services, unauthorized access to data, modification of data, or service disruption. There is no public indication in the provided data that this vulnerability is in CISA KEV or associated with ransomware campaigns, but the combination of high impact and moderate EPSS warrants proactive remediation.

How to fix it

Upgrade Oracle MySQL Cluster to a vendor-supported fixed release newer than the affected branches: later than 7.4.33, 7.5.23, 7.6.19, and 8.0.26, as applicable. Apply the relevant Oracle Critical Patch Update that addresses this vulnerability. For NetApp OnCommand Insight and NetApp SnapCenter deployments, review the applicable NetApp advisories and upgrade to vendor-provided fixed versions or maintenance releases that address the bundled or dependent MySQL Cluster exposure. Where immediate patching is not possible, restrict access to MySQL Cluster communication networks, ensure cluster interconnects are isolated from general-purpose networks, limit administrative access to trusted hosts only, enforce least privilege, monitor cluster management activity, and reduce opportunities for untrusted users to influence cluster operations.

How to confirm the fix worked

Confirm all MySQL Cluster components, including management nodes, data nodes, SQL nodes, and any bundled third-party deployments, are running versions newer than the affected releases. Use vendor version commands, package inventory, and software composition scans to verify that MySQL Cluster is not at 7.4.33 or earlier, 7.5.23 or earlier, 7.6.19 or earlier, or 8.0.26 or earlier. Validate that cluster communication interfaces are restricted to trusted network segments and are not reachable from untrusted adjacent networks. Review configuration baselines, firewall rules, host access controls, and segmentation controls. After upgrade, perform a controlled service restart or failover test where appropriate, confirm cluster health, and review logs for recurring crashes, abnormal restarts, or unexpected cluster state changes.

Typical attack path

1. Gain high-privileged access to a host or network location connected to the MySQL Cluster physical communication segment.
2. Identify vulnerable MySQL Cluster nodes running affected versions: 7.4.33 or earlier, 7.5.23 or earlier, 7.6.19 or earlier, or 8.0.26 or earlier.
3. Interact with cluster communication paths or cluster services from the adjacent network segment.
4. Trigger or wait for required legitimate user interaction that causes vulnerable cluster functionality to process attacker-influenced input or state.
5. Exploit the memory-corruption condition to compromise MySQL Cluster processes.
6. Use the compromised cluster position to access data, modify data, disrupt cluster availability, or establish further persistence.

How to detect it

To determine whether exploitation may have already occurred, review MySQL Cluster management node logs, data node logs, SQL node logs, operating system syslog or event logs, database audit logs, endpoint telemetry, and network flow records for the cluster communication segment. Focus on the period before patching and look for unexplained MySQL Cluster process crashes, segmentation faults, abnormal restarts, node disconnects or rejoins, unexpected management commands, unauthorized configuration changes, and traffic to cluster communication interfaces from hosts that are not part of the approved cluster topology. Correlate these events with privileged account activity and any user or administrator actions that occurred immediately before instability or state changes, because exploitation requires high privileges and user interaction. Investigate any evidence of data export, unauthorized schema or privilege changes, tampering with cluster configuration, or creation of unexpected administrative accounts after suspicious cluster events. There are no widely established public exploit-specific indicators in the provided data, so detection should emphasize behavioral anomalies and forensic review rather than signature-only matching.

What your security team should do

• Inventory all Oracle MySQL Cluster deployments and products that may bundle or depend on MySQL Cluster, including NetApp OnCommand Insight and NetApp SnapCenter.
• Prioritize patching for production clusters, shared-network deployments, and clusters supporting critical applications or sensitive data.
• Upgrade affected MySQL Cluster versions to vendor-fixed releases newer than 7.4.33, 7.5.23, 7.6.19, or 8.0.26 as applicable.
• Isolate MySQL Cluster inter-node and management communication on dedicated trusted network segments.
• Restrict administrative and cluster management access to approved hosts and accounts with least privilege.
• Review MySQL Cluster management logs, node logs, operating system logs, and network telemetry for signs of crashes, abnormal restarts, unauthorized management activity, or suspicious adjacent-network access.
• Add compensating monitoring for unexpected MySQL Cluster process restarts, node membership changes, configuration changes, and traffic from non-cluster hosts to cluster communication ports.
• Track Oracle and NetApp security advisories for exact fixed versions and apply any product-specific maintenance releases.