CVE-2026-55858: Client/Server Charset-Confusion SQL Injection in MariaDB Connector/J

The MariaDB Connector/J driver (mariadb-java-client) serves as the official Java Database Connectivity (JDBC) client library for MariaDB and MySQL database management systems. A key operational component of the driver is the processing of parameterized statements, where input parameters must be properly sanitized and escaped before database transmission. The driver executes client-side escaping and serialization based on the static configuration that the active session character set remains UTF-8.

This architecture creates a critical security boundary vulnerability when the client and server session states diverge. If the active client character set on the database server is modified mid-session—either via user-executed commands, stored routines, database triggers, or active Man-in-the-Middle configuration modification—the driver remains unaware of this change. It continues to escape and transmit parameter data as UTF-8, while the server interprets incoming raw bytes under the newly defined character set.

This vulnerability, classified as CWE-838 (Inappropriate Encoding for Output Context), permits attackers to systematically bypass client-side parameter validation. By leveraging character set discrepancies, malicious users can inject control characters that escape string boundaries on the database server. This leads directly to unauthenticated SQL injection on applications relying on vulnerable driver versions.

The root cause of CVE-2026-55858 lies in the desynchronization of the character encoding assumptions between the JDBC driver client and the SQL engine. To protect against SQL injection, the driver searches parameter strings for special control characters such as the single quote (0x27). The driver attempts to neutralize this delimiter by prepending an ASCII backslash character (0x5C), turning a single quote into the safe literal sequence 0x5C 0x27 (\').

When a session-level character set modification changes the server-side client character set to a multi-byte encoding like GBK, Big5, or SJIS, the parsing rules shift. In these multi-byte encodings, a character is represented by two or more bytes. Critically, these encodings allow the second (trailing) byte of a multi-byte sequence to overlap with ASCII control values, including the backslash character (0x5C).

An attacker can exploit this parsing behavior by injecting a specific high-order byte directly before a single quote character. For example, in the GBK character set, the byte 0xBF is a valid leading byte. If an attacker inputs the payload 0xBF 0x27, the client-side driver identifies the single quote (0x27) and prepends a backslash (0x5C), transmitting the byte stream 0xBF 0x5C 0x27 to the server.

Upon receiving the sequence, the server parses the bytes under the GBK encoding. Instead of processing the backslash as an escape character, the server merges 0xBF and 0x5C into a single valid multi-byte character (0xBF5C). The trailing single quote (0x27) is left isolated and unescaped. The server parses this quote as a string literal delimiter, allowing the attacker to break out of the string boundary and inject arbitrary SQL commands.

To address this vulnerability, the MariaDB Connector/J maintainers introduced a fail-secure architecture that enforces connection teardown if any non-UTF-8 character set is registered on the session post-initialization. This logic was primarily integrated into BaseContext.java along with state-tracking updates in the connection layer.

The patch introduces an initialized boolean tracking variable that is set to true once the connection handshake sequence is completed. The setCharset method is modified to intercept updates to the active connection character set. If the session has finished initialization and the proposed character set does not begin with the prefix utf8, the driver forcefully closes the network socket and throws a connection exception.

// Context state tracking and connection teardown logic
public void setCharset(String charset) throws SQLNonTransientConnectionException {
  if (initialized && charset != null && !charset.startsWith("utf8")) {
    // Immediately terminate the physical network connection
    connectionCloser.run();
    throw new SQLNonTransientConnectionException(
        String.format(
            "Connection character set was changed to '%s'. Only utf8 / utf8mb3 / utf8mb4 are supported. "
            + "The connection has been closed.",
            charset),
        "08000");
  }
  this.charset = charset;
}

Furthermore, to ensure that the driver is always notified of dynamic character set modifications, the handshake phase was updated. The client explicitly requests tracking for the character_set_client variable from the server using the CLIENT_SESSION_TRACK capability. This ensures that any command altering the active encoding on the server triggers an immediate state-tracker packet on the MySQL/MariaDB wire protocol, which the client parses, intercepts, and blocks by dropping the socket.

Exploitation of CVE-2026-55858 requires an active database session where an attacker can influence the character set state or manipulate parameters inside an application utilizing legacy multi-byte configurations.

In a standard web application scenario, an attacker might target input vectors that allow multi-statement execution or trigger dynamic stored procedures. If an attacker successfully executes a query such as ; SET NAMES gbk; --, the database server updates its session state. On unpatched drivers, the client continues using its standard escaping, enabling the attacker to execute SQL injection on subsequent fields by passing parameters starting with high-order bytes.

In a secondary attack scenario, a Man-in-the-Middle (MitM) actor or an administrator of a hostile rogue database server can return session state-change updates during the connection handshake. By forcing the unpatched client's session to match a legacy multibyte charset on the server side, the attacker can systematically defeat client-side validation controls implemented on the application layer.

The impact of CVE-2026-55858 is rated as Medium, with a CVSS v3.1 base score of 5.9. The CVSS vector is defined as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N. Although the impact is localized to integrity, successful exploitation can lead to complete database manipulation.

The Attack Complexity (AC) is classified as High because exploitation depends on the target application executing commands that modify the database session's character set mid-flight, or the presence of specific environment factors like an untrusted proxy or server. No privileges are required on the database layer to exploit the vulnerability if the application exposes unauthenticated inputs that can manipulate session parameters.

If successfully exploited, an attacker can modify arbitrary table data, delete database schemas, bypass authentication logic, or execute administrative functions within the privileges assigned to the application's database user. Because SQL injection allows execution of arbitrary data modification language (DML) commands, data integrity can be completely compromised.