CVE-2026-61700: MariaDB Connector/J does not enforce allowLocalInfile=false on server-initiated LOCAL INFILE requests
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
Other sources
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, ClientMessage.readPacket processes a server-initiated LOCAL INFILE protocol packet 0xfb without enforcing allowLocalInfile=false. When an application sends a LOAD DATA LOCAL INFILE COMQUERY, a rogue or man-in-the-middle server can echo the same filename and cause the connector to transmit that file despite the disabled option. The server cannot redirect the request to an arbitrary path and can receive only the exact file already selected by the application, so exploitation requires an application that actively loads sensitive data over an untrusted connection. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.5.9 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.4.3 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.3.5 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 2.7.14 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 2.7.14 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.3.5 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.4.3 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.5.9
Event History
Frequently Asked Questions
Which applications are realistically exposed to this issue?
Exposure requires a Java application using an affected MariaDB Connector/J version that sends a LOAD DATA LOCAL INFILE query and does so over an untrusted connection to a rogue or man-in-the-middle server. Applications that do not use LOAD DATA LOCAL INFILE are not exposed through this behavior.
Does setting allowLocalInfile=false prevent exploitation?
Not in the affected versions for this server-initiated request path. A rogue or man-in-the-middle server can echo the filename from the application's LOAD DATA LOCAL INFILE request and receive that selected file despite the option being disabled.
Can an attacker use this to read arbitrary files from the client host?
No. The server cannot redirect the request to a different path; it can receive only the exact file path already selected by the application.
What should be done if an immediate upgrade is not possible?
Avoid sending LOAD DATA LOCAL INFILE requests containing sensitive local data over untrusted connections. The issue is fixed in Connector/J versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.