CVE-2026-119276

About vulnerability

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 CLIENT_SESSION_TRACK 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

Affected product:

MariaDB , Spring , debezium , hapi-fhir , pulsar

Affected packages:

MariaDB @ 3.5.8 (+1044 more)