MariaDB Patches CVSS 10.0 RCE Flaw in Galera Cluster Replication Component

MariaDB has addressed a critical remote code execution vulnerability — CVE-2026-49261, rated CVSS 10.0 — that exists within the Galera Cluster replication subsystem. Patches shipped on May 27, 2026, roughly two weeks before public disclosure on June 11, following standard coordinated disclosure practice. The flaw carries the maximum possible CVSS score and requires no authentication, no user interaction, and no elevated privileges to exploit.

What happened

The vulnerability lives in wsrep_notify_cmd, a MariaDB configuration directive that names a shell script to execute whenever cluster membership shifts — for example, when a node joins or departs. When a new node connects, MariaDB passes that node's reported name to the script as a command-line argument. The root cause (classified as CWE-78, OS command injection) is that MariaDB failed to sanitize this name before constructing the shell invocation. An attacker who can reach the Galera replication port and present a node name containing embedded shell metacharacters can cause those commands to execute under the privileges of the MariaDB process itself.

The CVSS 3.1 vector reflects the worst-case scenario: network-reachable, low attack complexity, no credentials required, no user interaction, and high impact across confidentiality, integrity, and availability with a changed scope. The Galera replication port (TCP 4567) is typically restricted to cluster peers at the firewall level, but misconfigured environments or threats originating inside the network perimeter face no authentication barrier.

CVE-2026-49261 was not patched in isolation. The May 27 update also resolves CVE-2026-48165 and CVE-2026-48163 — both rated CVSS 8.0 and both involving parameter injection within the same wsrep notification surface. The Galera library itself was bumped to version 26.4.27 in the same release cycle. Teams should treat this as a comprehensive remediation of the wsrep notification attack surface rather than a single-issue fix.

Who is at risk

The exposure is narrowly scoped but serious within that scope. Three conditions must all be present for a system to be vulnerable: the MariaDB instance must be part of a Galera Cluster deployment; the wsrep_notify_cmd option must be explicitly set in the server configuration (it has no default value); and the server must be running an affected version. Standard single-node MariaDB installations — including the vast majority of shared hosting stacks running WordPress or similar PHP applications — are not affected by this vulnerability.

The affected release lines and their corresponding safe targets are: 10.6.x up to 10.6.26 (fix in 10.6.27), 10.11.x up to 10.11.17 (fix in 10.11.18), 11.4.x up to 11.4.11 (fix in 11.4.12), 11.8.x up to 11.8.7 (fix in 11.8.8), and 12.3.1 (fix in 12.3.2). The practical exposure sits with managed database providers, cloud database services, and infrastructure teams running clustered configurations for high availability or redundancy.

What to watch

Because the public disclosure postdated the patch release by two weeks, opportunistic exploitation of unpatched systems remains plausible for any team that has not yet applied the May 27 updates. Managed database and cloud hosting providers operating Galera clusters at scale should audit configurations for active wsrep_notify_cmd directives and confirm patch status across all nodes. The breadth of affected release lines — spanning from the 10.6 long-term support branch through the 12.3 development series — suggests this component had not been subjected to rigorous input-validation review across its version history.