Galera Cluster-peer > Donor command execution

The wsrep_sst_auth global variable is vulnerable to command injection on the donor node during State Snapshot Transfer (SST) operations. While recent patches (MDEV-39413, MDEV-39676) successfully mitigated the remote (Joiner -> Donor) vector, an attacker with SUPER or SYSTEM_VARIABLES_ADMIN privileges can still leverage this vulnerability to escape the database environment and achieve arbitrary OS Command Execution on the underlying host system. This occurs because WSREP_SST_OPT_USER is passed unsanitized into an eval statement in scripts/wsrep_sst_mariabackup.sh, bypassing the newly introduced safe() filtering.

Description
When configuring a Galera Cluster donor node for SST, the authentication details are read from the global variable wsrep_sst_auth. In sql/wsrep_sst.cc (wsrep_sst_donate), the donor reads its local sst_auth_real and sets the auth.name_ to the provided username. This value is subsequently written into the SST payload sent to the bash scripts as sst_user.

if (sst_auth_real)

  {

    /* User supplied non-trivial wsrep_sst_auth, use it */

    const char* col= sst_strchrnul(sst_auth_real, ':');

    auth.name_ = std::string(sst_auth_real, col - sst_auth_real);

    // ...

The script wsrep_sst_common.sh processes the incoming sst_user string and assigns it to WSREP_SST_OPT_USER. The vulnerability lies in scripts/wsrep_sst_mariabackup.sh. While MDEV-39413 successfully patched variables like WSREP_SST_OPT_REMOTE_USER by wrapping them in the safe() function, it omitted WSREP_SST_OPT_USER.
At line 1129, WSREP_SST_OPT_USER is concatenated into INNOEXTRA directly:

if [ -n "$WSREP_SST_OPT_USER" ]; then

        INNOEXTRA="$INNOEXTRA --user='$WSREP_SST_OPT_USER'"

        # ...

And later, INNOEXTRA  is evaluated via eval:

eval $INNOBACKUPEX_BIN $mb_args $INNOEXTRA $sfmt $tfmt $LIMIT $COMPRESS ...

By setting a crafted payload in  wsrep_sst_auth , an authenticated database administrator can inject shell commands and escape --secure-file-priv and UDF restrictions.

Steps to Reproduce

Setup a standard MariaDB Galera cluster withwsrep_sst_method=mariabackup.
Connect to thedonor nodeas a user with SUPER privileges (e.g.,root).
Set the global variable to a malicious payload:

SET GLOBAL wsrep_sst_auth="'; touch /tmp/RCE_PROOF_LPE; echo 'RCE LPE SUCCESS' > /tmp/RCE_PROOF_LPE #";

Trigger an SST operation (for example, by having another node join the cluster). The command will execute with the privileges of the mysqluser. Check/tmp/RCE_PROOF_LPE:

cat /tmp/RCE_PROOF_LPE

# Outputs: RCE LPE SUCCESS

Recommended Fix

In scripts/wsrep_sst_mariabackup.sh line 1129, apply the safe() function to WSREP_SST_OPT_USER (and similarly for WSREP_SST_OPT_PSWD if applicable) to prevent shell interpolation.

-        INNOEXTRA="$INNOEXTRA --user='$WSREP_SST_OPT_USER'"

+        WSREP_SST_OPT_USER_=$(safe WSREP_SST_OPT_USER)

+        INNOEXTRA="$INNOEXTRA --user='$WSREP_SST_OPT_USER_'"

Impact
This vulnerability allows Authenticated Privilege Escalation. A user with database administrative privileges (SUPER or SYSTEM_VARIABLES_ADMIN) can execute arbitrary operating system commands. In hardened environments where direct shell access is restricted, system functions are disabled, and --secure-file-priv is enforced, this vector allows a trivial escape to OS-level compromise of the database host.

Reported by letchu_pkt