CVE-2026-119280

Overview

MariaDB Connector/J is MariaDB's JDBC driver: a JDBC 4.2 compatible driver used to connect applications developed in Java to MariaDB and MySQL databases. It is published to Maven Central as org.mariadb.jdbc:mariadb-java-client, and Spring Boot 2.7.18 manages its 3.1.4 release.

A denial of service vulnerability (CVE-2026-119280) has been identified in the XA transaction recovery of MariaDB Connector/J, which allows attackers who control the server side of the connection, such as a malicious or compromised database server or a machine-in-the-middle, to crash XA recovery or force the client into very large memory allocations.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of MariaDB Connector/J.

Details

Module Info

• Product: MariaDB Connector/J
• Affected packages: org.mariadb.jdbc:mariadb-java-client
• Affected versions: >=3.0.0 <3.3.7, >=3.4.0 <3.4.5, >=3.5.0 <3.5.11
• GitHub repository: https://github.com/mariadb-corporation/mariadb-connector-j
• Published packages: https://central.sonatype.com/artifact/org.mariadb.jdbc/mariadb-java-client
• Package manager: Maven
• Fixed in:
  • OSS MariaDB Connector/J 3.3.7, 3.4.5, 3.5.11
  • NES for MariaDB Connector/J v3.1.7

Vulnerability Info

This Low-severity vulnerability is found in the org.mariadb.jdbc:mariadb-java-client package in multiple versions of MariaDB Connector/J.

A transaction manager recovering in-doubt distributed transactions calls XAResource.recover() on the driver's XAResource. Every XAConnection the driver hands out is a MariaDbPoolConnection, whether it comes from MariaDbDataSource or MariaDbPoolDataSource. The driver runs XA RECOVER and rebuilds each Xid from the returned row: the gtrid_length and bqual_length columns give the sizes of the global transaction id and the branch qualifier, and the data column holds both concatenated. The driver uses the two lengths exactly as the server sends them:

ResultSet rs = connection.createStatement().executeQuery("XA RECOVER");
ArrayList<MariaDbXid> xidList = new ArrayList<>();
while (rs.next()) {
  int formatId = rs.getInt(1);
  int len1 = rs.getInt(2);
  int len2 = rs.getInt(3);
  byte[] arr = rs.getBytes(4);
  byte[] globalTransactionId = new byte[len1];
  byte[] branchQualifier = new byte[len2];
  System.arraycopy(arr, 0, globalTransactionId, 0, len1);
  System.arraycopy(arr, len1, branchQualifier, 0, len2);
  xidList.add(new MariaDbXid(formatId, globalTransactionId, branchQualifier));
}

Neither length is checked against the XA specification bounds (Xid.MAXGTRIDSIZE and Xid.MAXBQUALSIZE, 64 bytes each) or against the size of the data payload. A server that returns a negative length makes new byte[len1] throw NegativeArraySizeException; lengths that do not fit the payload make System.arraycopy throw ArrayIndexOutOfBoundsException; and a length near Integer.MAX_VALUE makes the client try to allocate a byte array of up to 2 GB for a single row, which can exhaust the heap. recover() only maps SQLException to XAException, so these unchecked exceptions escape it and abort the transaction manager's recovery pass. Exploitation requires control of the server side of the connection, and only applications that run XA recovery through the driver's XA connections are exposed. The impact is limited to availability.

Mitigation

MariaDB plc's Engineering Policy lists MariaDB Connector/J 2.7, 3.3, 3.4 and 3.5 as its supported release series. Upstream has made no 3.1.x release since 3.1.4 (April 2023), so no 3.1.x release is available to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a currently supported release of MariaDB Connector/J that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• fg0x0 (finder)