CVE-2026-60624

Overview

MySQL Connector/J is the official JDBC Type 4 driver for MySQL, developed and released by the MySQL team at Oracle. It lets Java applications connect to and query MySQL servers over JDBC, and also implements the X DevAPI for document-store access. It is distributed as the Maven artifact com.mysql:mysql-connector-j and is a standard dependency in Java applications that talk to MySQL.

A denial of service vulnerability (CVE-2026-60624) has been identified in the X Protocol message reader of MySQL Connector/J, which allows attackers who control or impersonate the MySQL server a client connects to over X Protocol to make the client application exhaust its memory or crash. The client trusts the frame length the server sends and allocates a buffer of that size without checking it.

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 MySQL Connector/J.

Details

Module Info

• Product: MySQL Connector/J
• Affected packages: com.mysql:mysql-connector-j
• Affected versions: >=9.7.0 <=9.7.1
• GitHub repository: https://github.com/mysql/mysql-connector-j
• Published packages: https://central.sonatype.com/artifact/com.mysql/mysql-connector-j
• Package manager: Maven
• Fixed in:
  • OSS MySQL Connector/J 26.7.0
  • NES for MySQL Connector/J

Vulnerability Info

This Medium-severity vulnerability is found in the com.mysql:mysql-connector-j package in multiple versions of MySQL Connector/J. Oracle lists 9.7.0 through 9.7.1 as affected; the same code path is also present in Connector/J 8.0.33, the last release of the 8.0 line, which Oracle no longer assesses.

When an application uses the X DevAPI, Connector/J talks to the server over the X Protocol, where every server message starts with a 5-byte header: a 4-byte little-endian frame length followed by a 1-byte message type. XMessageHeader derives the payload size directly from the frame length the server sent, with no range check:

private void parseBuffer() {
    if (this.messageSize == -1) {
        this.headerBuf.position(0); // process the completed header and initiate message reading
        this.messageSize = this.headerBuf.getInt() - 1;
        this.messageType = this.headerBuf.get();
    }
}

SyncMessageReader then allocates a payload buffer of exactly that size before reading any of the payload:

Parser<T> parser = (Parser<T>) MessageConstants.MESSAGE_CLASS_TO_PARSER.get(messageClass);
byte[] packet = new byte[header.getMessageSize()];

CompressionSplittedInputStream, used when X Protocol compression is negotiated, takes the same unchecked value as the length of the frame payload it reads. The client applies maxAllowedPacket only to messages it sends, not to frames it receives. A malicious or spoofed X Protocol server, or an attacker able to tamper with an unencrypted connection, can therefore send a header announcing a frame of up to about 2 GB, which makes the client try to allocate that much memory for a single message and fail with an OutOfMemoryError, or a header whose length decodes to a negative size, which makes the allocation throw. Either way the attacker can repeatedly crash or hang the client application, affecting availability only. Exploitation requires the application to connect to a server the attacker controls or can impersonate.

Mitigation

MySQL Connector/J is maintained by Oracle, which ships fixes only in the current Connector/J release line; older lines no longer receive updates. For more information, see the MySQL Product Support EOL Announcements.

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

• Upgrade affected applications to supported versions of MySQL Connector/J.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.