
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 2.7.14
Patched in 2.7.14
Vulnerable: >= 3.0.0, < 3.3.5
Patched in 3.3.5
Vulnerable: >= 3.4.0, < 3.4.3
Patched in 3.4.3
Vulnerable: >= 3.5.0, < 3.5.9
Patched in 3.5.9
Details
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.
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:
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.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.
Reported by tharavel
EPSS, exploit probability
Low0.37%
estimated chance of real-world exploitation in the next 30 days, higher than 30.5% of every CVE FIRST.org scores
Refreshed 11/2/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.