CVE-2026-119210

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.

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.

Summary

MariaDB Connector/J checked a server's LOAD DATA LOCAL INFILE file request by searching the text of the command it had sent for LOAD DATA LOCAL INFILE '<file>'. The search also matched inside quoted identifiers, string literals and comments, so text returned by the server and re-used in a later query could satisfy it. A rogue or MitM server can read any file the client JVM can read.

Details

When a server answers a command with a LOCAL INFILE request (0xFB packet), the connector opens the named file on the client host and streams it to the server, after verifying that the file corresponds to a LOAD DATA LOCAL INFILE of the command it sent (ClientMessage.validateLocalFileName()). That verification was a regular expression whose prefix accepted any character, so it answered "does the text appear anywhere in the SQL", including inside a backtick-quoted identifier.

Several driver paths put identifiers returned by the server straight back into their next query: DatabaseMetaData.getImportedKeys() and getExportedKeys() re-use database and table names from SHOW DATABASES, SHOW TABLES and the REFERENCES clause of SHOW CREATE TABLE output, and updatable result sets build their UPDATE and refresh SELECT from the schema and table names of the column definition packets. A server returning an identifier such as LOAD DATA LOCAL INFILE '/etc/passwd' makes the connector send SHOW CREATE TABLE `LOAD DATA LOCAL INFILE '/etc/passwd'`.`accounts` ; the server answers it with a LOCAL INFILE request for /etc/passwd, the check passes, and the file content is sent. On the getImportedKeys() path the resulting error is swallowed and the application observes nothing. The same applies to an application that interpolates identifiers obtained from the server into its own queries.

The fix parses the command instead of searching it: string literals, quoted identifiers and comments are skipped, statements are split on ;, and only a LOAD DATA|XML [LOW_PRIORITY|CONCURRENT] LOCAL INFILE found at the start of a statement is considered, its file literal or bound parameter being compared exactly to the requested file.

Impact

Confidentiality: a malicious or compromised server, or a MitM, can read arbitrary files from the host running the JDBC client (application configuration, credential files, key stores, ...) through standard java.sql calls such as DatabaseMetaData.getImportedKeys(), getExportedKeys() or ResultSet.updateRow(). Exploitation requires control of the server side of the connection and allowLocalInfile enabled (the default). Setting allowLocalInfile=false is a workaround when LOAD DATA LOCAL INFILE is not needed. No integrity or availability impact.

Credit

Reported by buxuwa (buxu) through HackerOne

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.

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.

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.

Summary

MariaDB Connector/J checked a server's LOAD DATA LOCAL INFILE file request by searching the text of the command it had sent for LOAD DATA LOCAL INFILE '<file>'. The search also matched inside quoted identifiers, string literals and comments, so text returned by the server and re-used in a later query could satisfy it. A rogue or MitM server can read any file the client JVM can read.

Details

When a server answers a command with a LOCAL INFILE request (0xFB packet), the connector opens the named file on the client host and streams it to the server, after verifying that the file corresponds to a LOAD DATA LOCAL INFILE of the command it sent (ClientMessage.validateLocalFileName()). That verification was a regular expression whose prefix accepted any character, so it answered "does the text appear anywhere in the SQL", including inside a backtick-quoted identifier.

Several driver paths put identifiers returned by the server straight back into their next query: DatabaseMetaData.getImportedKeys() and getExportedKeys() re-use database and table names from SHOW DATABASES, SHOW TABLES and the REFERENCES clause of SHOW CREATE TABLE output, and updatable result sets build their UPDATE and refresh SELECT from the schema and table names of the column definition packets. A server returning an identifier such as LOAD DATA LOCAL INFILE '/etc/passwd' makes the connector send SHOW CREATE TABLE `LOAD DATA LOCAL INFILE '/etc/passwd'`.`accounts` ; the server answers it with a LOCAL INFILE request for /etc/passwd, the check passes, and the file content is sent. On the getImportedKeys() path the resulting error is swallowed and the application observes nothing. The same applies to an application that interpolates identifiers obtained from the server into its own queries.

The fix parses the command instead of searching it: string literals, quoted identifiers and comments are skipped, statements are split on ;, and only a LOAD DATA|XML [LOW_PRIORITY|CONCURRENT] LOCAL INFILE found at the start of a statement is considered, its file literal or bound parameter being compared exactly to the requested file.

Impact

Confidentiality: a malicious or compromised server, or a MitM, can read arbitrary files from the host running the JDBC client (application configuration, credential files, key stores, ...) through standard java.sql calls such as DatabaseMetaData.getImportedKeys(), getExportedKeys() or ResultSet.updateRow(). Exploitation requires control of the server side of the connection and allowLocalInfile enabled (the default). Setting allowLocalInfile=false is a workaround when LOAD DATA LOCAL INFILE is not needed. No integrity or availability impact.

Credit

Reported by buxuwa (buxu) through HackerOne

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.

These are all security issues fixed in the mariadb-java-client-3.5.11-1.1 package on the GA media of openSUSE Tumbleweed.