GHSA-wxmm-q36w-r9xj MariaDB Connector/J does not enforce allowLocalInfile=false on server-initiated LOCAL INFILE requests

• Maven org.mariadb.jdbc:mariadb-java-client: < 2.7.14 → fixed in 2.7.14 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.0.0, < 3.3.5 → fixed in 3.3.5 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.4.0, < 3.4.3 → fixed in 3.4.3 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.5.0, < 3.5.9 → fixed in 3.5.9

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 COM_QUERY. 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