CVE-2026-119276: MariaDB Connector/J: Rogue server can drive large heap allocations from server-declared lengths in OK packets
Summary
MariaDB Connector/J sized heap allocations from lengths declared by the server in OK packets before checking that those lengths fit in the packet. A rogue or MitM server can make the client allocate megabytes from a packet of a few bytes.
Details
When CLIENTSESSIONTRACK is negotiated (the default), an OK packet carries an info field followed by session-state blocks, each tracked variable being sent as a length-encoded name and value. OkPacket.parse() and parseWithInfo() allocated new byte[len] for the info field, the variable name and the value with the server-declared len, then copied the packet data into it. The copy failed with an ArrayIndexOutOfBoundsException when the packet was shorter, but only after the allocation had taken place.
A server-declared length of 8 MiB in an 18-byte packet was enough to trigger an 8 MiB allocation; the integer-range validation of length-encoded values does not help, since such lengths are valid positive integers.
The fix validates every server-declared length against the remaining packet bytes before any allocation (ReadableByteBuf.checkLength() and a bounded readBytes(int)), and stops reading the session state at the first inconsistent entry.
Impact
Availability only: a malicious or compromised server, or a MitM, can drive attacker-controlled heap allocations on every OK packet, creating GC pressure up to OutOfMemoryError in the client application. 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.11, when CLIENTSESSIONTRACK was negotiated, the OkPacket.parse() and OkPacket.parseWithInfo() paths allocated byte arrays using server-declared lengths for the OK packet info field and session-state variable names and values before confirming that the bytes remained in the packet. A malicious or compromised server, or a machine-in-the-middle attacker, could send a small OK packet declaring a much larger length and repeatedly force attacker-controlled heap allocations before the subsequent copy failed. This could create garbage-collection pressure or an OutOfMemoryError in the client application. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.5.11 - 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.11
Event History
Frequently Asked Questions
Are clients using the default Connector/J protocol settings affected?
Yes. CLIENT_SESSION_TRACK is negotiated by default, which enables parsing of the OK-packet session-state fields involved in this issue.
What would an attacker need to exploit this?
The attacker would need to act as a rogue database server or be able to modify server responses in transit. No client privileges or user interaction are required.
What is the practical impact on an affected client?
A maliciously short OK packet can cause the client to allocate megabytes of heap memory based on a server-declared length before parsing fails. Repeated malicious responses could therefore exhaust client memory and cause a denial of service.