DEV Community

SorrelThorncroft
SorrelThorncroft

Posted on

secure-file-priv Is Not a Patch: Hardening MariaDB File Writes After CVE-2026-107818

secure-file-priv Is Not a Patch: Hardening MariaDB File Writes After CVE-2026-107818

Vulnerability overview

CVE-2026-107818 is rated 8.4 under CVSS v3.1 in CSA Singapore alert AL-2026-144, and its exploitation condition is a configuration choice. A database user with the FILE privilege can create /run/mysqld and inject attacker-controlled environment values into the restarted service, provided secure-file-priv permits writes to that path. The setting that teams rely on to limit file writes is the same setting that decides whether this flaw is reachable.

Mechanism and exploitation conditions

The advisory frames the flaw as a write primitive that becomes an environment-injection path. The service restarts, reads its environment, and inherits values the attacker placed. Depending on how the unit file and wrapper scripts handle environment, injected values can influence library paths, configuration locations, or options passed to the server binary.

The companion flaw in the same release, CVE-2026-107814, does something similar against $HOME, writing dot-files such as .bash_profile for the service account. Together they show the same underlying weakness: the server treats a file-writing database privilege as if it were contained, while the operating system treats the written location as trusted input.

Neither flaw bypasses authentication. Both assume a session holding FILE. That detail matters because it turns the defensive conversation from patch urgency into grant design.

Impact

The realistic worst case is code execution under the service account on the next restart, from a write that required no shell access. That inverts the usual assumption that a database account is confined to the database.

Between the write and the restart, an attacker has time to prepare. Environment injection can point the service at altered libraries or configuration, and the restart that applies it is frequently an ordinary maintenance action. Discovery after the fact means untangling which restart applied which change.

Affected products and scope

Affected versions are 10.6.1 to 10.6.27, 10.11.1 to 10.11.18, 11.4.1 to 11.4.12, 11.8.1 to 11.8.8, 12.3.1 to 12.3.2 and 13.0.1. Because the flaw is conditional on secure-file-priv, two hosts on the same build can have very different exposure.

Exposure context

A ZoomEye query for app="MariaDB" returns 5111720 assets. Configuration is invisible from outside, so this number cannot distinguish a host writing files into /run/mysqld from one with a locked-down path. Internal configuration review is the only reliable measurement.

ZoomEye search: https://www.zoomeye.ai/searchResult?q=YXBwPSJNYXJpYURCIg%3D%3D

Remediation and mitigations

Patch first and verify the running build. Then fix the configuration that made the write possible, because the patch does not retroactively improve it.

Set secure-file-priv to a dedicated directory with no relationship to service unit paths, and confirm the value the running server reports rather than the one in a template. Give /run/mysqld ownership that excludes the database account from creating it, and review the unit file so environment values come from a root-owned location. Audit FILE grants and remove them from accounts whose real job is exporting query results.

Finally, check the service account home for unexpected dot-files and compare modification times against restart history. A file that postdates a recent write grant is a strong lead.

References

Top comments (0)