Listen to this Post
CVE-2026-55858 is a vulnerability in the MariaDB Connector/J (and by extension, MySQL Connector/J) that arises from an assumption mismatch between the client driver and the database server regarding the connection’s character encoding. Prior to the patched versions (2.7.14, 3.3.5, 3.4.3, and 3.5.9), the connector encodes and decodes all protocol text and performs client-side escaping under the assumption that the connection character set is permanently UTF-8.
The root cause of this vulnerability is the server’s ability to report a mid-session change to the `character_set_client` system variable. This change can be communicated to the client through the OK-packet session-state tracking mechanism. The server can trigger this change via a variety of methods, including the execution of `SET NAMES` commands, the invocation of stored routines or triggers, server-side configuration changes, or even a malicious server acting in a hostile manner.
The critical flaw is that the driver does not react to this mid-session change. If `character_set_client` is changed to a non-UTF-8 value (e.g., SJIS, Windows-31J, or any other encoding), a dangerous desynchronization occurs. The driver continues to encode all outgoing data and decode all incoming data as UTF-8. Simultaneously, the database server interprets the exact same byte sequences under the new, different encoding. This mismatch leads to silent data corruption, as the data written to the database or read from it will be incorrectly interpreted, leading to garbled text and broken application logic.
More critically, this type of charset confusion is a known primitive that can defeat byte-wise quoting and escaping mechanisms. When the client and server disagree on the encoding of multi-byte characters, an attacker can craft specific payloads that are escaped safely in one encoding (UTF-8) but are interpreted as dangerous SQL syntax in the other encoding. This creates a vector for SQL injection attacks, where the database server executes malicious SQL commands embedded within what the client believed to be safe, escaped data.
The fix implemented in the patched versions is a strict enforcement of character set integrity. After the connection is fully initialized, the driver now rejects any attempt to change the `character_set_client` to a value that is not utf8, utf8mb3, or utf8mb4. If such a change is attempted, the driver immediately raises a `SQLException` with the SQLState `08000` (indicating a connection exception) and forcibly closes the connection to prevent any further data exchange under a mismatched encoding. This prevents both data corruption and the potential for SQL injection.
DailyCVE Form:
Platform: MariaDB Connector/J
Version: <2.7.14, <3.3.5, <3.4.3, <3.5.9
Vulnerability: Charset-Confusion / SQL Injection
Severity: Medium (CVSS 5.9)
Date: 2026-08-28
Prediction: 2026-09-15
What Undercode Say:
Check current MariaDB Connector/J version
mvn dependency:tree | grep mariadb-java-client
Simulate a charset change that triggers the vulnerability (Educational)
Note: This demonstrates the dangerous state before the patch.
try (Connection conn = DriverManager.getConnection(url, user, pass)) {
try (Statement stmt = conn.createStatement()) {
// Change the character set to a non-UTF-8 encoding
stmt.execute(“SET NAMES ‘sjis'”);
// The driver is now in a confused state, still assuming UTF-8.
// Subsequent queries may be vulnerable.
}
}
(Hypothetical) SQL Injection payload exploiting charset confusion
This payload, when escaped as UTF-8, could be interpreted as SQL by a server
using a different encoding like SJIS.
String payload = “\”; // In SJIS, the second byte of a multi-byte char can be 0x5c
Exploit: (Educational Purposes!)
- Establish a connection using a vulnerable version of the connector.
- Execute a `SET NAMES` command to change the connection’s character set to a non-UTF-8 encoding, such as `sjis` or
eucjpms. - The driver, still assuming UTF-8, will escape data using UTF-8 rules.
- Send a crafted string containing multi-byte characters. The server, interpreting the bytes under the new charset, will see a different string, potentially breaking the escaping and allowing SQL injection.
Protection:
- Upgrade: Immediately upgrade to the patched versions: 2.7.14, 3.3.5, 3.4.3, or 3.5.9.
- Enforce UTF-8: Ensure your application and database server are configured to consistently use UTF-8 and avoid any mid-session charset changes.
- Monitor: Audit your application logs for any `SET NAMES` commands or `SQLException` with state `08000` which would indicate a rejected charset change attempt.
Impact:
Silent data corruption and a client/server encoding mismatch once the connection’s charset diverges from UTF-8. Because the mismatch undermines the assumption that quoting/escaping operates on UTF-8 bytes, it belongs to the charset-confusion class that can lead to SQL injection.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
