CVE-2020-15180: MariaDB Galera Cluster RCE Vulnerability

CVE-2020-15180 Overview

CVE-2020-15180 is a command injection vulnerability in the mysql-wsrep component of MariaDB. The flaw stems from missing input sanitization on the wsrep_sst_method variable used during State Snapshot Transfer (SST) operations in Galera cluster deployments. A remote attacker can inject arbitrary shell commands that execute on cluster nodes, breaking confidentiality, integrity, and availability. The defect affects MariaDB versions prior to 10.1.47, 10.2.34, 10.3.25, 10.4.15, and 10.5.6, as well as Percona XtraDB Cluster and Galera Cluster for MySQL deployments that share the affected wsrep provider logic.

Critical Impact

Successful exploitation allows arbitrary command execution on Galera cluster nodes with the privileges of the MariaDB service account, enabling full database takeover and lateral movement.

Affected Products

• MariaDB versions before 10.1.47, 10.2.34, 10.3.25, 10.4.15, and 10.5.6
• Percona XtraDB Cluster (versions prior to fixed releases referenced in the Percona advisory)
• Galera Cluster for MySQL
• Debian Linux 9 and Debian Linux 10

Discovery Timeline

• 2021-05-27 - CVE-2020-15180 published to the National Vulnerability Database (NVD)
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-15180

Vulnerability Analysis

The vulnerability resides in how the mysql-wsrep component handles the wsrep_sst_method configuration variable. This variable selects the backend used for State Snapshot Transfer between Galera cluster nodes, such as rsync, mariabackup, or mysqldump. The codepath constructs shell command strings that incorporate the supplied method name without escaping or validating it.

Because the variable value flows into a shell context, an attacker who can influence its content can append arbitrary commands using standard shell metacharacters. The issue is classified as Improper Input Validation [CWE-20] and Command Injection [CWE-77]. Exploitation yields code execution under the user account running the MariaDB server, typically mysql, on every cluster node that processes the malicious SST request.

Root Cause

The root cause is the absence of sanitization or whitelisting when the wsrep_sst_method value is concatenated into the shell invocation that launches the SST helper script. The code trusts the variable contents and passes them through a shell interpreter rather than executing the binary directly with a fixed argument list. Any shell metacharacter — semicolons, backticks, pipes, or $() constructs — is interpreted as part of the command line.

Attack Vector

The attack is network-based but conditioned on the attacker being able to set or influence the wsrep_sst_method value. This may occur through SQL SET GLOBAL statements when an attacker obtains sufficient privileges, through configuration injection on management interfaces, or through compromise of an upstream component that propagates wsrep settings. Once the malicious value is in place, the next SST event triggers shell execution of the injected payload on the donor or joiner node.

No verified public proof-of-concept code is referenced in the available data. See the Percona Blog on CVE-2020-15180 and the Red Hat Bug Report for additional technical context.

Detection Methods for CVE-2020-15180

Indicators of Compromise

• Unexpected child processes spawned by the mysqld or mariadbd process, particularly shells (/bin/sh, /bin/bash) executing non-SST binaries.
• Modifications to wsrep_sst_method containing shell metacharacters such as ;, |, `, or $( in audit logs or configuration files.
• Outbound network connections initiated by the MariaDB service account to attacker-controlled hosts following an SST event.
• New or modified files in the MariaDB data directory or in the home directory of the mysql user immediately after a cluster join.

Detection Strategies

• Audit MariaDB general query logs and configuration change events for SET GLOBAL wsrep_sst_method or SET SESSION wsrep_sst_method statements with non-standard values.
• Monitor process trees for mysqld parenting unexpected commands; legitimate SST should invoke only the configured helper script (for example wsrep_sst_rsync or wsrep_sst_mariabackup).
• Apply file integrity monitoring to /etc/mysql/, /etc/my.cnf, and /etc/my.cnf.d/ to flag unauthorized changes to wsrep parameters.

Monitoring Recommendations

• Forward MariaDB error logs, audit plugin output, and host process telemetry into a centralized SIEM for correlation across cluster nodes.
• Alert on any execution of wsrep_sst_* scripts outside scheduled cluster maintenance windows.
• Track network egress from database hosts and flag connections that do not match expected replication peers.

How to Mitigate CVE-2020-15180

Immediate Actions Required

• Upgrade MariaDB to 10.1.47, 10.2.34, 10.3.25, 10.4.15, 10.5.6, or later as appropriate to the installed branch.
• Apply the corresponding Percona XtraDB Cluster and Galera Cluster updates referenced in the vendor advisories.
• Rotate credentials for any account capable of issuing SET GLOBAL on cluster nodes and review recent privileged SQL activity.
• Inspect cluster hosts for signs of post-exploitation activity, including unexpected cron jobs, SSH keys, or persistence mechanisms under the mysql user.

Patch Information

Fixes are available from upstream vendors and downstream distributions. Consult the Debian Security Advisory DSA-4776, the Debian LTS Announcement, and the Gentoo GLSA 202011-14 for distribution-specific package versions. Percona deployments should follow guidance in the Percona advisory.

Workarounds

• Restrict the SUPER and SYSTEM_VARIABLES_ADMIN privileges so only trusted administrators can modify wsrep_sst_method at runtime.
• Place cluster replication traffic on a dedicated, segmented network reachable only from peer nodes and management hosts.
• Enforce configuration management (Ansible, Puppet, Chef) to keep wsrep parameters pinned to known-good values and revert drift automatically.
• Enable the MariaDB audit plugin to capture all changes to global variables for forensic review until patches are applied.

# Verify the installed MariaDB version and current SST method
mysql -u root -p -e "SELECT VERSION(); SHOW VARIABLES LIKE 'wsrep_sst_method';"

# Restrict privilege grants that allow runtime changes to wsrep variables
# Run as an administrative account after review
REVOKE SUPER ON *.* FROM 'app_user'@'%';
REVOKE SYSTEM_VARIABLES_ADMIN ON *.* FROM 'app_user'@'%';

# Pin wsrep_sst_method in my.cnf and disallow runtime overrides via config management
# /etc/mysql/conf.d/wsrep.cnf
# [mysqld]
# wsrep_sst_method=mariabackup