CVE-2026-107814 Overview
CVE-2026-107814 affects MariaDB server RPM packages, where the dedicated mysql service account was created with the database data directory as its home directory. A database user holding the FILE privilege can write shell startup files such as .bash_profile into the account's $HOME. Those files then execute when an administrator opens a login shell for the mysql account, leading to code execution in the context of that account. The flaw is tracked under [CWE-732: Incorrect Permission Assignment for Critical Resource]. Debian packages are not affected because they set the account home to /nonexistent. Fixed releases are MariaDB 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.
Critical Impact
Any database user with FILE privilege on an RPM-based MariaDB install can plant shell startup files that run as the mysql service account the next time an administrator opens a login shell.
Affected Products
- MariaDB server RPM packages from 10.6.1 up to (but not including) 10.6.28
- MariaDB server RPM packages 10.11.x prior to 10.11.19, 11.4.x prior to 11.4.13, and 11.8.x prior to 11.8.9
- MariaDB server RPM packages 12.3.x prior to 12.3.3, and 13.0.x prior to 13.0.2
Discovery Timeline
- 2026-10-09 - CVE-2026-107814 published to the National Vulnerability Database
- 2026-10-14 - Last updated in the NVD database
Technical Details for CVE-2026-107814
Vulnerability Analysis
The MariaDB RPM pre-install script creates a dedicated system account named mysql to own and run the database service. On affected RPM packages, that account was created with its home directory set to the database datadir (for example, /var/lib/mysql). The mysql process writes files into datadir during normal operation, and any authenticated database user holding the FILE privilege can issue SELECT ... INTO OUTFILE statements that write arbitrary files into that same directory.
Because datadir doubles as $HOME for the mysql user, an attacker can place shell startup files such as .bash_profile, .bashrc, or .profile there. These files are evaluated automatically whenever an administrator opens a login shell for the mysql account (for instance, via su - mysql or sudo -i -u mysql during routine maintenance). The commands in the planted dot-file then execute with the privileges of the mysql service account.
Root Cause
The root cause is an insecure design decision in support-files/rpm/server-prein.sh, where useradd was invoked with --home %{mysqldatadir}. Collocating a writable service data directory with the service account's shell startup search path violates the principle of least privilege and maps directly to [CWE-732].
Attack Vector
Exploitation requires an authenticated MariaDB account with the FILE privilege and relies on an administrator subsequently opening a login shell for the mysql user. The attack is remote in that the SQL statements can be issued over the network, but the final code execution step depends on administrator action.
# Vulnerable configuration (before patch) in support-files/rpm/server-prein.sh
useradd -M -r --home %{mysqldatadir} --shell /sbin/nologin \
--comment "MariaDB server" --gid %{mysqld_group} %{mysqld_user} 2> /dev/null || true
# Patched version pins $HOME to /nonexistent and fixes existing accounts
useradd -M -r --home /nonexistent --shell /sbin/nologin \
--comment "MariaDB server" --gid %{mysqld_group} %{mysqld_user} 2> /dev/null || true
usermod --gid %{mysqld_group} %{mysqld_user} 2> /dev/null || true
# Make sure the home dir is correct too (must not be datadir)
usermod -d /nonexistent %{mysqld_user} 2> /dev/null || true
Source: MariaDB commit d842d6e994a8b0d67c280bf785a11357d6b316a2
Detection Methods for CVE-2026-107814
Indicators of Compromise
- Presence of shell startup files such as .bash_profile, .bashrc, .profile, or .bash_logout inside the MariaDB datadir (commonly /var/lib/mysql).
- getent passwd mysql returning a home directory equal to the database datadir rather than /nonexistent.
- MariaDB general or audit logs showing SELECT ... INTO OUTFILE or SELECT ... INTO DUMPFILE statements that target filenames beginning with a dot in datadir.
Detection Strategies
- Audit database privileges and enumerate every account holding FILE to minimize the attacker population capable of writing files to disk.
- Enable the MariaDB audit plugin and alert on FILE-privileged writes whose target paths resolve under the mysql account's home directory.
- Monitor Linux endpoints for process executions where the parent is bash or sh running under uid mysql after a session transition such as su - mysql.
Monitoring Recommendations
- Deploy file integrity monitoring on datadir to flag creation or modification of any file whose basename starts with a dot.
- Collect and review /var/log/secure or journalctl entries for su and sudo invocations that switch to the mysql account.
- Forward MariaDB audit logs and OS process telemetry to a centralized data lake so that database FILE writes can be correlated with subsequent shell activity.
How to Mitigate CVE-2026-107814
Immediate Actions Required
- Upgrade MariaDB RPM installations to 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2 as appropriate for your branch.
- Inspect the mysql account with getent passwd mysql and reset its home directory to /nonexistent if it still points at datadir.
- Remove any unexpected dot-files already present under datadir and preserve copies for forensic review before deletion.
- Revoke the FILE privilege from all database accounts that do not have an explicit, documented need for it.
Patch Information
The fix is delivered in the following releases: MariaDB 10.6.28, MariaDB 10.11.19, MariaDB 11.4.13, MariaDB 11.8.9, MariaDB 12.3.3, and MariaDB 13.0.2. The upstream code change is documented in the MariaDB Security Advisory GHSA-m5gf-432r-g5jw.
Workarounds
- Manually relocate the mysql account home with usermod -d /nonexistent mysql on all RPM-based hosts that cannot be patched immediately.
- Set secure_file_priv to a directory outside datadir (or to an empty value) so that FILE-privileged writes cannot target the service account's home.
- Administer the database host without opening login shells for the mysql user; use sudo -u mysql <command> or su -s /sbin/nologin mysql which bypass dot-file evaluation.
# Fix the mysql account home and verify
usermod -d /nonexistent mysql
getent passwd mysql
# Restrict FILE-privileged writes to a dedicated directory
# Add to /etc/my.cnf under [mysqld]
secure_file_priv = /var/lib/mysql-files
# Review accounts that currently hold the FILE privilege
mysql -e "SELECT user, host FROM mysql.user WHERE File_priv='Y';"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

