MariaDB Connector/J: LOAD DATA LOCAL INFILE file check could be satisfied by text inside quoted identifiers, letting a malicious server read client filesGHSA-fhx5-2xqw-2cgm
MEDIUMFix: mariadb-corporation/mariadb-connector-j@4d2f800GHSA-fhx5-2xqw-2cgm is a medium-severity (CVSS 5.9) Improper Input Validation vulnerability in org.mariadb.jdbc:mariadb-java-client. A fix is available for org.mariadb.jdbc:mariadb-java-client — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-fhx5-2xqw-2cgm by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.mariadb.jdbc:mariadb-java-client☕org.mariadb.jdbc:mariadb-java-client☕org.mariadb.jdbc:mariadb-java-clientReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.mariadb.jdbc:mariadb-java-client | ≥ 3.0.0&&< 3.3.7 | 3.3.7org.mariadb.jdbc:mariadb-java-client:3.3.7 |
| ☕Maven | org.mariadb.jdbc:mariadb-java-client | ≥ 3.4.0&&< 3.4.5 | 3.4.5org.mariadb.jdbc:mariadb-java-client:3.4.5 |
| ☕Maven | org.mariadb.jdbc:mariadb-java-client | ≥ 3.5.0&&< 3.5.11 | 3.5.11org.mariadb.jdbc:mariadb-java-client:3.5.11 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.mariadb.jdbc:mariadb-java-client, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.mariadb.jdbc:mariadb-java-client to 3.3.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fhx5-2xqw-2cgm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-fhx5-2xqw-2cgm in your dependencies?
Find it across Maven, including transitive dependencies.