CVE-2026-119279

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-119279) has been identified in the protocol packet decoding of MariaDB Connector/J, which allows attackers who control or intercept the database server side of a connection to crash the client's connection handling or force oversized memory allocations. The driver narrows 8-byte length-encoded integers received from the server to a Java int without checking that the value fits, so a large value becomes a negative or arbitrary length.

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.10
• 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 Medium-severity vulnerability is found in the org.mariadb.jdbc:mariadb-java-client package in multiple versions of MariaDB Connector/J.

The MariaDB client/server protocol encodes string and field lengths as length-encoded integers. A first byte of 0xFE (254) means that the length follows as an unsigned 8-byte integer. The driver's buffer reader decodes these values in readIntLengthEncodedNotNull() and readLength(), and for the 8-byte form both methods cast the 64-bit value straight to an int:

public int readIntLengthEncodedNotNull() {
  int type = (buf[pos++] & 0xff);
  if (type < 251) return type;
  switch (type) {
    case 252:
      return readUnsignedShort();
    case 253:
      return readUnsignedMedium();
    case 254:
      return (int) readLong();
    default:
      return type;
  }
}

public Integer readLength() {
  int type = readUnsignedByte();
  switch (type) {
    case 251:
      return null;
    case 252:
      return readUnsignedShort();
    case 253:
      return readUnsignedMedium();
    case 254:
      return (int) readLong();
    default:
      return type;
  }
}

The cast keeps only the low 32 bits. Any value above Integer.MAX_VALUE therefore wraps to a negative or unrelated int. Neither method rejects it, so the wrapped value goes back to the callers that decode column definitions, OK packets with session-tracking data, and other server responses. Those callers use it directly as a length, for example to advance the read position or to build a string:

public String readString(int length) {
  pos += length;
  return new String(buf, pos - length, length, StandardCharsets.UTF_8);
}

A malicious or compromised server, or a machine-in-the-middle attacker, can put a crafted 8-byte length in a response packet. The resulting negative or oversized length makes the client throw unchecked exceptions such as NegativeArraySizeException or out-of-bounds errors in connection handling, or makes it attempt oversized allocations. The impact is on availability only: exploitation requires control of the server side of the connection, and the flaw does not expose or modify data.

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)