MariaDB CVE-2026-49261: Galera wsrep_notify_cmd shell injection (CVSS 10.0)

MariaDB is the MySQL-compatible engine behind a large share of Swiss and EU public-sector LAMP stacks, Nextcloud and Mattermost deployments, and cantonal portals — so a wormable, root-capable RCE in its clustering layer is a direct concern for this audience.

The bug. CVE-2026-49261 (CVSS 3.1: 10.0, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) is an OS command injection in MariaDB Server's Galera cluster replication subsystem. When an operator configures wsrep_notify_cmd — the hook Galera invokes on cluster-membership and state changes, commonly used by auto-failover and load-balancer scripts — the server builds the notification command by string-concatenating peer-supplied fields (wsrep_node_name, wsrep_node_incoming_address) directly into a shell line, "without validating or escaping them" (NCSC-CH CSH, 2026-06-11). A malicious or compromised cluster member that announces a node name containing shell metacharacters (;, $(…), backticks) therefore executes arbitrary OS commands on every other member that has the hook configured, with the privileges of the mariadbd process — frequently mysql, sometimes root. The technique maps to T1059 (Command and Scripting Interpreter); code-level detail lives in MariaDB ticket MDEV-39721, with the corrective releases documented by the MariaDB Foundation (MariaDB Foundation, 2026-06-02).

Prerequisites and blast radius. Exploitation requires no MariaDB credential — the attacker needs membership in the Galera cluster or the ability to inject Galera protocol traffic on the replication port (default TCP 4567), plus wsrep_notify_cmd set on the victim members. That makes this a lateral-movement amplifier rather than a direct internet-edge bug: one compromised replica converts into code execution across every notification-enabled member of the cluster, including across data centres in geo-distributed deployments. The MariaDB Foundation's corrective-release note lists two companion fixes in the same cycle, CVE-2026-48165 and CVE-2026-48163, addressing related parameter-injection surfaces in the wsrep replication path (MariaDB Foundation, 2026-06-02). The realistic attacker is therefore one who already holds a foothold on a peer or on the replication segment, not an arbitrary internet client. NCSC-CH records exploitation status as unknown; no public PoC is referenced and no in-the-wild activity is reported as of 11 June.

Affected and patched versions. Community Server below 11.8.8 / 11.4.12 / 10.11.18 / 10.6.27; Enterprise Server below 11.8.6-4 / 11.4.10-8 / 10.6.25-22. Fixes ship in those releases and above (NCSC-CH CSH, 2026-06-11; MariaDB Foundation, 2026-06-02).

Hunt and detection concepts (no IOCs). The signal is process lineage: a database daemon does not normally fork a shell. Alert on mariadbd/mysqld spawning sh/bash/dash or any non-database child process (Sysmon Event ID 1 / Linux auditd execve records whose parent is the database service UID). Inventory which instances actually have wsrep_on=ON and a non-empty wsrep_notify_cmd — only those are exploitable, and the set is often smaller than operators assume because auto-failover tooling sets the variable opaquely. Watch for Galera membership churn from unexpected peer addresses on TCP 4567/4568.

Hardening / mitigation. Patch to the fixed releases. Where notification is not required, leave wsrep_notify_cmd unset (or wsrep_on=OFF on standalone instances). Restrict the Galera communication ports (4567 replication, 4568 IST, 4444 SST) to the known peer subnet with host firewall rules so an attacker cannot inject membership messages from outside the cluster. Treat the database service account as a high-value identity — an RCE here is RCE on the data tier.