CVE-2026-107823 in MariaDB
Summary
by MITRE • 10/09/2026
MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the MariaDB view FRM parser did not safely encode embedded newline characters in a username. An account with CREATE USER and CREATE VIEW WITH GRANT OPTION could create a crafted username containing additional view metadata, causing the parser to interpret part of the username as security metadata and potentially escalating database privileges. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in MariaDB server versions ranging from 10.6.1 through specific patched releases such as 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2 stems from a critical flaw in the FRM parser component responsible for handling view definitions. MariaDB, as a community-developed fork of MySQL server, relies on this internal parsing logic to interpret metadata associated with database objects. The core technical issue lies in the failure to safely encode embedded newline characters within username strings during the creation or modification of views. In standard SQL operations and internal data structures, newlines are typically treated as delimiters or control characters that should be escaped or sanitized when stored in binary formats like FRM files. However, due to this encoding oversight, a crafted username containing literal newline sequences was not properly neutralized before being processed by the parser logic.
This lack of proper input sanitization allows an attacker with specific privileges to inject malicious metadata into the view definition structure. Specifically, any database account possessing both CREATE USER and CREATE VIEW WITH GRANT OPTION capabilities can exploit this flaw. By constructing a username that includes carefully placed newline characters followed by additional view metadata fields, the parser is tricked into interpreting parts of the username string as legitimate security-related attributes rather than simple text data. This misinterpretation effectively bypasses standard validation checks because the parser processes these injected segments as if they were part of the official schema definition for user permissions and access controls.
The operational impact of this vulnerability is severe, primarily centering on privilege escalation within the database environment. By manipulating how the FRM file interprets its own metadata, an attacker can potentially elevate their privileges beyond what was originally granted by a Database Administrator or security officer. This could result in unauthorized access to sensitive data, modification of system tables, or complete compromise of the underlying MariaDB instance depending on the configuration and existing privilege grants. The vulnerability represents a classic case where input validation failures lead to structural integrity issues within application metadata storage mechanisms, allowing for unintended state changes that affect security boundaries.
From an industry standard perspective, this flaw aligns with CWE-20 Improper Input Validation, as the system failed to reject or properly handle invalid characters in user-supplied data intended for internal processing. Furthermore, it relates to CWE-74 Injection in External Control of File Name or Path when considering how metadata is parsed and stored, although more accurately it reflects issues related to structural injection into configuration files. In terms of MITRE ATT&CK mapping, this technique corresponds to T1068 Exploitation for Privilege Escalation, where an adversary leverages a software vulnerability to gain higher-level permissions on the operating system or database engine. It also touches upon aspects of persistence and defense evasion if the crafted views are used to maintain access or hide malicious activities within legitimate-looking metadata structures.
Mitigation strategies require immediate attention from database administrators managing affected versions. The primary remediation is to upgrade MariaDB server to one of the fixed releases listed, specifically 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2, which contain patches for this encoding issue. Until upgrading is feasible, organizations should enforce strict least-privilege principles by auditing accounts that hold CREATE USER and CREATE VIEW WITH GRANT OPTION privileges. Restricting these high-level permissions to only the most trusted administrative accounts reduces the attack surface significantly. Additionally, implementing rigorous input validation at the application layer before sending SQL statements involving username creation or view definitions can provide a secondary defense mechanism against malformed inputs attempting to exploit this parser weakness.