CVE-2026-119210

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