MariaDB Server CVE-2026-107821

The attacker must be able to write a crafted binary FRM (table-definition) file into MariaDB's data directory and then cause the server to open that table, invoking the FRM image parser (init_from_binary_frm_image / create_key_infos). This presupposes filesystem write access to the data directory - typically the OS 'mysql' service account, a host-level compromise, or a database account with FILE/administrative privileges - matching the PR:H rating. Limiting factors that reduce realistic risk: no remote-unauthenticated path despite the AV:N label (file placement is a local operation), high attack complexity in crafting an FRM that reaches the vulnerable code, and the requirement that the poisoned table actually be opened. Affected only in versions 10.6.1 up to the fixed releases; patched installations are not exposed.

This is a high-CVSS (8.0) memory-safety flaw (CWE-1285, improper validation of counts/offsets/lengths/field boundaries) in MariaDB's FRM metadata parser (sql/table.cc), but multiple signals point to a lower real-world priority than the score suggests. No EPSS probability, CISA KEV listing, or public POC is present in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' The most important signal is a vector/description tension: the input vector is CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C, yet the description states the attacker must 'place a crafted FRM file in the data directory,' which is fundamentally a local filesystem operation, not a network one - the AV:N rating appears generous and AV:L is more defensible (verify with vendor advisory GHSA-c4gx-34mg-95q5). PR:H is consistent across both readings: an attacker already needs write access to the server's data directory, meaning they are effectively a DBA, the OS 'mysql' user, or an account with FILE-level privileges. AC:H reflects the difficulty of hand-crafting an FRM image that reaches the vulnerable paths. Net assessment: a genuine out-of-bounds read/write with potential code execution, but gated behind high privilege and local file placement, so it is a defense-in-depth / post-compromise privilege-boundary issue rather than an externally-exploitable priority. The absence of EPSS/KEV/POC is consistent with that lower-urgency profile.

An attacker who already holds write access to the MariaDB data directory (e.g. a low-trust DBA, a compromised 'mysql' OS account, or an account with FILE privileges) crafts a malicious .frm file with inconsistent counts, offsets, and field boundaries and places it where the server stores table metadata. When the server opens that table, the unvalidated FRM parsing in init_from_binary_frm_image/create_key_infos triggers an out-of-bounds read or write, crashing mysqld or potentially executing code in its context. No public exploit code is identified in the provided data.