CVE-2026-107818: MariaDB Server RCE Vulnerability

CVE-2026-107818 Overview

CVE-2026-107818 is a privilege escalation vulnerability in MariaDB server affecting the systemd service unit's handling of the wsrep-new-cluster bootstrap file. The mariadb.service unit reads /run/mysqld/wsrep-new-cluster during restarts as a systemd EnvironmentFile. A database user holding the FILE privilege, combined with a secure-file-priv configuration that permits writes to /run/mysqld, can create this file and inject attacker-controlled environment variables into the restarted service. The flaw is tracked as [CWE-15: External Control of System or Configuration Setting] and affects MariaDB versions from 10.6.1 through the fixed releases.

Critical Impact
An authenticated database user with FILE privilege can inject arbitrary environment variables into the MariaDB systemd service upon restart, enabling privilege escalation on the host.

Affected Products

MariaDB server 10.6.1 through 10.6.27 (fixed in 10.6.28)
MariaDB server 10.11.x through 10.11.18, 11.4.x through 11.4.12, 11.8.x through 11.8.8
MariaDB server 12.3.x through 12.3.2 and 13.0.x through 13.0.1

Discovery Timeline

2026-10-09 - CVE-2026-107818 published to NVD
2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-107818

Vulnerability Analysis

MariaDB's Galera cluster bootstrap workflow writes the file /run/mysqld/wsrep-new-cluster containing a line such as _WSREP_NEW_CLUSTER='--wsrep-new-cluster'. The mariadb.service systemd unit then consumes this file as an EnvironmentFile on next restart. Because /run/mysqld is writable by the mysql user that owns the mariadbd process, any SQL path that can write files into that directory becomes a vector to control the service environment.

A database account granted the FILE privilege can issue SELECT ... INTO OUTFILE statements. When secure-file-priv is unset or configured to permit writes under /run/mysqld, the attacker can write a crafted wsrep-new-cluster file containing additional KEY=VALUE lines. On the next mariadb.service restart, systemd loads those lines into the service environment, allowing injection of variables such as LD_PRELOAD or other runtime controls that influence process behavior.

Root Cause

The root cause is a layout mistake: a runtime state file consumed by systemd lived in a directory the database process itself could write. The patch introduces a dedicated INSTALL_RUNDIR for runtime state that mariadbd must not be able to modify, separating it from the socket directory /run/mysqld.

Attack Vector

Exploitation requires an authenticated database session with FILE privilege, a permissive secure-file-priv value, and the ability to trigger or wait for a mariadb.service restart. The attack crosses a privilege boundary from the database user context into the systemd-managed service context, which typically runs with elevated local permissions.

bash

     exit 0
 fi

-echo _WSREP_NEW_CLUSTER='--wsrep-new-cluster' > "@INSTALL_RUNDATADIR@/wsrep-new-cluster" && \
+# INSTALL_RUNDIR, not the socket directory - the latter is writable by
+# mariadbd, which could then inject arbitrary variables into the service
+# environment. Removing the file here and not in the service file,
+# because that runs as mysql and cannot unlink in /run.
+new_cluster=@INSTALL_RUNDIR@/mariadb-wsrep-new-cluster
+trap 'rm -f "$new_cluster"' EXIT
+trap 'exit 1' HUP INT TERM
+
+echo _WSREP_NEW_CLUSTER='--wsrep-new-cluster' > "$new_cluster" && \
     systemctl restart mariadb.service

 extcode=$?

-rm -f "@INSTALL_RUNDATADIR@/wsrep-new-cluster"
-
 exit $extcode

Source: MariaDB commit e3d62d4e. The patch relocates the bootstrap file to INSTALL_RUNDIR, outside the directory writable by mariadbd.

Detection Methods for CVE-2026-107818

Indicators of Compromise

Unexpected files at /run/mysqld/wsrep-new-cluster containing environment keys beyond _WSREP_NEW_CLUSTER.
MariaDB general or audit log entries showing SELECT ... INTO OUTFILE '/run/mysqld/...' statements from non-administrative users.
mariadbd child processes spawned with unexpected environment variables such as LD_PRELOAD after a service restart.

Detection Strategies

Audit grants of the FILE privilege and review the configured value of secure-file-priv; flag any instance where it is empty or points inside /run/mysqld.
Monitor filesystem writes to /run/mysqld/ for file names other than the MariaDB socket, especially wsrep-new-cluster.
Correlate systemctl restart mariadb.service or galera_new_cluster executions with recent SQL OUTFILE activity.

Monitoring Recommendations

Enable the MariaDB audit plugin and ship events to a centralized log pipeline for review of FILE privilege usage.
Deploy host-based file integrity monitoring on /run/mysqld/ with alerts on new file creation.
Track systemd EnvironmentFile parsing errors and unusual environment variables in mariadbd process metadata via EDR telemetry.

How to Mitigate CVE-2026-107818

Immediate Actions Required

Upgrade MariaDB to 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2 depending on the deployed branch.
Revoke the FILE privilege from any account that does not strictly require it.
Set secure-file-priv to a dedicated directory outside /run/mysqld and outside any systemd-read path.

Patch Information

The fix is published in the upstream commit e3d62d4e and documented in MariaDB Security Advisory GHSA-mhvc-vqcq-7vq5. Tracking is maintained in MariaDB JIRA MDEV-40629. Fixed release packages are available at 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

Workarounds

Explicitly set secure-file-priv to a path such as /var/lib/mysql-files/ that systemd never reads as an EnvironmentFile.
Remove the FILE privilege from all non-administrative accounts until the upgrade is deployed.
Override the mariadb.service unit to drop the EnvironmentFile directive referencing /run/mysqld/wsrep-new-cluster where Galera bootstrap is not required.