GHSA-xvr9-35cr-46v9 org.mariadb.jdbc:mariadb-java-client has Inappropriate Encoding for Output Context

• Maven org.mariadb.jdbc:mariadb-java-client: < 2.7.14 → fixed in 2.7.14 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.0.0, < 3.3.5 → fixed in 3.3.5 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.4.0, < 3.4.3 → fixed in 3.4.3 • Maven org.mariadb.jdbc:mariadb-java-client: >= 3.5.0, < 3.5.9 → fixed in 3.5.9

Summary The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change character_set_client mid-session to a non-UTF-8 charset, after which the driver and server interpret the same bytes under different encodings, causing silent data corruption and a client/server charset-confusion mismatch. Details The driver encodes and decodes all character data on the assumption that the connection character set is UTF-8. Charset can be changed by commands like SET NAMES... commands. If the new charset is not UTF-8, the driver continues to read and write UTF-8 while the server interprets the same bytes under a different encoding. The result is silent data corruption and a client/server charset-confusion mismatch. Charset confusion of this kind is also the primitive that can defeat byte-wise quoting/escaping when client and server disagree on a multi-byte encoding. 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. Patches Fixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x → 3.5.9, 3.4.x → 3.4.3, 3.0/3.1/3.2/3.3.x → 3.3.5, 2.x → 2.7.14). Once the connection is fully initialized, any subsequent charset change to a value that is not utf8 / utf8mb3 / utf8mb4 is rejected: the driver raises a SQLException with SQLState 08000 (connection exception) and closes the connection rather than continuing to exchange data under a mismatched encoding. Workarounds There is no reliable application-level workaround. Credit Reported by Yalguun Tumenkhuu (@fg0x0).