CVE-2026-49261

What it actually does

This is a command injection vulnerability in MariaDB Galera/wsrep notification handling. When `wsrep_notify_cmd` is enabled, affected MariaDB versions pass the joining node name into shell command execution without sufficient sanitization. An unauthenticated network attacker who can cause a maliciously named node to participate in, or be processed by, the cluster membership workflow can embed shell metacharacters in the joiner node name and cause arbitrary commands to execute on the MariaDB server host. Because command execution occurs in the context of the MariaDB service and may cross trust boundaries in clustered deployments, the impact can include full compromise of database confidentiality, integrity, and availability, plus potential operating-system-level compromise depending on service privileges.

Why it matters to the business

Successful exploitation can allow an attacker to run commands on database servers, steal or alter data, disrupt clustered database availability, deploy persistence, or use the database host as a foothold into the broader network. The CVSS score is critical and the attack is network-accessible with low complexity, so organizations running affected MariaDB Galera configurations with `wsrep_notify_cmd` enabled should treat this as urgent even though it is not currently listed in CISA KEV and no public exploit maturity was reported in the supplied data.

How an attack unfolds

An attacker first identifies a MariaDB deployment using Galera/wsrep clustering where `wsrep_notify_cmd` is configured. The attacker then attempts to influence cluster membership events by presenting or registering a joiner node name containing shell metacharacters and attacker-controlled commands. When the vulnerable MariaDB server processes the join event, it invokes the configured notification command and includes the malicious node name in a shell-interpreted context. The embedded command is then executed by the operating system under the MariaDB service account or the account used to run the notification hook. The attacker can use the initial command execution to validate access, retrieve secrets, modify database files, create outbound callbacks, deploy persistence, or disrupt the database service.

How to fix it

Upgrade MariaDB to a fixed release: 10.6.27 or later for the 10.6 branch, 10.11.18 or later for the 10.11 branch, 11.4.12 or later for the 11.4 branch, 11.8.8 or later for the 11.8 branch, and 12.3.2 or later for the 12.3 branch. Affected versions are 10.6.1 through 10.6.26, 10.11.1 through 10.11.17, 11.4.1 through 11.4.11, 11.8.1 through 11.8.7, and 12.3.1 when `wsrep_notify_cmd` is enabled. If immediate upgrade is not possible, disable `wsrep_notify_cmd` as a workaround and restart/reload the affected service as required. Restrict Galera cluster communication ports to trusted cluster members only, enforce mutual authentication and network segmentation for cluster traffic, review all notification scripts for shell-safe argument handling, and run MariaDB with least-privilege service accounts.

How to confirm the fix worked

Confirm the installed MariaDB version is at or above the fixed release for the deployed branch. Verify configuration files and runtime variables to ensure `wsrep_notify_cmd` is disabled where not required or safely configured after patching. Review `my.cnf`, included configuration directories, and package-managed service overrides for any remaining `wsrep_notify_cmd` entries. Validate that Galera/wsrep cluster ports are not reachable from untrusted networks. In a controlled non-production environment, confirm that node names containing shell metacharacters are rejected, escaped, or do not result in shell execution. After remediation, restart affected MariaDB services where required and verify cluster health, replication state, and notification workflows continue to operate as expected.

Typical attack path

1. Discover externally or internally reachable MariaDB/Galera nodes and determine whether wsrep clustering is in use.
2. Identify or infer that `wsrep_notify_cmd` is enabled through configuration exposure, operational behavior, or targeted probing.
3. Craft a malicious joiner node name containing shell metacharacters such as command separators, command substitution, or pipeline operators.
4. Trigger a Galera/wsrep membership or join event that causes the vulnerable server to process the malicious node name.
5. MariaDB invokes the configured `wsrep_notify_cmd` and the shell interprets the injected payload.
6. Execute arbitrary commands as the MariaDB service user or notification-command user.
7. Expand access by reading credentials, modifying data, dropping a web shell or backdoor where applicable, establishing outbound command-and-control, or moving laterally from the database host.

How to detect it

Investigate MariaDB error logs, Galera/wsrep logs, system journals, auditd logs, EDR telemetry, process creation logs, and shell history for evidence of unexpected command execution around cluster membership changes. Focus on deployments where `wsrep_notify_cmd` is enabled. Look for joiner or member names containing shell metacharacters such as `;`, `&&`, `||`, `|`, backticks, `$()`, redirection operators, or newline characters. Correlate wsrep membership events with child processes spawned by `mariadbd`, `mysqld`, notification scripts, `/bin/sh`, `/bin/bash`, `curl`, `wget`, `nc`, `ncat`, `python`, `perl`, or package-management tools. Review the configured notification command and its script logs for unusual arguments, outbound network connections, file writes, new users, cron entries, systemd services, SSH authorized keys, modified database files, and unexpected restarts. Network detection should look for untrusted hosts attempting to communicate with Galera cluster ports and for database servers initiating unusual outbound connections immediately after join or membership-change events.

• wsrep_notify_cmd
• WSREP: Member
• WSREP: view
• WSREP: JOINED
• WSREP: declaring .* stable
• /bin/sh -c
• /bin/bash -c
• mariadbd -> /bin/sh
• mysqld -> /bin/sh
• mariadbd -> /bin/bash
• mysqld -> /bin/bash
• ;curl
• ;wget
• && curl
• && wget
• | sh
• | bash
• $(curl
• $(wget
• `curl
• `wget
• /etc/mysql/my.cnf
• /etc/my.cnf
• /etc/mysql/mariadb.conf.d/
• /etc/systemd/system/
• /var/lib/mysql/
• /var/log/mysql/error.log
• /var/log/mariadb/mariadb.log

What your security team should do

• Inventory MariaDB Galera/wsrep deployments and prioritize any affected versions with `wsrep_notify_cmd` enabled.
• Upgrade affected MariaDB branches to 10.6.27, 10.11.18, 11.4.12, 11.8.8, 12.3.2, or later as applicable.
• If patching is delayed, immediately disable `wsrep_notify_cmd` and restrict Galera cluster network access to explicitly trusted nodes.
• Hunt for suspicious cluster node names, notification-command executions, and unexpected shell child processes spawned by `mariadbd` or `mysqld`.
• Review notification scripts for unsafe shell usage and convert them to use fixed arguments, strict input validation, and safe quoting.
• Rotate database and operating-system credentials if evidence suggests command execution occurred on a database server.
• Add monitoring for changes to MariaDB configuration files, especially additions or modifications to `wsrep_notify_cmd`.
• Ensure database service accounts have minimal OS permissions and cannot write to sensitive paths or execute unnecessary administrative tools.