CVE-2026-119280: MariaDB Connector/J: XA recover() trusted server-supplied gtrid and bqual lengths
Summary
XAResource.recover() in MariaDB Connector/J trusted the gtridlength and bquallength columns returned by XA RECOVER to allocate and split each Xid.
Details
MariaDbPoolConnection and MariaDbPoolPinnedConnection built each Xid of the recovery list by allocating new byte[gtridlength] and new byte[bquallength] and copying from the data column, without validating the lengths against the XA specification bounds (Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE) or the actual payload. Negative or oversized lengths, or lengths that do not fit the data, ended in large allocations or unchecked exceptions (NegativeArraySizeException, ArrayIndexOutOfBoundsException) during recovery.
The fix validates the lengths before any allocation or copy and reports an invalid row as an XAException (XAERRMFAIL).
Impact
Availability only, and limited to applications running XA recovery: a malicious or compromised server, or a MitM, can crash the recovery or drive large allocations. Exploitation requires control of the server side of the connection.
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, the MariaDbPoolConnection.recover() and MariaDbPoolPinnedConnection.recover() implementations trusted the gtridlength and bquallength columns returned by XA RECOVER. The methods allocated and split Xid byte arrays without validating the lengths against Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE, or the actual data payload. A malicious or compromised server, or a machine-in-the-middle attacker, could cause large allocations, NegativeArraySizeException, or ArrayIndexOutOfBoundsException during XA recovery. 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
Which deployments are exposed to this issue?
Only applications that run XA recovery through MariaDB Connector/J are affected. Applications that do not invoke XA recovery are not exposed through this code path.
What must an attacker control to trigger the failure?
The attacker must control the server side of the connection, such as through a malicious or compromised server, or be able to act as a man-in-the-middle. They can return malformed XA RECOVER rows with invalid transaction identifier lengths.
What is the practical impact on an affected application?
The issue affects availability only. XA recovery can crash with exceptions such as NegativeArraySizeException or ArrayIndexOutOfBoundsException, or it can be driven to make large memory allocations.
How can operators identify a possible occurrence?
Investigate failures during XA recovery, particularly NegativeArraySizeException or ArrayIndexOutOfBoundsException while processing Xid recovery data. Such failures may indicate that returned gtrid or bqual lengths were negative, oversized, or inconsistent with the payload.
How does the fix handle malformed recovery records?
The fix validates the returned lengths against XA bounds and the actual payload before allocating or copying data. Invalid rows are reported as an XAException with XAER_RMFAIL instead of causing unchecked exceptions or large allocations.