CVE-2026-48165

What it actually does

This is a command injection vulnerability in MariaDB Galera-related global system variable handling. In affected MariaDB versions, a highly privileged database user can set wsrep_sst_receive_address or wsrep_sst_donor in a way that causes shell commands to execute on the Galera joiner node as the operating-system user running the mariadbd process. Successful exploitation can give the attacker code execution with the database service account's permissions, enabling access to database files, local configuration, credentials readable by the service account, and potential modification or disruption of database operations.

Why it matters to the business

An attacker who already has high-level MariaDB privileges could turn database administrative access into operating-system command execution on a database server. This can lead to data theft, unauthorized data changes, service outages, destruction of database files, or a foothold for lateral movement. The issue is high severity, but exploitation requires privileged database access and specific Galera/SST conditions, and it is not currently listed in CISA KEV or known ransomware use. Because MariaDB is commonly deployed in business-critical applications, exposed vulnerable clusters should still be prioritized for upgrade.

How an attack unfolds

An attacker first obtains or abuses a high-privileged MariaDB account capable of changing global system variables. In an affected Galera-enabled deployment, the attacker modifies wsrep_sst_receive_address or wsrep_sst_donor with maliciously crafted content. During the relevant state snapshot transfer or joiner-node workflow, MariaDB passes the variable value into shell-invoked logic without sufficient sanitization. The injected command then runs on the Galera joiner node as the mariadbd operating-system user. From there, the attacker may read database files, stage tools, alter data, disrupt replication, create persistence where permissions allow, or use credentials and network access available to the database service account to move further.

How to fix it

Upgrade affected MariaDB installations 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. Affected ranges are 10.6.1 through before 10.6.27, 10.11.1 through before 10.11.18, 11.4.1 through before 11.4.12, 11.8.1 through before 11.8.8, and 12.3.1. If immediate patching is not possible, restrict high-privileged database accounts, remove unnecessary privileges to change global variables, disable or tightly control Galera/SST functionality where not required, limit database administrative access to trusted management networks, and monitor or block changes to wsrep_sst_receive_address and wsrep_sst_donor. Run mariadbd with least-privilege OS permissions and ensure file-system and network egress controls limit what the database service account can access.

How to confirm the fix worked

Confirm the running MariaDB version with SELECT VERSION(); or mariadb --version and verify it is at or above the fixed version for the deployed release branch. Review package manager output and service restart status to ensure the patched mariadbd binary is actually running, not merely installed. Check Galera cluster nodes individually because mixed-version clusters may leave some joiner nodes exposed. Verify that only tightly controlled administrative roles can modify global system variables. Review configuration and runtime values for wsrep_sst_receive_address and wsrep_sst_donor to ensure they contain only expected host, address, or donor values and no shell metacharacters. Where safe, validate in a non-production environment that suspicious values are rejected or do not result in shell execution after upgrade.

Typical attack path

1. Gain access to a high-privileged MariaDB account, such as one able to set global system variables.
2. Identify that the target runs an affected MariaDB version with Galera/wsrep functionality in use or available.
3. Set wsrep_sst_receive_address or wsrep_sst_donor to a crafted value containing shell metacharacters or command content.
4. Trigger or wait for the Galera SST/joiner workflow that consumes the malicious variable value.
5. Execute commands as the operating-system user running mariadbd on the joiner node.
6. Use the resulting access to collect data, modify files, disrupt database service, or attempt lateral movement.

How to detect it

To determine whether exploitation already occurred, review MariaDB audit logs, general query logs, error logs, and Galera/SST logs for changes to wsrep_sst_receive_address or wsrep_sst_donor, especially values containing shell metacharacters such as semicolons, backticks, pipes, dollar-parentheses, redirection, or ampersands. Correlate those events with endpoint process telemetry, auditd, Sysmon for Linux, EDR, or system logs showing mariadbd spawning shells, interpreters, download utilities, or networking tools. Examine /var/lib/mysql, /tmp, /var/tmp, service working directories, and Galera SST directories for unexpected scripts, binaries, web shells, archives, or recently modified files owned by the MariaDB service account. Review authentication and privilege-change logs for newly created high-privileged database users or unusual administrative sessions preceding the variable change. Network telemetry should be checked for unexpected outbound connections from database servers around the same time, particularly to file-sharing, command-and-control, or unfamiliar external IP addresses. Because no public exploit maturity or KEV exploitation is reported for this issue, detections should focus on abuse patterns rather than a single known campaign signature.

• SET GLOBAL wsrep_sst_receive_address
• SET GLOBAL wsrep_sst_donor
• SET @@global.wsrep_sst_receive_address
• SET @@global.wsrep_sst_donor
• wsrep_sst_receive_address
• wsrep_sst_donor
• wsrep_sst_receive_address=
• wsrep_sst_donor=
• WSREP_SST
• mariadbd
• /bin/sh
• /bin/bash
• /usr/bin/curl
• /usr/bin/wget
• /usr/bin/nc
• /bin/nc
• /tmp/
• /var/tmp/
• /var/lib/mysql/

What your security team should do

• Patch MariaDB Galera-capable systems to the appropriate fixed version as the primary control.
• Inventory all MariaDB servers and identify those running affected branches, especially Galera clusters and systems where wsrep is enabled.
• Audit high-privileged MariaDB accounts and remove unnecessary rights to change global variables.
• Review MariaDB audit/general logs for historical changes to wsrep_sst_receive_address and wsrep_sst_donor.
• Hunt endpoint telemetry for child shell or scripting processes spawned by mariadbd.
• Restrict administrative database access to trusted hosts and require strong authentication for privileged accounts.
• Apply least-privilege OS hardening to the mariadbd service account, including file-system and outbound network restrictions.
• Prioritize remediation based on business criticality, internet/VPN administrative exposure, Galera usage, and presence of shared or weak privileged database credentials.