CVE-2026-107814 in MariaDB
Summary
by MITRE • 10/09/2026
MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, MariaDB RPM packages created the dedicated mysql service account with the database data directory as its home directory. A database user with the FILE privilege could write startup dot-files such as .bash_profile into $HOME, and those files could execute when an administrator opened a login shell for the mysql account. Debian packages are not affected because they use /nonexistent as the account home. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability in question stems from a configuration oversight within the RPM packaging of MariaDB server versions ranging from 10.6.1 to 10.6.28, as well as specific releases of other branches including 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. In these affected versions, the package installation process configured the dedicated mysql service account with its home directory set to the database data directory rather than a standard system path such as /var/lib/mysql or /nonexistent. This deviation from best practices creates an environment where files written by the MySQL daemon into the data directory are interpreted as belonging to the user context of that same account, thereby blurring the lines between service operation and interactive shell behavior.
The core technical flaw involves the interaction between database privileges and operating system file execution mechanisms. A database user who has been granted the FILE privilege can write arbitrary files to any location accessible by the MySQL server process, which includes the data directory serving as the mysql account's home directory. By writing startup dot-files such as .bash_profile or .profile into this directory, an attacker with limited SQL privileges effectively places executable scripts in a location that is processed during shell initialization for the mysql user. This configuration allows low-privilege database users to escalate their access significantly by leveraging standard Unix login behaviors.
The operational impact of this vulnerability is severe because it facilitates privilege escalation from a restricted database role to full system-level control under the context of the mysql service account. When an administrator or automated process opens a login shell for the mysql account, typically via commands like su - mysql or ssh if configured, the operating system reads and executes the malicious dot-files placed in the home directory. This execution occurs with the permissions of the mysql user, which often possesses broad read access to sensitive database files and potentially other service-specific resources. Although this does not directly grant root privileges without further exploitation steps, it provides a significant foothold for lateral movement within the system and potential exfiltration or manipulation of critical data stored in the accessible directories.
This issue is specifically relevant to RPM-based distributions such as Red Hat Enterprise Linux, CentOS, Fedora, and openSUSE, while Debian-based systems remain unaffected because their packaging correctly utilizes /nonexistent as the home directory for service accounts, thereby preventing any file persistence that could be interpreted by a shell. The vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, and can be mapped to MITRE ATT&CK techniques related to privilege escalation and command-line interface abuse, specifically T1059 Command and Scripting Interpreter when considering the execution of the malicious scripts.
To mitigate this risk, organizations running affected MariaDB versions must upgrade immediately to patched releases where 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2 are the minimum safe thresholds. For environments that cannot upgrade immediately, administrators should manually change the home directory of the mysql user to a secure location such as /var/lib/mysql or /nonexistent using standard system utilities like usermod. Additionally, strict enforcement of least-privilege principles for database users is essential; specifically, the FILE privilege should be granted only to trusted administrative accounts and never to public-facing application users. Regular auditing of shell configurations and home directory permissions further reduces the attack surface by ensuring that no unauthorized startup scripts exist in service account directories.