CVE-2026-119210 in MariaDB Connector
Summary
by MITRE • 10/29/2026
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the ClientMessage.validateLocalFileName() check used a regular expression that could match LOAD DATA LOCAL INFILE text inside quoted identifiers, string literals, or comments instead of requiring a real statement. A malicious or compromised server, or a machine-in-the-middle attacker, could return crafted database or table identifiers that the connector reused in metadata or updatable-result queries, then answer with a LOCAL INFILE request for a client file. With allowLocalInfile enabled, this caused the connector to stream any readable client-host file named by the crafted text, including through DatabaseMetaData.getImportedKeys(), DatabaseMetaData.getExportedKeys(), or ResultSet.updateRow() paths. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified within MariaDB Connector/J affects Java-based applications that interface with MariaDB and MySQL databases using connector versions ranging from 3.0.0 up to specific patched releases including 3.3.7, 3.4.5, and 3.5.11. This security flaw resides in the ClientMessage.validateLocalFileName method, which is responsible for validating requests related to the LOAD DATA LOCAL INFILE functionality. The core technical deficiency lies in the regular expression used by this validation mechanism, which fails to strictly distinguish between actual SQL statements containing the LOAD DATA LOCAL INFILE command and instances where such text appears within quoted identifiers, string literals, or comments. This lack of strict contextual parsing allows a malicious actor to exploit the parser's permissiveness by crafting database or table names that mimic valid load commands when embedded in metadata queries or result set operations.
The operational impact of this vulnerability is severe, particularly for environments where the allowLocalInfile configuration option is enabled on either the client connector or the server side. An attacker who controls a compromised MariaDB or MySQL server, or one positioned as a man-in-the-middle capable of intercepting and modifying traffic, can exploit this flaw to force the Java application into an unintended state. By returning crafted identifiers that trigger the flawed validation logic, the attacker causes the connector to initiate a LOCAL INFILE request aimed at reading files from the client host machine. This effectively turns the database connection into a vector for arbitrary file read attacks, allowing sensitive data residing on the application server or client workstation to be exfiltrated through standard database communication channels.
The attack surface is broadened by the specific API methods susceptible to this exploitation path. The vulnerability can be triggered not only through direct SQL execution but also via metadata retrieval functions such as DatabaseMetaData.getImportedKeys and DatabaseMetaData.getExportedKeys, which query schema information about foreign key relationships. Additionally, operations involving ResultSet.updateRow are affected, meaning that even routine data manipulation tasks could inadvertently trigger the file read mechanism if the underlying database response contains the crafted malicious identifiers. This highlights a significant deviation from secure coding practices regarding input validation and context-aware parsing of SQL constructs within JDBC drivers.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the connector fails to adequately sanitize or validate user-controlled data derived from server responses before processing it for file operations. It also relates to CWE-94 Improper Control of Generation of Code (Code Injection) in the context of how the driver interprets string content as executable commands rather than literal strings. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1005 Data from Local System Retrieval, where an adversary uses installed software to gather data directly from a local system without executing native tools or scripts on the target machine.
To mitigate this risk, organizations must ensure that all instances of MariaDB Connector/J are upgraded to version 3.3.7, 3.4.5, or 3.5.11 and later, where the validation logic has been corrected to strictly enforce context boundaries for SQL keywords. Furthermore, security best practices dictate disabling allowLocalInfile unless absolutely necessary for specific data import operations, as this setting is a primary enabler of such file read vulnerabilities. Network-level protections should also be implemented to prevent man-in-the-middle attacks that could inject malicious metadata into database traffic streams. Regular auditing of JDBC configurations and dependency management processes are essential to maintain the integrity of application-to-database communication channels against these types of parser-based exploits.