CVE-2026-107818 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, the mariadb.service unit used /run/mysqld/wsrep-new-cluster during the next service restart. A database user with FILE privilege and a secure-file-priv configuration permitting writes to /run/mysqld could create that file and inject attacker-controlled environment values into the restarted service. 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability in question affects MariaDB server versions ranging from 10.6.1 through specific patched releases including 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. This issue stems from a misconfiguration in the systemd service unit file for MariaDB, specifically regarding how environment variables are handled during service restarts. The core technical flaw involves the use of an insecure path, /run/mysqld/wsrep-new-cluster, which is referenced by the mariadb.service unit to determine cluster state or configuration parameters upon restarting. Because this file resides in a world-writable directory under standard Linux permissions and lacks appropriate ownership restrictions within the service definition context, it becomes susceptible to manipulation by local users who possess specific database privileges.
An attacker with FILE privilege on the MariaDB instance can exploit this mechanism if the secure-file-priv configuration variable is set to permit writes to /run/mysqld or a subdirectory thereof. By leveraging their ability to write files via SQL statements such as SELECT ... INTO OUTFILE, an authenticated user can create and populate the wsrep-new-cluster file with arbitrary content. When the MariaDB service is subsequently restarted by systemd, it reads this environment variable from the manipulated file. This allows the attacker to inject malicious environment values directly into the process context of the database server. The impact of such injection is severe, as environment variables can influence critical runtime behaviors, potentially leading to privilege escalation, denial of service through configuration corruption, or further exploitation depending on how these injected variables are processed by subsequent initialization scripts or internal logic.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-94 Improper Control of Generation of Code which is often categorized under injection flaws. In the context of the MITRE ATT&CK framework, this technique corresponds to T1053 Scheduled Task/Job as it involves manipulating a service restart mechanism, and potentially T1608 Install Resilient Component if used for persistence, though primarily it represents an environment variable manipulation leading to potential command injection or configuration abuse. The attack vector is local and requires prior authentication with specific privileges, making it less likely in environments where database access is strictly controlled but highly dangerous in shared hosting or multi-tenant deployments where FILE privilege might be granted broadly.
Mitigation strategies focus on applying the vendor-provided patches for the affected versions immediately to close this code-level defect. For systems that cannot be patched instantly, administrators should audit and restrict the secure-file-priv setting to a dedicated directory with strict permissions owned by the mysql user, ensuring no other users can write to it. Additionally, modifying the systemd service unit file to use EnvironmentFile directives pointing to files in directories not writable by database users or removing reliance on world-writable paths for critical configuration variables will prevent exploitation. Regular auditing of FILE privilege grants and monitoring for unusual file creation events in /run/mysqld are also recommended defensive measures to detect potential attempts at this vulnerability before it is fully exploited.