CVE-2026-119279: MariaDB Connector/J: Length-encoded integers larger than Integer.MAX_VALUE were truncated before being used as lengths
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.MAXVALUE 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.MAXVALUE 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
Other sources
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.10, the ReadableByteBuf.readLength() and ReadableByteBuf.readIntLengthEncodedNotNull() methods narrowed the protocol's unsigned 8-byte length-encoded integer to a Java int without checking that the value fit a non-negative integer. Values above Integer.MAXVALUE could wrap to a negative or unrelated length that downstream allocation and read paths used. A malicious or compromised server, or a machine-in-the-middle attacker, could trigger NegativeArraySizeException, out-of-bounds failures, or oversized allocation behavior in client connection handling. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.10.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/mariadb-connector-javato a version that resolves this vulnerability.Fixed in 3.5.10-1 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.5.10 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.4.5 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.3.7 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.3.7 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.4.5 - Upgrade
Upgrade
MariaDB Connector/Jto a version that resolves this vulnerability.Fixed in 3.5.10
Event History
Frequently Asked Questions
Which deployments should be prioritized for remediation?
Prioritize Java applications using MariaDB Connector/J that connect to servers which could be malicious or compromised, or whose network path could be intercepted by a man-in-the-middle attacker. The affected connector is used with both MariaDB and MySQL connections.
What access does an attacker need, and what is the expected impact?
An attacker must control the server side of the database connection or act as a man-in-the-middle; no client authentication bypass is involved. The impact is availability only, including crashes in connection handling or oversized allocations, with no stated confidentiality or integrity impact.