GHSA-fhx5-2xqw-2cgm: MariaDB Connector/J: LOAD DATA LOCAL INFILE file check could be satisfied by text inside quoted identifiers, letting a malicious server read client files

Published Oct 29, 2026
·
Updated

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 [LOWPRIORITY|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

Other sources

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.

— OSV

Affected Software

3 affected componentsFixes available
maven/org.mariadb.jdbc:mariadb-java-client>=3.5.0<3.5.11
3.5.11
maven/org.mariadb.jdbc:mariadb-java-client>=3.4.0<3.4.5
3.4.5
maven/org.mariadb.jdbc:mariadb-java-client>=3.0.0<3.3.7
3.3.7

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/org.mariadb.jdbc:mariadb-java-client to a version that resolves this vulnerability.

    Fixed in 3.5.11
  2. Upgrade

    Upgrade maven/org.mariadb.jdbc:mariadb-java-client to a version that resolves this vulnerability.

    Fixed in 3.4.5
  3. Upgrade

    Upgrade maven/org.mariadb.jdbc:mariadb-java-client to a version that resolves this vulnerability.

    Fixed in 3.3.7
  4. Upgrade

    Upgrade MariaDB Connector/J to a version that resolves this vulnerability.

    Fixed in 3.3.7
  5. Upgrade

    Upgrade MariaDB Connector/J to a version that resolves this vulnerability.

    Fixed in 3.4.5
  6. Upgrade

    Upgrade MariaDB Connector/J to a version that resolves this vulnerability.

    Fixed in 3.5.11
  7. Configuration

    Set allowLocalInfile=false when LOAD DATA LOCAL INFILE is not needed.

    MariaDB Connector/J allowLocalInfile = false

Event History

Oct 29, 2026
CVE Published
via OSV·08:45 PM
Data Sourced
via OSV·08:45 PM
DescriptionSeverityWeakness
Oct 30, 2026
Advisory Published
via GitHub·10:59 PM
Data Sourced
via GitHub·10:59 PM
DescriptionSeverityWeaknessAffected Software
Data Sourced
via OSV·10:59 PM
Affected Software

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203