CVE-2026-55859: Client-Server Charset Confusion in MariaDB Connector/R2DBC leading to SQL Injection

The MariaDB Connector/R2DBC is an asynchronous, non-blocking Java driver that relies on the Netty framework for database network exchanges. To maintain performance, the driver serializes query parameters and deserializes database responses under the assumption that the connection character set remains UTF-8.

The MySQL and MariaDB protocol allows dynamic session-level configuration changes. A database server can alter session-level variables such as character_set_client and character_set_connection mid-session. When these variables are modified, the server notifies the client driver using the state-tracking mechanism embedded inside the standard database OkPacket payload.

In versions of the R2DBC driver prior to 1.4.1, the client protocol parser completely ignored these session-state-tracking notifications. This omission creates a mismatch where the client behaves under UTF-8 rules, while the database server operates under a different character set, enabling classic multi-byte charset-confusion attacks.

The vulnerability stems from an architectural assumption within the unpatched driver's protocol engine. Because the driver assumes character operations are statically encoded using UTF-8, it does not dynamically adapt its escaping behavior to synchronize with the server's state updates.

When a client-side parameter interpolation takes place, the driver escapes control characters like single quotes (0x27) by prepending a backslash (0x5C). If an attacker successfully triggers a character set change to a multi-byte encoding such as GBK or Big5, the escaping mechanism is completely bypassed.

In multi-byte systems like Big5, the backslash byte 0x5C is a valid trailing byte (the low-order byte) of a multi-byte character sequence. By prefixing the single quote with a high-order byte (for example, 0xd5), an attacker forces the server to pair 0xd5 and 0x5c together as a single multi-byte character. This leaves the trailing quote 0x27 unescaped, leading to arbitrary SQL injection.

The fix introduced in commit 38bad9afebc6c581a853656a42f9ebf403b1b1b7 blocks this state desynchronization vector. The R2DBC context driver is enhanced with state initialization flags and a check inside SimpleContext.java to validate incoming character sets.

// Added in SimpleContext.java
private volatile boolean initialized = false;
 
@Override
public void setCharset(String charset) {
  // If the driver is initialized, reject any character set change to non-utf8 encodings
  if (initialized && charset != null && !charset.startsWith("utf8")) {
    throw new R2dbcNonTransientResourceException(
        String.format(
            "Connection character set was changed to '%s'. Only utf8 / utf8mb3 / utf8mb4 are" 
                + " supported. The connection has been closed.",
            charset),
        "08000");
  }
}
 
@Override
public void setInitialized() {
  this.initialized = true;
}

The protocol parser in OkPacket.java is modified to process state-tracking blocks and call context.setCharset() when the server broadcasts a variable modification:

// Added in OkPacket.java
case "character_set_client":
  context.setCharset(value);
  break;

Additionally, connection factories like MariadbConnectionFactory.java mark the context as fully initialized once the authentication exchange is complete:

// Inside MariadbConnectionFactory.java (post-patch)
.flatMap(
    client -> {
      client.getContext().setInitialized();
      return setSessionVariables(configuration, client).thenReturn(client);
    })

This remediation operates under a fail-fast strategy. Rather than attempting to support dynamic multi-byte translation on the fly, the driver outright rejects any non-UTF-8 transition and terminates the network socket connection immediately.

Exploitation of CVE-2026-55859 requires the execution of a mid-session character set transition followed by a crafted database payload. An attacker can achieve this transition through multiple distinct avenues.

In the first scenario, the target application executes an unauthenticated routine or stored procedure containing a dynamic charset modification. For example, a procedure executing a SET NAMES 'big5' statement causes the backend database to alter its expected client-side encoding.

In the second scenario, a Man-in-the-Middle actor intercepts an unencrypted connection between the application and the database. By tampering with the server's raw TCP response packets, the adversary injects an OkPacket containing a SESSION_TRACK_SYSTEM_VARIABLES structure that sets character_set_client to big5 or gbk.

Once the desynchronized state is established, the attacker delivers an injection payload containing a high-order byte followed by a quote. The application escaper prepends a backslash, creating a byte sequence that the database parses as a single valid multi-byte character. The unescaped quote breaks out of the intended query structure, granting arbitrary command execution.

The impact of this vulnerability is critical for applications processing user input inside dynamically compiled SQL structures. An unauthenticated attacker capable of injecting character set states can routinely bypass standard parameter escaping logic.

This leads directly to unauthenticated remote SQL injection. Depending on the privileges assigned to the database connection pool, the attacker can read, modify, or delete sensitive tables. In some environments, SQL injection allows executing system-level commands or writing malicious files to the filesystem.

The CVSS v3.1 base score is 5.9. The attack complexity is rated as High because triggering the vulnerability requires specific database code paths to alter system variables or an active network position to modify packets. Because it bypasses traditional query isolation layers, this flaw poses a notable risk to multi-tenant or public-facing enterprise services.

Detecting vulnerability exposure involves auditing both codebase dependencies and network encryption configurations. Organizations must check build configurations (such as Maven POM files and Gradle build scripts) to identify the presence of org.mariadb:r2dbc-mariadb versions below 1.4.1.

Immediate remediation requires upgrading to version 1.4.1 or higher. This version contains the fail-fast setCharset verification code that drops mismatched connections.

If patching cannot be executed immediately, administrators must enforce TLS with strict verification (sslMode=VERIFY_CA or VERIFY_FULL). This prevents active network-based attackers from injecting malicious charset changes via packet manipulation. Furthermore, database-level privileges must be restricted to prevent user-supplied sessions from executing SET NAMES commands.