DEV Community

StarkMan
StarkMan

Posted on

MariaDB's FILE Privilege Is a Filesystem Primitive: CVE-2026-107814 and CVE-2026-107818

#cybersecurity #database #infosec #security

MariaDB's FILE Privilege Is a Filesystem Primitive: CVE-2026-107814 and CVE-2026-107818

Vulnerability overview

The Cyber Security Agency of Singapore published alert AL-2026-144 on 16 October 2026 describing five MariaDB Server vulnerabilities fixed by the project. Two of them share a cause that a patch note makes easy to skim past. CVE-2026-107814 and CVE-2026-107818 are both rated 8.4 under CVSS v3.1, and both turn an ordinary database grant into the ability to write files that the operating system later trusts.

The other three flaws in the same release are CVE-2026-107815 at 8.5, CVE-2026-107821 at 8.0 and CVE-2026-107823 at 7.2. This analysis concentrates on the pair that abuses the FILE privilege, because their exploitation prerequisites are the ones most likely to be present in routine database estates.

Mechanism and exploitation conditions

CVE-2026-107814 allows a database user holding the FILE privilege to write startup dot-files such as .bash_profile into the $HOME directory of the database service account. The written file is inert until a human opens a login shell for the mysql account, at which point the shell reads the profile and executes its contents. The flaw is therefore a persistence mechanism dressed as a file-write issue, and the trigger is administrative behaviour rather than an automated cron job.

CVE-2026-107818 follows a related path. A user with the FILE privilege can create /run/mysqld and inject attacker-controlled environment values into the restarted service. That path is conditional: it depends on the secure-file-priv configuration permitting writes to /run/mysqld. Where administrators have left secure-file-priv empty, file writes across the filesystem are unrestricted and the condition is trivially satisfied.

Neither flaw requires remote code execution against the server binary. The FILE privilege is normally treated as a data-export convenience, granted to reporting accounts that stage query output on disk. Once granted, it becomes a filesystem primitive with the effective permissions of the mysqld process.

Impact

The immediate consequence is code execution in the context of the database service account, reached through a shell profile or through environment injection into a service restart. From that position an attacker can read the full data directory, harvest credentials embedded in configuration, and reach any system the database account can access over the network.

Operational risk concentrates on two populations. The first is shared database platforms where FILE was granted broadly to support operational scripts. The second is hosts where the service account shares $HOME with human login behaviour, such as manually administered virtual machines. Container images that never spawn a login shell reduce the trigger surface for CVE-2026-107814 without addressing CVE-2026-107818.

Affected products and scope

The advisory lists MariaDB Server versions 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. That spans six maintained branches, so branch-level patch inventory matters more than a single version comparison.

The advisory does not state which upstream engine component each fix touched, and it does not describe a proof of concept. Treat both as unknown rather than as evidence of low risk.

Exposure context

A ZoomEye query for the database fingerprint app="MariaDB" returns 5111720 matching assets. That figure describes deployment scale for identification purposes: it counts hosts whose banners identify MariaDB, not hosts confirmed to be running an affected build or to have granted FILE.

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

Remediation and mitigations

Upgrade to the current release in your branch, following the vendor guidance to update promptly. Because six branches are affected, verify the exact build string after upgrading instead of assuming a package manager did the right thing.

Where an upgrade cannot be scheduled immediately, attack the prerequisites. Audit every account holding the FILE privilege with SHOW GRANTS and revoke it where the business case is a query export that can be redirected. Set secure-file-priv to a dedicated directory. Review filesystem permissions on the service account home so that the account cannot write shell profiles, and give /run/mysqld ownership and mode expectations that exclude arbitrary environment injection.

References

Top comments (0)