MariaDB Connector/J: Length-encoded integers larger than Integer.MAX_VALUE were truncated before being used as lengthsGHSA-797x-p4mc-jwpm
MEDIUMFix: mariadb-corporation/mariadb-connector-j@30d4a88GHSA-797x-p4mc-jwpm is a medium-severity (CVSS 5.9) CWE-130 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-797x-p4mc-jwpm 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 narrowed 8-byte length-encoded integers received from the
server to int without validation. A rogue or MitM server can send a value above
Integer.MAX_VALUE whose truncation becomes a negative or arbitrary length.
Details
The protocol encodes lengths as length-encoded integers, whose 8-byte form the
decoder (readLength() and readIntLengthEncodedNotNull()) returned as
(int) readLong(). A value above Integer.MAX_VALUE therefore wrapped to a
negative or unrelated int, used afterwards as a length to size allocations or
reads, which ended in NegativeArraySizeException, out-of-bounds exceptions or
oversized allocations.
The fix rejects any length-encoded value that does not fit a non-negative int
with an explicit error.
Impact
Availability only: a malicious or compromised server, or a MitM, can crash the client's connection handling with unchecked exceptions or drive oversized allocations. Exploitation requires control of the server side of the connection; no authentication bypass, confidentiality or integrity impact.
Credit
Reported by fg0x0
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.10 | 3.5.10org.mariadb.jdbc:mariadb-java-client:3.5.10 |
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-797x-p4mc-jwpm is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is GHSA-797x-p4mc-jwpm in your dependencies?
Find it across Maven, including transitive dependencies.