CVE-2026-44168

What it actually does

This vulnerability is a command injection flaw in MariaDB Galera Cluster state snapshot transfer using the mariabackup SST method. During SST, a donor node accepts 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 the cluster can cause the donor to execute arbitrary shell commands. Successful exploitation can compromise confidentiality, integrity, and availability of the donor host and the MariaDB data it can access, typically under the operating-system privileges used by MariaDB/SST scripts.

Why it matters to the business

An attacker who can act as a cluster joiner can turn the database synchronization process into code execution on another database node. This can lead to database theft, tampering, service disruption, persistence on database infrastructure, and possible lateral movement from high-value data systems. Although exploitation requires privileged cluster-level access and is not currently listed in CISA KEV, the CVSS 8.0 severity and database-server impact make remediation important, especially for Galera clusters that allow node joins over less-trusted networks.

How an attack unfolds

An attacker first obtains the ability to connect as, or control, a MariaDB Galera joiner node that can request state snapshot transfer from an affected donor. The attacker triggers an SST using the mariabackup method and supplies crafted joiner-controlled parameters containing shell metacharacters or command payloads. On the vulnerable donor, the SST handling path interpolates insufficiently validated parameters into a command line. When the donor starts the SST process, the injected command is executed on the donor host. The attacker can then use that execution to read database files, alter data, create persistence, stage tools, disrupt database service, or pivot further from the database node.

How to fix it

Upgrade MariaDB to a patched version for the installed branch: 10.6.26 or later for 10.6.x, 10.11.17 or later for 10.11.x, 11.4.11 or later for 11.4.x, 11.8.7 or later for 11.8.x, and 12.3.2 or later for 12.3.x. Affected ranges are 10.6.1 through before 10.6.26, 10.11.1 through before 10.11.17, 11.4.1 through before 11.4.11, 11.8.1 through before 11.8.7, and 12.3.1. If immediate upgrade is not possible, restrict Galera cluster and SST connectivity to trusted nodes only, enforce host-based firewalls and network segmentation around replication/SST ports, prevent untrusted systems from joining the cluster, review SST credentials and cluster membership controls, and monitor or temporarily limit use of mariabackup SST where operationally feasible. Treat mitigations as temporary because the vulnerable command construction is fixed only by applying the vendor patch.

How to confirm the fix worked

Confirm the installed MariaDB version on every Galera node using package inventory and database version checks such as SELECT VERSION(); then compare the branch to the fixed versions. Review configuration for wsrep_sst_method=mariabackup to identify systems where the vulnerable path is relevant. Validate that all donor-capable nodes, not only active primaries, have been upgraded. After patching, restart or roll nodes according to MariaDB/Galera maintenance procedures and confirm cluster health, successful SST/IST behavior, and absence of downgrade packages. From a network perspective, verify that only approved cluster members can reach Galera replication and SST services and that unauthorized hosts cannot initiate joiner behavior.

Typical attack path

1. Gain control of, or valid access to, a MariaDB Galera node or system allowed to join the cluster.
2. Ensure the target donor is running an affected MariaDB version and uses the mariabackup SST method.
3. Initiate or force a state snapshot transfer from the malicious joiner to an affected donor.
4. Send crafted SST parameters that are accepted by the donor and interpolated into a shell command.
5. Achieve arbitrary command execution on the donor host under the SST/MariaDB execution context.
6. Use the foothold to access database contents, modify data, disrupt service, establish persistence, or move laterally.

How to detect it

To determine whether this was already exploited, review MariaDB error logs, Galera/wsrep logs, systemd journal entries, SST logs, shell history where applicable, auditd/process accounting/EDR telemetry, and network flow records around the time of any SST or node-join activity. Focus on donor nodes running affected versions with wsrep_sst_method=mariabackup. Look for unexpected joiner IP addresses, SST requests at unusual times, repeated failed SST attempts, log entries containing shell metacharacters in SST-related values, and child processes of mysqld, mariabackup, or wsrep_sst_mariabackup that are not part of normal backup/SST operation. On Linux hosts, investigate evidence of /bin/sh, bash, curl, wget, nc, python, perl, cron modification, new SSH keys, new local users, outbound connections, or files created in temporary directories during SST windows. If endpoint telemetry is available, build a process tree hunt for shell or network utility execution with parent process names associated with MariaDB SST. Also compare Galera membership history with approved node inventories to identify unauthorized or suspicious joiners.

• wsrep_sst_method=mariabackup
• wsrep_sst_mariabackup
• mariabackup
• WSREP_SST
• SST request
• State transfer
• /usr/bin/wsrep_sst_mariabackup
• /usr/bin/mariabackup
• /var/lib/mysql/innobackup.backup.log
• /var/lib/mysql/innobackup.prepare.log
• /bin/sh -c
• bash -c
• curl http
• wget http
• nc -e
• ncat -e
• python -c
• perl -e
• /tmp/
• /var/tmp/
• authorized_keys
• /etc/cron.d/
• crontab

What your security team should do

• Prioritize patching all MariaDB Galera nodes that use mariabackup SST, especially donor-capable production nodes and clusters reachable from broad internal networks.
• Inventory MariaDB versions across all database hosts and map each host to its fixed branch version: 10.6.26, 10.11.17, 11.4.11, 11.8.7, or 12.3.2 or later.
• Restrict cluster membership and SST traffic to explicitly approved nodes using firewalls, security groups, host allowlists, and strong operational controls.
• Review recent Galera node join, SST, and donor events for unexpected joiners, unusual source addresses, repeated SST failures, or anomalous SST parameters.
• Hunt for shell processes or unexpected child processes spawned by MariaDB, mariabackup, or SST scripts on database hosts.
• Rotate SST-related credentials and review cluster secrets if exploitation is suspected or if an untrusted joiner may have been present.
• Ensure database backups are current and offline/immutable where possible before maintenance, because exploitation can affect both data integrity and availability.