CVE-2026-107821: 
MariaDB Server Análisis y mitigación de vulnerabilidades

CVE-2026-107821 is a vulnerability in MariaDB Server involving insufficient validation of binary FRM (table definition) file metadata, which can lead to out-of-bounds reads or writes, server crashes, or remote code execution. It affects MariaDB versions 10.6.1–10.6.27, 10.11.1–10.11.18, 11.4.1–11.4.12, 11.8.1–11.8.8, 12.3.1–12.3.2, and 13.0.1. The vulnerability was reported by researchers pinebudweiser and Ph4nt0m, disclosed via a GitHub Security Advisory on September 7, 2026, and published to NVD on October 9, 2026. It carries a CVSS v3.1 base score of 8.0 (High) (GitHub Advisory, Red Hat CVE).

The root cause is improper validation of counts, offsets, lengths, and field boundaries within binary FRM files parsed by MariaDB when opening a table, classified as CWE-1285 (Improper Validation of Specified Index, Position, or Offset in Input) and CWE-787 (Out-of-bounds Write). An attacker with the FILE privilege and access to the MariaDB data directory can place a specially crafted FRM file; when the server opens the corresponding table, it processes the malformed metadata without adequate bounds checking, triggering out-of-bounds memory access. The fix (commit 3b1c2e5) added numerous validation checks in sql/table.cc, converting unsafe asserts to conditional checks covering key part counts, field value overlaps, record boundaries, and other structural constraints (GitHub Advisory, Patch Commit).

Successful exploitation can result in full compromise of the MariaDB server — including high confidentiality, integrity, and availability impact — with potential for arbitrary code execution in the context of the database service account. An attacker could crash the server (denial of service), read sensitive data from server memory via out-of-bounds reads, or achieve remote code execution that could enable lateral movement within the hosting environment. The scope is marked as Changed, indicating that a successful exploit can affect resources beyond the database process itself (GitHub Advisory, Red Hat CVE).

Exploitation requires high privileges (specifically the FILE privilege) and the ability to write to the MariaDB data directory, making opportunistic mass exploitation unlikely. No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable (GitHub Advisory, Red Hat CVE).

1. Privilege Acquisition: Obtain a MariaDB account with the FILE privilege, either through credential theft, brute force, or SQL injection that escalates to a privileged session.
2. Verify secure-file-priv configuration: Confirm that the secure-file-priv server variable permits write access to the MariaDB data directory (e.g., it is set to an empty string or to the data directory path).
3. Craft a malicious FRM file: Construct a binary FRM file with invalid metadata — such as manipulated counts of keys, keyparts, or fields, or field offsets that extend beyond record boundaries — designed to trigger out-of-bounds memory access when parsed.
4. Place the FRM file: Use SELECT ... INTO OUTFILE or a direct file write (via FILE privilege) to drop the crafted .frm file into the target database's data directory subdirectory.
5. Trigger parsing: Execute a USE <database>; SHOW TABLES; or SELECT * FROM <poisoned_table>; statement to cause the server to open and parse the malicious FRM file.
6. Achieve impact: Depending on the crafted payload, the server crashes (DoS), leaks memory contents, or executes attacker-controlled code in the context of the MariaDB process (GitHub Advisory, Patch Commit).

• File System: Unexpected or anomalous .frm files in the MariaDB data directory with unusual file sizes, timestamps inconsistent with normal table creation, or files not corresponding to any known table schema.
• Logs: MariaDB error log (/var/log/mysql/error.log or equivalent) showing segmentation faults, assertion failures, or crashes during table open operations; entries referencing table.cc or FRM parsing errors.
• Logs: Audit log entries showing a privileged user executing SELECT ... INTO OUTFILE targeting the data directory, or unusual LOAD DATA INFILE activity.
• Process: Unexpected crashes or restarts of the mysqld/mariadbd process, particularly correlated with table access operations.
• Network: Database connections from unexpected source IPs using high-privilege accounts, especially followed by file write operations or table access attempts on recently created or modified tables.

Upgrade MariaDB to one of the patched versions: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2 (GitHub Advisory). As a workaround, restrict the FILE privilege to only trusted, essential accounts and configure secure-file-priv to a directory outside the data directory to prevent unauthorized FRM file placement. Additionally, enforce strict OS-level file system permissions on the MariaDB data directory so that only the mysql service account can write to it (GitHub Advisory, Red Hat CVE).

The vulnerability was reported by security researchers pinebudweiser and Ph4nt0m and acknowledged by the MariaDB project via a GitHub Security Advisory. Red Hat has tracked the issue in their CVE database. General community coverage has been limited to automated vulnerability tracking platforms (VulDB, CVEFeed, Vulners), with no notable independent researcher commentary or significant social media discussion observed at the time of this report (GitHub Advisory, Red Hat CVE).