CVE-2021-35594

What it actually does

This is an improper input validation vulnerability in Oracle MySQL Cluster's general cluster component. A highly privileged attacker who can access the physical communication segment used by MySQL Cluster nodes may be able to submit or influence malformed cluster communications or inputs that are not safely validated. Exploitation is difficult, requires user interaction by another person, and can result in full compromise or takeover of the MySQL Cluster, affecting confidentiality, integrity, and availability.

Why it matters to the business

Successful exploitation can allow an attacker to take control of a MySQL Cluster, potentially exposing sensitive data, corrupting application data, or disrupting database-backed services. The risk is constrained by the need for high privileges, adjacent physical/network access to the cluster communication segment, and user interaction, but the impact is severe for organizations using MySQL Cluster for critical workloads. The issue is old and has had significant time to be incorporated into attacker tooling, and the EPSS score indicates non-trivial exploitation likelihood despite no CISA KEV listing or known ransomware association.

How an attack unfolds

An attacker first obtains a privileged position on or near the infrastructure segment where MySQL Cluster nodes communicate. They then identify exposed MySQL Cluster management or data-node communication paths and determine the cluster version. Because the flaw requires human interaction, the attacker must induce an administrator, operator, or other user to perform an action that causes vulnerable cluster code to process attacker-influenced input. If the malformed input reaches the vulnerable component, improper validation can allow the attacker to compromise the cluster process and ultimately take over the MySQL Cluster. From there, the attacker may access or alter database contents, manipulate cluster membership or configuration, stop nodes, or disrupt dependent applications.

How to fix it

Upgrade Oracle MySQL Cluster to a vendor-fixed, supported release newer than the affected branches: 7.4.33 and earlier, 7.5.23 and earlier, 7.6.19 and earlier, and 8.0.26 and earlier. Where Oracle packages are embedded in third-party products such as NetApp OnCommand Insight or NetApp SnapCenter, apply the relevant vendor advisory updates or supported product releases. If immediate patching is not possible, restrict MySQL Cluster communication to dedicated, trusted, segmented networks; limit administrative access; prevent untrusted users from interacting with cluster management workflows; monitor for unexpected cluster configuration or membership changes; and ensure backups and recovery procedures are tested.

How to confirm the fix worked

Confirm that all MySQL Cluster components, including management nodes, data nodes, SQL nodes, and bundled deployments, are running fixed versions later than the affected versions. Validate using vendor-supported version commands, package inventory, and configuration management records. Review network segmentation to ensure only authorized cluster nodes and administrators can reach cluster communication interfaces. For third-party appliances or products that include MySQL Cluster components, verify the vendor-provided fixed release is installed rather than relying only on operating-system package checks. After patching, perform a controlled restart or rolling upgrade validation according to MySQL Cluster procedures and confirm cluster health, node membership, and application connectivity.

Typical attack path

1. Gain high-privilege access to systems or network infrastructure connected to the MySQL Cluster physical communication segment.
2. Identify MySQL Cluster nodes, management services, and versions in use.
3. Position attacker-controlled traffic or input where cluster components or administrators will interact with it.
4. Induce required user interaction by an administrator or operator.
5. Trigger the improper input validation condition in the vulnerable MySQL Cluster component.
6. Take control of cluster functionality or affected processes.
7. Access, modify, or disrupt clustered database data and services.

How to detect it

There are no widely published, unique indicators of compromise for this vulnerability. Detection should focus on evidence of suspicious activity around MySQL Cluster management and node communications. Review MySQL Cluster management node logs, data node logs, SQL node logs, operating system authentication logs, network flow records for cluster communication segments, administrative shell history, and change-management records. Look for unexpected cluster node joins or removals, unexplained restarts or crashes of ndb_mgmd, ndbd, ndbmtd, or mysqld processes, unusual use of MySQL Cluster management tools, administrative actions outside maintenance windows, new privileged accounts, altered cluster configuration files, and traffic to cluster ports from systems that are not authorized cluster members or administrators. Correlate any anomalous user interaction or administrative session with subsequent cluster instability, configuration changes, or data access anomalies.

What your security team should do

• Prioritize inventory of Oracle MySQL Cluster deployments and products that embed it, including NetApp OnCommand Insight and NetApp SnapCenter.
• Upgrade affected MySQL Cluster versions beyond 7.4.33, 7.5.23, 7.6.19, and 8.0.26, or apply the applicable third-party vendor fixes.
• Treat internet exposure as a misconfiguration; MySQL Cluster communication should be isolated to trusted internal segments only.
• Restrict cluster administration to named, audited privileged users and require strong authentication for management access.
• Review recent cluster logs for unexplained administrative activity, node restarts, membership changes, configuration changes, or crashes.
• Harden the physical and logical network segment used by MySQL Cluster nodes, including firewalling, VLAN isolation, and access control enforcement.
• Ensure recent, tested backups exist for all databases hosted on affected clusters.
• Because the vulnerability is long-published and has a relatively elevated EPSS score, do not defer remediation solely because it is not listed in CISA KEV.