GHSA-wxmm-q36w-r9xj: Low severity maven/org.mariadb.jdbc:mariadb-java-client vulnerability

Published Sep 17, 2026
·
Updated

Summary

MariaDB Connector/J does not enforce allowLocalInfile=false when processing server-initiated LOCAL INFILE requests (protocol packet type 0xfb). However, exploitation is constrained: the server can only request the exact filename the client already included in its LOAD DATA LOCAL INFILE query, it cannot redirect to arbitrary paths.

Details

When a client executes LOAD DATA LOCAL INFILE '/path/to/file', the connector sends the filename to the server as part of the COMQUERY. A rogue or MitM server responds with a 0xfb packet echoing that same filename. The connector, without checking allowLocalInfile, transmits the file content.

The bypass is therefore limited to the file the application itself intended to load. The attacker cannot escalate to other files (e.g. /etc/passwd) unless the application's own query targets them.

The real-world risk is: - An application that uses LOAD DATA LOCAL INFILE on potentially sensitive files (credentials, exports, configs) and connects over an untrusted network. - allowLocalInfile=false is supposed to disable this entire mechanism as a defense-in-depth measure, but the flag is ignored.

Impact

The security guarantee of allowLocalInfile=false is not upheld, but practical exploitation requires both a MitM/rogue server and an application that actively uses LOCAL INFILE on sensitive data.

Credit

Reported by tharavel

Affected Software

4 affected componentsFixes available
maven/org.mariadb.jdbc:mariadb-java-client>=3.5.0<3.5.9
3.5.9
maven/org.mariadb.jdbc:mariadb-java-client>=3.4.0<3.4.3
3.4.3
maven/org.mariadb.jdbc:mariadb-java-client>=3.0.0<3.3.5
3.3.5
maven/org.mariadb.jdbc:mariadb-java-client<2.7.14
2.7.14

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.9
  2. Upgrade

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

    Fixed in 3.4.3
  3. Upgrade

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

    Fixed in 3.3.5
  4. Upgrade

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

    Fixed in 2.7.14

Event History

Sep 17, 2026
Advisory Published
via GitHub·04:29 PM
Data Sourced
via GitHub·04:29 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are realistically exposed?

Applications using MariaDB Connector/J that execute LOAD DATA LOCAL INFILE against potentially sensitive local files and connect to an untrusted, rogue, or man-in-the-middle server are exposed. The server can obtain only the file path that the application already supplied in its own query.

2

What does an attacker need to exploit this issue?

An attacker must be able to act as the database server or intercept the connection and return a server-initiated LOCAL INFILE request using protocol packet type 0xfb. The application must already have issued a LOAD DATA LOCAL INFILE query for the file the attacker wants read.

3

Does setting allowLocalInfile=false prevent the affected behavior?

No. The connector does not enforce allowLocalInfile=false when it processes the server-initiated LOCAL INFILE request, so the file named in the application's query can still be transmitted.

4

Can the attacker use this to read arbitrary client files?

No. The request is limited to the exact filename already included by the client in its LOAD DATA LOCAL INFILE query. It cannot be redirected to another path unless the application itself targets that path.

5

What can be done if updating is not immediately possible?

Avoid using LOAD DATA LOCAL INFILE for sensitive files and avoid connecting to untrusted servers or networks where a rogue server or man-in-the-middle could respond to the query. The affected setting should not be relied upon as a defense against this behavior.

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