Vulnerability overview

Four of the five MariaDB Server vulnerabilities disclosed in CSA Singapore alert AL-2026-144 on 16 October 2026 require a database session of some kind. CVE-2026-107821 stands apart. It is rated 8.0 under CVSS v3.1, and its precondition is a file placed in the data directory rather than a grant issued to an account.

Mechanism and exploitation conditions

The advisory states that the vulnerability allows an attacker to place a crafted FRM file in the data directory to trigger an out-of-bounds read or write, crash the server, or potentially execute arbitrary code. FRM files hold table definitions, and the server reads them when it opens or scans a table's metadata.

Trusting a file format is a recurring pattern in database engines. The parser expects a structure the storage engine wrote, and a crafted file can violate those expectations. An out-of-bounds write in a network-facing service is a genuine code-execution candidate, which is why the advisory pairs it with the code-execution language used elsewhere in the same alert.

The gating question is access. Placing a file in the data directory implies either filesystem access to the host or an indirect write path. CVE-2026-107814 and CVE-2026-107818 in the same release describe ways for a FILE-privileged account to write files. Chaining a write primitive into the data directory with a malformed FRM file is a plausible escalation route, and defenders should treat the trio as one story rather than three isolated tickets.

Impact

At minimum an attacker who can place the file can crash the server, which is a denial-of-service outcome against a tier-one asset. At worst the out-of-bounds write becomes code execution in the mysqld process, at which point every table on the instance is readable and the host is a foothold.

Data-directory integrity also matters for backup and recovery. Restoring an untrusted dump or cloning a data directory from an unverified source introduces the same exposure without any attacker needing network access to the database.

Affected products and scope

Version ranges named in the advisory 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. The advisory does not describe a public exploit and does not confirm in-the-wild use.

Confirm how your engine configuration stores table definitions rather than assuming the file type is absent from your deployment.

Exposure context

A ZoomEye query for app="MariaDB" returns 5111720 assets that identify as MariaDB. The query helps scope where the affected software family is deployed. It cannot tell you whether a given host's data directory is writable by an untrusted party, and it should not be presented as a population of exploitable systems.

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

Remediation and mitigations

Upgrade to a fixed build in your branch and verify the version string afterwards. Then close the write paths that make the file placement possible: restrict secure-file-priv to a dedicated directory, revoke FILE from accounts that only export reports, and remove shell-profile write access from the service account.

Operationally, treat the data directory as a restricted location. Only the database service account and root should be able to create files there. Verify that backup restores and host clones come from controlled sources, because a restore is a file-placement event by definition.

Monitoring holds limited value against a local write, which is why the control set leans on permissions and privilege minimisation rather than detection content.

References