CVE-2021-35590

What it actually does

CVE-2021-35590 is a memory-corruption vulnerability in Oracle MySQL Cluster, in the Cluster: General component. A highly privileged attacker with access to the same physical communication segment as the MySQL Cluster deployment can trigger the flaw under conditions that require user interaction by another person. Successful exploitation can compromise the cluster and may affect confidentiality, integrity, and availability, potentially allowing takeover of MySQL Cluster services or nodes. Affected Oracle MySQL Cluster versions are 7.4.33 and earlier, 7.5.23 and earlier, 7.6.19 and earlier, and 8.0.26 and earlier; downstream products including NetApp OnCommand Insight and NetApp SnapCenter may also be affected when they embed or depend on vulnerable MySQL Cluster components.

Why it matters to the business

If exploited, this vulnerability can allow an attacker already positioned on the relevant cluster network segment and holding significant privileges to take over a MySQL Cluster environment. That can lead to data exposure, unauthorized data modification, cluster outage, application downtime, and loss of trust in database integrity. Although exploitation is difficult and requires both privileged access and user interaction, the EPSS score is high, indicating elevated likelihood of exploitation activity relative to many vulnerabilities; organizations still running affected legacy MySQL Cluster versions should treat remediation as urgent, especially where cluster networks are reachable by administrators, shared infrastructure, or downstream products such as NetApp OnCommand Insight or SnapCenter.

How an attack unfolds

An attacker first gains high-privileged access to systems or network paths on the physical communication segment used by MySQL Cluster nodes. The attacker then identifies vulnerable MySQL Cluster management, SQL, or data-node services and waits for or induces the required human interaction, such as an administrator performing a cluster-related action that causes the vulnerable component to process attacker-influenced data or traffic. The attacker sends crafted input to the Cluster: General component, triggering memory corruption in the affected MySQL Cluster process. If exploitation succeeds, the attacker can compromise the MySQL Cluster environment, potentially controlling cluster behavior, accessing or altering data, disrupting node operations, or using the compromised cluster as a foothold for further activity.

How to fix it

Upgrade Oracle MySQL Cluster to a vendor-supported version newer than the affected release lines: later than 7.4.33, later than 7.5.23, later than 7.6.19, and later than 8.0.26, or preferably to the latest supported Oracle MySQL Cluster release containing the October 2021 Critical Patch Update fixes or later. If using NetApp OnCommand Insight or NetApp SnapCenter, apply the applicable NetApp-supplied updates or mitigations because embedded or bundled components may need vendor-specific patches. Where immediate upgrade is not possible, restrict MySQL Cluster management, data-node, and inter-node communication to dedicated trusted networks; block untrusted access to cluster ports at firewalls and switch ACLs; enforce administrative MFA and least privilege; limit who can perform cluster-management actions; monitor and control interactive administrative workflows; and consider isolating or temporarily disabling vulnerable cluster functions until patched.

How to confirm the fix worked

Confirm installed versions using MySQL Cluster administrative tooling and package inventories, and verify that no cluster nodes remain on Oracle MySQL Cluster 7.4.33 or earlier, 7.5.23 or earlier, 7.6.19 or earlier, or 8.0.26 or earlier. Validate downstream vendor products separately, including NetApp OnCommand Insight and NetApp SnapCenter, because their remediation state may not match the standalone MySQL Cluster package version. Review vendor patch notes or build manifests to confirm the Oracle CPU fix is present. Perform network validation to ensure cluster management and inter-node ports are reachable only from approved cluster nodes and administrative systems. After patching, restart or rolling-upgrade cluster components according to vendor guidance, verify all nodes rejoin cleanly, and confirm normal replication, failover, and application connectivity.

Typical attack path

1. Gain high-privileged access to infrastructure connected to the MySQL Cluster physical communication segment.
2. Perform reconnaissance to identify MySQL Cluster nodes, management services, data nodes, SQL nodes, versions, and exposed cluster ports.
3. Confirm that the deployment is running Oracle MySQL Cluster 7.4.33 or earlier, 7.5.23 or earlier, 7.6.19 or earlier, or 8.0.26 or earlier, or a downstream product containing an affected component.
4. Wait for, social-engineer, or otherwise induce the user interaction required to reach the vulnerable code path.
5. Send crafted cluster-related traffic or data to the vulnerable Cluster: General component.
6. Trigger memory corruption and obtain control over the affected MySQL Cluster process or cluster function.
7. Use the compromised cluster access to read, alter, or disrupt data and services, or to pivot further within the environment.

How to detect it

To determine whether this vulnerability may have been exploited, review MySQL Cluster management-node logs, data-node logs, SQL-node MySQL error logs, operating system syslog or journal logs, authentication logs, EDR telemetry, and network flow records for the cluster communication segment. Look for unusual or unauthorized connections to cluster management and inter-node services, especially from systems that are not expected cluster nodes or administrative hosts. Investigate unexpected ndb_mgmd, ndbd, ndbmtd, or mysqld crashes; segmentation faults; abnormal restarts; sudden node failovers; unexplained cluster reconfiguration; unauthorized administrative commands; new or modified database users; altered grants; suspicious data export activity; and cluster activity occurring immediately after interactive administrative sessions. Because no public, stable exploit indicators are provided in the advisory, detection should focus on behavioral evidence of memory-corruption attempts and post-compromise cluster control rather than a fixed exploit string. Correlate any anomalies with the human-interaction requirement by reviewing administrative logins, remote sessions, configuration changes, file transfers, and ticketed maintenance around the same time.

What your security team should do

• Prioritize patching or upgrading affected MySQL Cluster deployments despite the absence of CISA KEV listing, because the EPSS score is high and the vulnerability has full confidentiality, integrity, and availability impact if exploited.
• Inventory all Oracle MySQL Cluster deployments and downstream products that may include vulnerable components, especially NetApp OnCommand Insight and NetApp SnapCenter.
• Restrict access to MySQL Cluster management and inter-node communication networks to explicitly approved systems only; remove shared or broadly reachable network exposure.
• Review administrative privileges for database, cluster, operating system, and network access; remove unnecessary high-privileged access and require MFA for administrative workflows.
• Hunt for signs of suspicious cluster activity, including unexpected node restarts, crashes, configuration changes, administrative actions, and connections from non-cluster systems on the cluster communication segment.
• Ensure MySQL Cluster logs, operating system logs, authentication logs, and network telemetry for cluster segments are retained long enough to support retrospective investigation.
• If patching is delayed, document compensating controls, increase monitoring on cluster ports and administrative sessions, and schedule a maintenance window for remediation.