MariaDB Hit by Top-Severity RCE in Galera Clustering — wsrep Users Should Update Now (CVE-2026-49261)

A flaw rated at the maximum severity of 10.0 (CVE-2026-49261) has been found and patched in MariaDB, the database that runs behind countless web services. MariaDB is a popular database for storing things like member records and order histories; born as a fork and successor of MySQL, it runs on many hosting servers and business systems. If this hole is struck, the database server itself can be taken over.

But here is the crucial part. This 10.0 hole only applies to environments running a "Galera cluster" — multiple servers that keep the same data in sync — and that also have the wsrep_notify_cmd notification feature enabled. An ordinary single-server MariaDB (which is what most WordPress sites and small systems run) is not a target of CVE-2026-49261. The starting point is to check "do we run MariaDB as a multi-server cluster?"

If you do, this needs urgent action. MariaDB shipped fixed versions (10.6.27 / 10.11.18 / 11.4.12 / 11.8.8 / 12.3.2) on May 27, 2026, and urges that "if you are a Galera user, you are strongly recommended to upgrade as soon as possible." No real-world attacks have been reported so far, but the location of a flaw becomes easier to map once a fix ships.

What a Galera cluster is, and who is affected

A Galera cluster bundles multiple MariaDB servers so that "the service stays up even if any one of them goes down." Every server holds the same data in real time and keeps syncing with the others. It is widely used behind high-traffic web services and business systems that cannot afford downtime. This flaw lives in the part where "the nodes (servers) talk to each other."

The culprit, wsrep_notify_cmd, is a notification feature that automatically calls an administrator-specified script whenever cluster membership changes. Convenient — but it dropped the "name" of a newly joined node straight into the command line, so a crafted name lets an embedded instruction run on the server. Use the table below to see where your setup falls.

In other words, not everyone running MariaDB needs to panic right now. But if you have built high availability ("stay-up" redundancy) with Galera, this is not an "if conditions align" case — it is "urgent because it applies." If you use a managed cloud database, the provider handles the fix, so checking each vendor's notice is enough.

What happens — inside the maximum 10.0 score

Three Galera-related holes were fixed together. All are the same kind of flaw — "a value handed in from outside is dropped into a command without being checked" (OS command injection). The severity numbers use "CVSS," the international common score rating seriousness from 0 to 10.

CVE-2026-49261 is the heaviest at 10.0 because the attack needs no special privileges and, if it succeeds, lets an attacker run any command on the server with the privilege of the running database process — maximum impact to confidentiality, integrity, and availability alike. The other two are also flaws where externally sourced values were handled unsafely around Galera's sync, and all are closed in the fixed releases.

Who wants this bug, and what they walk off with

MariaDB is a staple database running behind web services and apps worldwide, and member records and every transaction collect here. The people after the worst hole are attackers who have intruded far enough to reach the cluster's communication network, ransomware crews that have gained a foothold on the internal network, and scanners hunting for servers that misconfiguration left with Galera ports exposed. What they carry off is member data, order histories, password hashes, and control of the database server itself. The moment a node with a crafted name joins the cluster, that name runs as part of the notification command in a shell, and the attacker's instructions execute with the privilege that runs the DB.

Once control is seized, the damage does not stop at one server. Because the same notification is delivered to every node, a single takeover spreads across the whole cluster. The stolen member data is sold on underground markets, buyers use it for impersonation and phishing, and the hashed passwords are cracked over time and reused to log in to other services. And using that server as a foothold, the intrusion expands to other servers on the internal network.

The final responsibility for this falls not on MariaDB's developers, but on the company that operates the cluster. If members' personal data leaks, reporting to the data protection authority and notifying the individuals become obligations, and depending on scale, damages and lost trust weigh heavily. The maximum value of CVSS 10.0 is only a gauge of technical seriousness; the real cost shows up in the after-the-fact response. If you use Galera, whether you can decide right now to update or to close off the traffic is what makes the difference.

A closer look at each hole

CVE-2026-49261: a node's name executed as a command

In a Galera cluster, a notification mechanism informs the administrator each time a server joins or leaves. That is wsrep_notify_cmd, which auto-calls a script you specify. The problem is that the joining node's name (wsrep_node_name) and incoming address (wsrep_node_incoming_address) were dropped into the notification command string without their contents being checked.

Computer commands treat certain symbols (semicolons, backticks, and the like) as "a new instruction starts here." So if a node joins the cluster with crafted symbols and an instruction embedded in its name, a string that should be just a name runs as a fresh command on the server. It runs with the privilege of the MariaDB main process (mariadbd), so beyond exfiltrating the database, an attacker can plant other programs on the server or spread the attack to other servers. This is "OS command injection," the classic attack of smuggling external input in as an instruction. CVSS is 10.0, and the report is credited to GitHub's security research team.

CVE-2026-48163 / CVE-2026-48165: the same kind of hole in sync handling

The other two are the same family of flaw, around the "state transfer (SST)" by which Galera lines up data between servers. CVE-2026-48163 is in the wsrep_sst_rsync handling used for data sync, and CVE-2026-48165 is in the handling of settings that can be changed at runtime; in each, values passed from outside were not processed safely. Both are CVSS 8.0, and while exploitation needs certain conditions, leaving them unpatched can lead to command execution. All three were closed in a single fix release.

Does your MariaDB need updating (version cheat sheet)

You can check your version with mariadbd --version, or by connecting to the database and running SELECT VERSION();. Use the table to match your number to its series. A fix is provided for each series.

The "High" priority applies only if you run a Galera cluster. On a single standalone server, the top-scoring CVE-2026-49261 itself does not apply. That said, the same release also fixes smaller, non-Galera issues (in audit logging, character-encoding handling, and so on), so even standalone setups should pick it up within their normal update cycle.

What to do right now

If you run a Galera cluster, the top priority is to update to your series' fixed release (10.6.27 / 10.11.18 / 11.4.12 / 11.8.8 / 12.3.2). That is the root fix. A cluster can be updated one node at a time — a "rolling upgrade" — without taking the service down.

If you cannot update immediately, there are two stopgaps. One is to temporarily turn off the offending notification feature (remove the wsrep_notify_cmd setting). The other is to block the ports the cluster uses for internal communication (4567, 4568, 4444) from untrusted networks. Galera's communication network should never be exposed externally in the first place; restricting it to member servers with a firewall is the baseline. But these only buy time; the root fix is the version update. No real-world attacks have been confirmed so far, but the location of a flaw becomes easier to map once a fix ships, so delay is simply accumulated risk.

A technical view: why an external value becomes a command

All three flaws stem from "pouring a string that came from outside straight into the material used to build a command." When a program invokes another command by stitching it together as one human-readable string, a symbol hidden inside gets read as a command separator, and unintended processing runs. To avoid this, externally sourced values must be passed as "plain data," kept separate from the command, or have dangerous symbols neutralized (escaped) before use.

This "mixing external input into a command" mistake is not confined to one product. The file-sharing software Samba, for instance, had a vulnerability allowing unauthenticated command execution from how values were handled for a password-change script. The more convenient the "call an external script" feature, the faster it becomes an entry point for takeover when the values it receives are weakly validated. As running AI-written code as-is becomes more common, holes that turn input directly into an instruction will keep being a recurring question.

A mechanism like Galera, where servers automatically talk to each other, tends to be built on the assumption that "the other node is trusted." But that assumption collapses the moment a third party can reach into the cluster's communication network. A design that treats even seemingly harmless information — like a node's name — as "an external, untrusted value" is the fundamental defense against this class of hole.

Sources

• ▸ MariaDB.org - Community Server Corrective Releases (May 27, 2026)
• ▸ MariaDB 10.6.27 release notes (CVE list)
• ▸ NVD - CVE-2026-49261 (OS command injection in wsrep_notify_cmd)
• ▸ NVD - CVE-2026-48165
• ▸ NVD - CVE-2026-48163
• ▸ Galera Cluster official site