CVE-2026-107817 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 mysql_json plugin assumed that imported MySQL tables contained valid MySQL binary JSON data. A specially prepared MySQL table containing invalid JSON data could cause out-of-bounds reads, information disclosure, or a server crash. 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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/10/2026
The MariaDB server, a widely used community-developed fork of the MySQL relational database management system, contains a critical security flaw within its mysql_json plugin that affects multiple recent release branches including versions from 10.6 through 13.0. This vulnerability arises from an insufficient validation mechanism when processing imported data structures. Specifically, the plugin operates under the assumption that all incoming MySQL tables contain strictly valid binary JSON data as defined by the internal schema and format specifications. When this assumption is violated by a specially crafted table containing malformed or invalid JSON payloads, the application logic fails to perform necessary boundary checks before attempting to parse or access memory regions associated with these structures.
From a technical perspective, this flaw constitutes an out-of-bounds read vulnerability, which aligns with Common Weakness Enumeration identifier CWE-125. The root cause lies in the lack of rigorous input validation and bounds checking during the deserialization process of binary JSON objects. When the server processes data that does not conform to expected structural constraints, it may attempt to access memory addresses beyond the allocated buffer limits. This behavior can lead to several severe operational consequences depending on how the underlying system handles such illegal memory accesses. In many cases, this results in an immediate denial of service condition where the MariaDB process crashes due to a segmentation fault or similar fatal error triggered by accessing unmapped or protected memory pages.
Beyond simple availability impacts, out-of-bounds reads pose significant risks regarding information disclosure and potential remote code execution vectors depending on the specific compiler optimizations and runtime environment. An attacker who can inject malformed JSON data into an importable table structure could potentially read sensitive contents from adjacent memory locations. This might include authentication tokens, session identifiers, or other confidential database records stored in nearby heap allocations. Such information leakage violates fundamental confidentiality principles and undermines the integrity of the entire database ecosystem by exposing internal state that should remain isolated within secure boundaries.
This vulnerability is particularly dangerous because it can be exploited remotely if an attacker has access to a service endpoint that allows table imports or data ingestion via standard SQL interfaces. The attack complexity remains relatively low as it primarily requires constructing specific binary payloads rather than exploiting complex logic flaws in application code layers above the database engine. Consequently, this issue maps closely to MITRE ATT&CK techniques related to unauthorized acquisition of sensitive information and potential exploitation for privilege escalation if combined with other vulnerabilities within the same environment.
To mitigate these risks, organizations running affected versions must immediately upgrade their MariaDB installations to patched releases including version 10.6.28 or later in the 10.6 branch, as well as corresponding updates for branches 10.11 (version 10.11.19), 11.4 (version 11.4.13), 11.8 (version 11.8.9), 12.3 (version 12.3.3), and 13.0 (version 13.0.2). These updates contain the necessary code changes to enforce strict validation of binary JSON structures before processing, ensuring that any malformed data triggers a controlled error response rather than proceeding with unsafe memory operations. Additionally, administrators should implement network-level access controls to restrict who can perform table imports and ensure that all input sources are trusted or sanitized prior to ingestion into the database system. Regular patch management cycles and monitoring for unusual server crashes or performance anomalies related to JSON processing functions are recommended defensive measures while transitioning to secure versions.