Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details When `CLIENT_SESSION_TRACK` is negotiated (the default), an OK packet carries an info field followed by session-state blocks, each tracked variable being sent as a length-encoded name and value. `OkPacket.parse()` and `parseWithInfo()` allocated `new byte[len]` for the info field, the variable name and the value with the server-declared `len`, then copied the packet data into it. The copy failed with an `ArrayIndexOutOfBoundsException` when the packet was shorter, but only after the allocation had taken place. A server-declared length of 8 MiB in an 18-byte packet was enough to trigger an 8 MiB allocation; the integer-range validation of length-encoded values does not help, since such lengths are valid positive integers. The…
Recommended action: Upgrade to 3.5.11, 3.4.5 or 3.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The protocol encodes lengths as length-encoded integers, whose 8-byte form the decoder (`readLength()` and `readIntLengthEncodedNotNull()`) returned as `(int) readLong()`. A value above `Integer.MAX_VALUE` therefore wrapped to a negative or unrelated `int`, used afterwards as a length to size allocations or reads, which ended in `NegativeArraySizeException`, out-of-bounds exceptions or oversized allocations. The fix rejects any length-encoded value that does not fit a non-negative `int` with an explicit error. Impact Availability only: a malicious or compromised server, or a MitM, can crash the client's connection handling with unchecked exceptions or drive oversized allocations. Exploitation requires control of the server…
Recommended action: Upgrade to 3.5.10, 3.4.5 or 3.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`XAResource.recover()` in MariaDB Connector/J trusted the `gtrid_length` and `bqual_length` columns returned by `XA RECOVER` to allocate and split each Xid. Details `MariaDbPoolConnection` and `MariaDbPoolPinnedConnection` built each `Xid` of the recovery list by allocating `new byte[gtrid_length]` and `new byte[bqual_length]` and copying from the `data` column, without validating the lengths against the XA specification bounds (`Xid.MAXGTRIDSIZE`, `Xid.MAXBQUALSIZE`) or the actual payload. Negative or oversized lengths, or lengths that do not fit the data, ended in large allocations or unchecked exceptions (`NegativeArraySizeException`, `ArrayIndexOutOfBoundsException`) during recovery. The fix validates the lengths before any allocation or copy and reports an invalid row as an `XAException` (`XAER_RMFAIL`). Impact Availability only, and limited to applications running XA recovery: a malicious or compromised server, or a MitM, can crash the recovery or drive large…
Recommended action: Upgrade to 3.5.11, 3.4.5 or 3.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 ' '`. 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. Details When a server answers a command with a LOCAL INFILE request (`0xFB` packet), the connector opens the named file on the client host and streams it to the server, after verifying that the file corresponds to a `LOAD DATA LOCAL INFILE` of the command it sent (`ClientMessage.validateLocalFileName()`). That verification was a regular expression whose prefix accepted any character, so it answered "does the text appear anywhere in the SQL", including inside a backtick-quoted identifier. Several driver paths put identifiers returned by the server straight back into their next query:…
Recommended action: Upgrade to 3.5.11, 3.4.5 or 3.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details 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. - the list of tracked variables came from the server's global `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…
Recommended action: Upgrade to 3.5.11, 3.4.5 or 3.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details When a client executes LOAD DATA LOCAL INFILE '/path/to/file', the connector sends the filename to the server as part of the COMQUERY. A rogue or MitM server responds with a 0xfb packet echoing that same filename. The connector, without checking allowLocalInfile, transmits the file content. The bypass is therefore limited to the file the application itself intended to load. The attacker cannot escalate to other files (e.g. /etc/passwd) unless the application's own query targets them. The real-world risk is: - An application that uses LOAD DATA LOCAL INFILE on potentially sensitive files (credentials, exports, configs) and connects over an…
Recommended action: Upgrade to 3.5.9, 3.4.3, 3.3.5 or 2.7.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change charactersetclient 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…
Recommended action: Upgrade to 3.5.9, 3.4.3, 3.3.5 or 2.7.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The mysqlclearpassword plugin is gated behind a secure connection: the driver refuses to transmit the password in cleartext over plain TCP. The sibling PAM plugin handler (SendPamAuthPacketFactory, server-side plugin name dialog) did not override that gate and inherited the default value false, so it was not subject to the same secure-transport requirement. As a result, a hostile or man-in-the-middle server can issue an Authentication Switch Request for the dialog plugin over plain TCP, and the driver responds with the user's password in cleartext. With the default configuration (sslMode=DISABLE, restrictedAuth=null) this is reachable with no non-default options. Am I affected? You are affected if all of…
Recommended action: Upgrade to 3.5.9, 3.4.3, 3.3.5 or 2.7.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 that presents a self-signed certificate, claims to be MariaDB, and names the initial authentication plugin mysqlclearpassword receives the victim's database password in cleartext, before any fingerprint/identity check runs. The connection is torn down a moment later, but the credential is already gone. Details For sslMode=verify-full/verify-ca with a password and no serverSslCert/trustStore, the connector falls back to an ephemeral trust manager (default…
Recommended action: Upgrade to 3.5.9, 3.4.3, 3.3.5 or 2.7.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.