Advisories for Maven/Org.mariadb.jdbc/Mariadb-Java-Client package

XAResource.recover() in MariaDB Connector/J trusted the gtrid_length and bqual_length columns returned by XA RECOVER to allocate and split each Xid.

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.

MariaDB Connector/J sized heap allocations from lengths declared by the server in OK packets before checking that those lengths fit in the packet. A rogue or MitM server can make the client allocate megabytes from a packet of a few bytes.

MariaDB Connector/J checked a server's LOAD DATA LOCAL INFILE file request by searching the text of the command it had sent for LOAD DATA LOCAL INFILE '<file>'. The search also matched inside quoted identifiers, string literals and comments, so text returned by the server and re-used in a later query could satisfy it. A rogue or MitM server can read any file the client JVM can read.

MariaDB Connector/J narrowed 8-byte length-encoded integers received from the server to int without validation. A rogue or MitM server can send a value above Integer.MAX_VALUE whose truncation becomes a negative or arbitrary length.

MariaDB Connector/J does not enforce allowLocalInfile=false when processing server-initiated LOCAL INFILE requests (protocol packet type 0xfb). However, exploitation is constrained: the server can only request the exact filename the client already included in its LOAD DATA LOCAL INFILE query, it cannot redirect to arbitrary paths.

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.

When PAM (dialog) authentication is used, the connector can be coerced into sending the account password in cleartext over an insecure connection. A hostile or man-in-the-middle server can trigger this with the default configuration, disclosing the user's password.

When a Java application connects with sslMode=verify-full (or verify-ca) and a password but does not pin a server certificate, Connector/J deliberately accepts an untrusted/self-signed certificate at the TLS layer (the "MITM-proof without a CA" feature) and proves the server's identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint enforcement is applied to the OK-packet and auth-switch paths but not to the initial-handshake path. An active man-in-the-middle …