Listen to this Post
MariaDB Connector/R2DBC is a non-blocking MariaDB and MySQL client implemented in Java that enables reactive database operations within Java applications. Prior to version 1.4.1, the connector contains a critical security vulnerability in how it handles character set negotiations during runtime sessions.
The core technical flaw stems from the driver’s rigid assumption that all character data exchanged between the client and server is encoded using UTF-8. While this assumption holds true for the initial connection setup, the driver fails to account for dynamic changes in the session state initiated by the database server itself. The vulnerability manifests through the OK-packet session-state-tracking mechanism, which allows a MariaDB or MySQL server to announce mid-session modifications to the `character_set_client` variable. Such changes can be triggered legitimately through stored routines, triggers, or specific server configurations that execute `SET NAMES` commands. However, this same mechanism can also be exploited by a hostile actor controlling the database server or via a man-in-the-middle attack where an intermediary intercepts and alters session parameters.
When a charset change to a value other than UTF-8 occurs, the driver continues to encode outgoing data as UTF-8 while simultaneously decoding incoming data under that same assumption. Meanwhile, the server interprets these identical byte sequences using its newly announced, different encoding standard. This discrepancy results in silent data corruption because the bytes interpreted by the client do not match their semantic meaning when processed by the server under a different charset mapping. More critically for security operations, this character set confusion can defeat byte-wise quoting or escaping mechanisms employed to prevent SQL injection attacks. If an attacker can manipulate the session’s character set to one that maps certain special characters differently than UTF-8 does, they may bypass input validation logic that relies on specific byte patterns associated with safe encoding in UTF-8. This leads to a classic charset confusion vulnerability where the application believes it is sanitizing inputs correctly based on UTF-8 rules, but the database processes them under a different set of parsing rules, potentially allowing malicious payloads to execute. From an industry standards perspective, this issue aligns closely with CWE-175: Improper Handling of Multiple Encoding Types and CWE-693: Protection Mechanism Failure related to character encoding mismatches.
DailyCVE Form:
Platform: MariaDB Connector/R2DBC
Version: < 1.4.1
Vulnerability: Charset confusion mismatch
Severity: Medium (CVSS 5.9)
Date: 2026-08-28
Prediction: Patch already available
What Undercode Say:
Check current version in Maven project mvn dependency:tree | grep r2dbc-mariadb Check current version in Gradle project gradle dependencies | grep r2dbc-mariadb Verify if connection is vulnerable - monitor for charset changes Look for R2dbcNonTransientResourceException with SQLState 08000 grep "R2dbcNonTransientResourceException" application.log grep "SQLState 08000" application.log Check for silent data corruption - compare expected vs actual data Example: query data that may have been corrupted SELECT id, HEX(column_name) FROM table_name WHERE column_name LIKE '%\x%'; Monitor for mid-session SET NAMES changes in database logs MySQL/MariaDB general log tail -f /var/log/mysql/mysql.log | grep "SET NAMES" Check current character_set_client for active connections SHOW PROCESSLIST; SHOW SESSION VARIABLES LIKE 'character_set_client';
Exploit: (Educational Purposes!)
// EDUCATIONAL DEMONSTRATION ONLY - DO NOT USE IN PRODUCTION
// Scenario: Malicious server triggers charset change mid-session
// 1. Attacker-controlled server sends OK-packet with session-state-tracking
// announcing character_set_client change to e.g., 'latin1'
// 2. Driver continues encoding as UTF-8 while server reads as latin1
// Example payload that could bypass escaping:
String maliciousInput = "'; DROP TABLE users; --";
// Under UTF-8: 0x27273b2044524f50205441424c452075736572733b202d2d
// Under latin1 interpretation: different byte mapping
// 3. The server interprets the same bytes under latin1, potentially
// treating quote characters differently and allowing injection
// 4. The driver raises exception only if charset not in whitelist:
// R2dbcNonTransientResourceException (SQLState 08000)
// To simulate detection after patch:
try {
connection.createStatement("SET NAMES latin1").execute();
} catch (R2dbcNonTransientResourceException e) {
// Connection closed - charset rejected
System.err.println("Charset rejected: " + e.getMessage());
}
Protection:
- Upgrade to 1.4.1 or later – the fix accepts only
utf8,utf8mb3, or `utf8mb4` after initialization; any other value raises `R2dbcNonTransientResourceException` with SQLState 08000 and closes the connection - Configure the MariaDB server to enforce UTF-8 for all client connections
- Disable or remove stored routines, triggers, or configuration changes that alter `character_set_client` during a session
- Monitor database logs for `R2dbcNonTransientResourceException` errors indicating charset conflicts
- Review application data for signs of silent corruption to detect any incidents early
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. The CVSS score of 5.9 places the issue in a moderate severity range. An attacker with control over the MariaDB server or capable of acting as a man-in-the-middle could trigger a charset change mid-session, forcing the driver to continue using UTF-8 and potentially leading to corrupted data or injection attacks. The exploit requires privileged access to the database server or the ability to intercept traffic, making it unlikely for unauthenticated external attackers but a concern for compromised or malicious insiders.
🎯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
