MariaDB Connector/J decodes every result as UTF-8 and guards
character_set_client against a change to another charset, but did not guard
character_set_results, and relied on the server's global
session_track_system_variables list to be told about charset changes at all.
The connector learns about session variable changes through session tracking,
and closes the connection when character_set_client is switched away from UTF-8,
so that its UTF-8 decoding stays correct. Two gaps remained:
character_set_results was not guarded: a server could switch it to another
charset, after which the bytes of every result were decoded as UTF-8 although
encoded otherwise.session_track_system_variables: a server configured, or made, not to track
the character set variables could change them silently.The fix requests an explicit session tracking list that includes both character
set variables whatever the server's global setting, and closes the connection
when character_set_results is changed to a charset other than utf8, utf8mb3
or utf8mb4, as it already did for character_set_client.
Integrity: a malicious or compromised server, or a MitM, can make the strings an application reads differ from the bytes the server returned (inappropriate encoding for the output context), which can defeat application-side validation or escaping built on those values. Exploitation requires control of the server side of the connection; no confidentiality or availability impact.
Reported by fg0x0
{
"cwe_ids": [
"CWE-838"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T22:59:45Z",
"nvd_published_at": "2026-10-29T21:17:21Z",
"severity": "MODERATE"
}