CVE-2026-92262 in Server
Summary
by MITRE • 10/16/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 #mysql50# bypass prefix is affected because it allows the #mysql50# prefix to bypass normal table-name filesystem encoding. An attacker can trigger the issue with a table name using the #mysql50# prefix, then use a #mysql50# table name to access files under their legacy unencoded name and cause crashes, data corruption, data exfiltration, or remote code execution. 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/16/2026
MariaDB server is a widely deployed community-developed fork of the MySQL database management system, known for its high performance and robust feature set. In versions ranging from 10.6.1 up to but not including 10.6.28, as well as in branches 10.11 through 13.0 prior to their respective patch releases, a critical security flaw exists within the handling of table name prefixes. Specifically, the #mysql50# prefix mechanism, which is designed for legacy compatibility and internal system operations, contains an encoding bypass vulnerability. This defect allows an attacker who has sufficient privileges to create or manipulate tables to circumvent normal filesystem encoding rules applied by the database engine when mapping logical table names to physical files on disk.
The technical root cause of this vulnerability lies in how MariaDB processes identifiers that begin with the #mysql50# sequence. Normally, the server applies specific encoding and sanitization routines to ensure that file paths generated from SQL object names are safe and conform to operating system constraints. However, when the #mysql50# prefix is utilized, these safeguards are bypassed, allowing the underlying unencoded name of the table to be used directly in filesystem operations. This discrepancy creates a path traversal-like condition where an attacker can specify file paths that deviate from expected directory structures or contain characters that should have been escaped or sanitized by the standard encoding logic.
The operational impact of this flaw is severe and multifaceted, primarily affecting data integrity and system availability. By exploiting this bypass, an authenticated attacker with CREATE TABLE privileges can cause the database server to crash due to invalid file operations, leading to a denial of service against all users relying on the instance. More critically, the ability to access files under their legacy unencoded names opens avenues for significant security breaches. An adversary could potentially read sensitive data from other databases or configuration files if they fall within accessible paths, resulting in unauthorized data exfiltration. In scenarios where file write operations are possible and combined with other vulnerabilities such as command injection through specific storage engines or server configurations, this flaw can escalate to remote code execution on the host system hosting the database service.
This vulnerability is categorized under CWE-20 Improper Input Validation within the Common Weakness Enumeration framework, specifically relating to the failure to properly sanitize special elements when they are used in file paths. From a tactical perspective, it aligns with ATT&CK techniques related to Data from Local System and potentially Command and Scripting Interpreter if exploited for code execution. The flaw highlights the risks associated with legacy compatibility features that may not receive rigorous security scrutiny compared to modern API endpoints or query parsers.
To mitigate this risk, organizations running affected versions of MariaDB must immediately upgrade to patched releases. For the 10.6 series, version 10.6.28 and later are required; for 10.11, version 10.11.19 or higher is necessary; similarly, updates to 11.4.13, 11.8.9, 12.3.3, and 13.0.2 respectively resolve the issue. Until upgrades are performed, administrators should enforce strict least-privilege access controls, ensuring that only trusted users with administrative privileges can create tables or modify schema structures. Additionally, monitoring for unusual file system activity around database data directories can help detect exploitation attempts in real-time. Regular patch management and adherence to vendor security advisories remain the most effective defense against such structural vulnerabilities in database software.