CVE-2026-119281 in MariaDB Connector
Summary
by MITRE • 10/29/2026
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the connector assumed result bytes were UTF-8 but guarded only changes to character_set_client. It did not reject non-UTF-8 character_set_results changes and relied on the server's global session_track_system_variables configuration to report character-set changes. A malicious or compromised server, or a machine-in-the-middle attacker, could suppress tracking or change the result charset so application strings differed from the returned bytes, potentially defeating application-side validation or escaping that depended on the decoded values. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The MariaDB Connector/J serves as a critical bridge for Java-based applications interacting with MariaDB and MySQL database systems, facilitating data exchange through standardized JDBC protocols. In versions ranging from 3.0.0 up to specific patched releases including 3.3.7, 3.4.5, and 3.5.11, the connector exhibited a significant flaw in its handling of character set configurations during result retrieval operations. The vulnerability stems from an inconsistent validation mechanism where the connector strictly enforced UTF-8 encoding for incoming data by guarding changes to the client-side character set variable but failed to apply equivalent restrictions or validations on the server-reported results character set. This architectural oversight created a discrepancy between how the application interpreted string data and the actual byte sequences returned by the database engine, undermining the integrity of text processing within the application layer.
The core technical flaw involves the connector's reliance on the MySQL session_track_system_variables feature to detect changes in the character_set_results variable rather than enforcing strict UTF-8 compliance independently. When a malicious or compromised server altered this configuration, or when a machine-in-the-middle attacker intercepted and modified network traffic to suppress tracking mechanisms, the application would continue processing data under the assumption that it was valid UTF-8 text. However, because the connector did not reject non-UTF-8 character set declarations for results, the decoded strings could differ significantly from their underlying byte representations. This divergence allows an attacker to manipulate how characters are interpreted by the Java runtime environment, potentially leading to encoding mismatches that bypass application-level security controls designed based on expected UTF-8 behavior.
The operational impact of this vulnerability is severe, particularly in contexts where input validation and output escaping rely heavily on accurate character decoding. Attackers can exploit this discrepancy to defeat application-side sanitization logic, as the escaped or validated strings may not match the actual bytes processed by subsequent database queries or system commands. This scenario aligns with CWE-697, which describes incorrect comparison errors, and specifically relates to CWE-184, the improper blacklist of forbidden inputs, since the validation checks are rendered ineffective due to encoding manipulation. Furthermore, this attack vector is consistent with MITRE ATT&CK technique T1557, Adversary-in-the-Middle, where an attacker intercepts communication between two parties and alters it without detection, thereby compromising the confidentiality or integrity of the data exchange.
To mitigate these risks, organizations must ensure that all instances of MariaDB Connector/J are upgraded to version 3.3.7, 3.4.5, or 3.5.11, where the logic has been corrected to properly validate and enforce character set consistency regardless of server-side configurations. Additionally, developers should implement defense-in-depth strategies by validating data encoding at multiple layers rather than relying solely on connector-level assumptions. Enforcing strict UTF-8 enforcement in both application code and database configuration settings can further reduce the attack surface. Monitoring for unexpected changes in session variables related to character sets may also provide early detection indicators of such manipulation attempts, ensuring that any deviation from expected protocol behavior is flagged before it leads to successful exploitation.