CVE-2026-119276 — Vulnerability intelligence
mariadb-corporation — org.mariadb.jdbc:mariadb-java-client, org.mariadb.jdbc:mariadb-java-client, org.mariadb.jdbc:mariadb-java-client
Published:
- CVSS
- 5.9
- CISA KEV
- Not listed; not proof of no exploitation
Original source text (not a translation)
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 `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