CVE-2026-48163

What it actually does

This is a command injection vulnerability in MariaDB Galera State Snapshot Transfer (SST) when the rsync SST method is used. During SST, a donor node processes parameters supplied by a joining node and interpolates some of them into a command line without sufficient validation. A malicious or compromised joiner with the ability to participate in SST can craft parameters that cause arbitrary shell commands to execute on the donor node. Successful exploitation can compromise the operating-system context under which MariaDB/SST scripts run, potentially leading to full confidentiality, integrity, and availability impact on the donor host and lateral movement within the database cluster environment. The CVSS vector indicates network reachability, high attack complexity, high privileges required, no user interaction, and scope change with high impact across confidentiality, integrity, and availability.

Why it matters to the business

A successful attack could allow a rogue or compromised MariaDB cluster participant to run commands on another database server during synchronization, potentially exposing sensitive data, modifying database infrastructure, disrupting replication, or using the database host as a foothold for broader compromise. The risk is highest for organizations using MariaDB Galera clustering with rsync-based SST, especially where cluster membership or database administrative access is not tightly controlled. Although this is not listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, the potential impact is severe because compromise of a database donor node can affect critical data services and operational availability.

How an attack unfolds

An attacker first needs high-privilege access sufficient to introduce or control a MariaDB Galera joiner node, or to compromise an existing node that can request SST. The attacker configures the joiner to request rsync-based SST and supplies specially crafted SST parameters. When the donor node accepts the SST request, vulnerable MariaDB versions interpolate insufficiently validated joiner-controlled values into shell commands used by the rsync SST process. The injected shell metacharacters or command fragments execute on the donor side. The attacker can then run arbitrary commands in the SST/MariaDB execution context, such as dropping a web shell or backdoor, reading local files, altering database-related files, collecting credentials, modifying service configuration, or disrupting the donor node. Because exploitation depends on SST activity and attacker control over a joiner, attacks may appear as abnormal node join/rejoin or synchronization events rather than conventional SQL exploitation.

How to fix it

Upgrade affected MariaDB Server deployments to a fixed release: 10.6.27 or later for the 10.6 series, 10.11.18 or later for the 10.11 series, 11.4.12 or later for the 11.4 series, 11.8.8 or later for the 11.8 series, and 12.3.2 or later for the 12.3 series. Prioritize Galera cluster nodes that use or allow rsync SST. If immediate upgrade is not possible, restrict cluster membership to trusted hosts only, tightly control credentials and certificates used for Galera/SST operations, block untrusted network access to Galera and SST-related ports, disable or avoid rsync SST where operationally feasible, and use a safer SST method supported by the deployment. Review wsrep and SST configuration for unnecessary exposure, and ensure MariaDB/SST processes run with least privilege under a dedicated service account rather than elevated system privileges.

How to confirm the fix worked

Confirm the installed MariaDB version on every cluster node is at or above the fixed version for its release branch. Validate that no node remains on MariaDB 10.6.1-10.6.26, 10.11.1-10.11.17, 11.4.1-11.4.11, 11.8.1-11.8.7, or 12.3.1. Review MariaDB configuration for wsrep/Galera usage and determine whether wsrep_sst_method=rsync is configured or allowed. Confirm that cluster membership controls, firewall rules, and authentication mechanisms prevent unauthorized joiners from initiating SST. In a non-production test environment, perform a controlled node join/SST after upgrade and verify logs show normal SST operation without command parsing errors or unexpected shell activity. Use package manager queries, MariaDB version output, and configuration management inventory to validate coverage across all database nodes.

Typical attack path

1. Obtain administrative or equivalent access that allows control of a MariaDB Galera joiner node or the ability to initiate SST against a donor.
2. Ensure the cluster uses the rsync SST method and identify a vulnerable donor running MariaDB 10.6.1-10.6.26, 10.11.1-10.11.17, 11.4.1-11.4.11, 11.8.1-11.8.7, or 12.3.1.
3. Configure the malicious joiner to send crafted SST parameters containing shell command injection payloads.
4. Trigger a State Snapshot Transfer from the donor to the malicious joiner.
5. Wait for the donor's SST scripts to build command lines using the malicious parameters.
6. Execute arbitrary shell commands on the donor host in the MariaDB/SST process context.
7. Use the gained execution to collect secrets, alter database or system files, deploy persistence, disrupt services, or pivot further.

How to detect it

Investigate whether any Galera SST activity occurred on vulnerable versions, especially rsync SST events involving unexpected joiner hosts, repeated failed joins, or joins initiated outside maintenance windows. Review MariaDB error logs, Galera/wsrep logs, system logs, auditd records, process execution telemetry, EDR events, and shell history for commands spawned from SST-related scripts or the MariaDB service account. Focus on parent-child process relationships where mysqld, wsrep_sst_rsync, wsrep_sst_common, rsync, socat, bash, sh, or timeout start unexpected utilities such as curl, wget, nc, ncat, bash, sh, python, perl, chmod, chattr, useradd, crontab, systemctl, or reverse-shell tools. Check for abnormal files created or modified by the MariaDB service account in temporary directories, MariaDB data directories, systemd locations, cron locations, SSH authorized_keys files, and web-accessible directories. Correlate suspicious process execution with MariaDB log entries showing SST donor activity, joiner negotiation, rsync transfer startup, or node state changes. Because no specific public exploit indicators are provided, detection should emphasize behavioral signs of command injection during SST rather than a single payload string.

• wsrep_sst_method=rsync
• WSREP_SST: [INFO] Streaming with rsync
• WSREP_SST: [INFO] rsync SST started
• WSREP_SST: [INFO] Joiner cleanup
• WSREP_SST: [INFO] Donor cleanup
• WSREP: Member joined the cluster
• WSREP: Shifting DONOR/DESYNCED
• WSREP: State transfer required
• wsrep_sst_rsync
• wsrep_sst_common
• mysqld -> sh
• mysqld -> bash
• wsrep_sst_rsync -> sh
• wsrep_sst_rsync -> bash
• rsync -> sh
• rsync -> bash
• /usr/bin/wsrep_sst_rsync
• /usr/bin/wsrep_sst_common
• /usr/bin/rsync
• /var/lib/mysql/.ssh/authorized_keys
• /var/lib/mysql/.bash_history
• /tmp/.X11-unix
• /tmp/.ICE-unix
• /tmp/.mariadb
• /etc/cron.d/
• /etc/systemd/system/
• curl http
• wget http
• nc -e
• ncat -e
• bash -i >& /dev/tcp/
• sh -i >& /dev/tcp/

What your security team should do

• Inventory all MariaDB Galera clusters and identify nodes using rsync-based SST.
• Upgrade affected MariaDB branches to 10.6.27, 10.11.18, 11.4.12, 11.8.8, 12.3.2, or newer as applicable.
• Restrict Galera replication and SST network access to explicitly trusted cluster nodes only.
• Audit cluster administration paths to ensure only authorized administrators can add or reconfigure joiner nodes.
• Review recent SST, node join, and node rejoin events for suspicious parameters or unexpected donor-side process execution.
• Harden MariaDB service accounts and SST scripts with least privilege and file-system access controls.
• Add monitoring for unexpected shell, scripting, or network utility processes spawned by MariaDB, SST, rsync, or wsrep-related processes.
• If upgrade must be delayed, consider disabling rsync SST or switching to a safer supported SST method after operational testing.