CVE-2026-119277

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-119277) has been identified in the packet decoders of MariaDB Connector/J, which allows a rogue or compromised database server, or a man-in-the-middle, to make the client read past the end of a packet through lengths the server declares. The out-of-bounds reads surface as unchecked runtime exceptions inside JDBC calls instead of a SQLException, breaking the client's connection handling.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

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 Medium-severity vulnerability is found in the org.mariadb.jdbc:mariadb-java-client package in multiple versions of MariaDB Connector/J. Several packets the server sends to the driver carry length fields that tell the decoder how many bytes to read next: the session-state block of an OK packet, the extended metadata of a column definition packet, and each field of a text or binary result row. The decoders trust those lengths and never check them against the bytes actually left in the packet.

The low-level buffer reads move the read position by the declared length and then decode from the backing array, and readLengthBuffer() copies a declared number of bytes into a new sub-buffer:

public void skip(int length) {
  pos += length;
}

public StandardReadableByteBuf readLengthBuffer() {
  int len = this.readIntLengthEncodedNotNull();
  byte[] tmp = new byte[len];
  readBytes(tmp);
  return new StandardReadableByteBuf(tmp, len);
}

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

The OK packet parser feeds server-declared lengths straight into these reads when session tracking is enabled:

case StateChange.SESSION_TRACK_SYSTEM_VARIABLES:
  buf.readIntLengthEncodedNotNull();
  String variable = buf.readString(buf.readIntLengthEncodedNotNull());
  Integer len = buf.readLength();
  String value = len == null ? null : buf.readString(len);
  ...
default:
  buf.skip(buf.readIntLengthEncodedNotNull());

The column definition decoder reads extended type metadata the same way (subPacket.readAscii(subPacket.readLength()) and subPacket.skip(subPacket.readLength())), and the row decoders' setPosition() returns the length-encoded field length from the row packet without comparing it to rowBuf.readableBytes(), so later field reads use it as is.

A rogue server, or an attacker who can tamper with an unencrypted connection, can send a packet whose declared length exceeds the remaining bytes. The driver then reads outside the packet buffer and throws ArrayIndexOutOfBoundsException, StringIndexOutOfBoundsException or IllegalArgumentException from inside JDBC calls such as executing a statement or reading a result set. Applications expect a SQLException from JDBC and usually do not handle these unchecked exceptions, so the client's connection handling fails. The impact is limited to availability: exploitation needs control of the server side of the connection, and the advisory reports no confidentiality or integrity impact.

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)