Summary

The connector does not gate clear-text password authentication plugins on transport encryption. A hostile or man-in-the-middle MariaDB server can request a clear-text plugin over an unencrypted (plain-TCP) connection, and the driver responds with the user's password in cleartext on the wire.

Details

The driver does not require a secure transport before using clear-text-password authentication plugins. A hostile or man-in-the-middle server can issue an AuthSwitchRequest naming mysqlclearpassword or dialog (PAM) over a plain-TCP, unencrypted connection, and the driver replies with the user's password as cleartext bytes on the wire.

The root cause is that the AuthenticationPlugin interface declares no capability for a plugin to require a secure connection. Because no such gate exists, clear-text plugins run regardless of whether the connection is encrypted.

Impact

The account password is transmitted in cleartext to the peer. An on-path attacker (MITM) who presents themselves as the server can capture the password during the authentication handshake. The disclosed credentials can subsequently be used to authenticate directly against the database server.

Patches

Fixed in 1.4.1. Clear-text authentication plugins (mysqlclearpassword, dialog/PAM) now require a secure connection: the AuthenticationPlugin contract can declare that a plugin requires a secure transport, and such plugins are permitted only over an encrypted connection. Upgrade to 1.4.1 or later.

Workarounds

Until you can upgrade, configure certificate verification explicitly: provide the server/CA certificate and use a verifying SSL mode (e.g. VERIFYCA / VERIFYFULL) so the connection is encrypted and the server's identity is established before credentials are sent.

Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

Summary

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. The server can, however, announce a change of charactersetclient mid-session through the OK-packet session-state-tracking mechanism, for example via a SET NAMES … run by a stored routine or trigger, by server configuration, or by a hostile server.

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.

Am I affected?

You are affected if you use mariadb Connector/R2DBC (org.mariadb:r2dbc-mariadb) below 1.4.1 and a connection can be steered, by a hostile or man-in-the-middle server, or by server-side state such as a stored routine, trigger, or configuration — to switch charactersetclient to a non-UTF-8 value mid-session.

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 1.4.1. Once the connection is fully initialized, any subsequent charset change to a value that is not utf8 / utf8mb3 / utf8mb4 is rejected: the driver raises R2dbcNonTransientResourceException (SQLState 08000) and closes the connection rather than continuing to exchange data under a mismatched encoding. Upgrade to 1.4.1 or later.

Workarounds

There is no reliable application-level workaround; upgrade to 1.4.1 or later.

Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

Summary

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 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).

Summary

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 the following hold:

You use mariadb Connector/J at a version below the patched release(s). Connections can occur over an insecure transport — i.e. plain TCP (sslMode=DISABLE), or a TLS mode that establishes server identity only via self-signed-certificate fingerprint validation. An attacker can occupy an on-path (MITM) position, or otherwise cause the client to connect to a server they control, and present an Authentication Switch Request for the dialog plugin.

Connections over properly verified TLS or a local Unix socket are not exposed to this vector.

Impact

Disclosure of the authenticating account's password in cleartext to an on-path or hostile server. The captured credentials can then be reused to authenticate to the database.

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). PAM (dialog) is now treated exactly like mysqlclearpassword: it may only run over a secure transport. SendPamAuthPacketFactory overrides the secure-required flag to true, and the authentication dispatcher permits a secure-required plugin only when the connection is TLS or a local Unix socket. The pre-existing check that blocks non-MITM-proof plugins when server identity relies solely on self-signed-certificate fingerprint validation continues to apply. Net effect: PAM is allowed over TLS or a Unix socket, and rejected over plain TCP or fingerprint-only connections.

Workarounds

If you cannot upgrade immediately:

Connect over verified TLS (set sslMode=verify-full) so a man-in-the-middle cannot impersonate the server, or use a local Unix socket. Restrict the permitted authentication plugins via restrictedAuth so dialog cannot be negotiated over an insecure transport.

Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

Summary

A SQL injection is possible when the connector escapes Buffer parameters client-side under a multi-byte client character set whose trail-byte range overlaps the ASCII backslash (0x5C): big5, gbk, sjis, cp932, and gb18030. Under these charsets, an attacker-controlled lead byte can absorb the escape byte the connector inserts, leaving the following quote unescaped so it terminates the string literal and injected SQL is parsed.

Details

When binding a Buffer (binary) parameter, the connector escapes the value byte-by-byte, inserting a backslash (0x5C) before quote (0x27) and backslash bytes. This is correct under single-byte and UTF-8–family charsets, but unsafe under client charsets whose multi-byte trail-byte range includes 0x5C.

On the server, the SQL lexer performs multi-byte character recognition (myismbchar) before it interprets escape sequences. If charactersetclient is one of the affected charsets and the attacker controls a byte the lexer treats as a valid lead byte, the sequence <lead-byte><0x5C> is consumed as a single multi-byte character. The escaping backslash inserted by the connector is swallowed as that character's trail byte, so the following 0x27 is no longer escaped — it closes the string literal, and the remaining bytes are parsed as SQL.

This is the well-known multi-byte escaping bypass (the same class that historically affected addslashes / mysqlrealescapestring under GBK/Big5), here applied to the connector's client-side Buffer escaping path.

Am I affected?

You are affected if all of the following hold:

You use mariadb Connector/Node.js at a version below the patched releases listed below. The connection's client character set is one of big5, gbk, sjis, cp932, or gb18030. This is not the default (the default is utf8mb4). Untrusted data can reach a Buffer-typed query parameter.

Applications using utf8mb4 (or any charset whose trail-byte range does not include 0x5C) are not affected by this vector. Parameters bound through the binary/server-side prepared-statement path are also not affected, because those values are sent out-of-band and are never escaped into the SQL text.

Impact

SQL injection. An attacker able to influence the contents of a Buffer parameter can break out of the intended string literal and inject arbitrary SQL, leading to unauthorized read or modification of data and, depending on the database account's privileges, further compromise.

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch:

3.5.x → 3.5.3 3.4.x → 3.4.6 3.3.x → 3.3.3 3.2.x and earlier → 3.2.4 (or any newer release)

Workarounds

If you cannot upgrade immediately:

Use server-side prepared statements (execute) so parameters are bound via the binary protocol rather than escaped into the SQL text. Avoid passing untrusted data as Buffer parameters under the affected charsets.

Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.26, 10.11.1 to before 10.11.17, 11.4.1 to before 11.4.11, 11.8.1 to before 11.8.7, and 12.3.1, MariaDB on WIndows with installed CONNECT engine and enabled REST support interpolated table HTTP attribute into the curl command line without proper sanitizing. This allows the user to execute shell commands on the server. This issue has been patched in versions 10.6.26, 10.11.17, 11.4.11, 11.8.7, and 12.3.2.

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.26, 10.11.1 to before 10.11.17, 11.4.1 to before 11.4.11, 11.8.1 to before 11.8.7, and 12.3.1, during the SST the donor node is interpolating parameters that the joiner sent into the command line. Not all parameters were properly validated which could allow a malicious joiner to execute arbitrary shell commands on the donor side via the mariabackup SST method. This issue has been patched in versions 10.6.26, 10.11.17, 11.4.11, 11.8.7, and 12.3.2.

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.27, 10.11.1 to before 10.11.18, 11.4.1 to before 11.4.12, 11.8.1 to before 11.8.8, and 12.3.1, during the SST the donor node is interpolating parameters that the joiner sent into the command line. Not all parameters were properly validated which could allow a malicious joiner to execute arbitrary shell commands on the donor side via the rsync SST method. This issue has been patched in versions 10.6.27, 10.11.18, 11.4.12, 11.8.8, and 12.3.2.

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.26, 10.11.1 to before 10.11.17, 11.4.1 to before 11.4.11, 11.8.1 to before 11.8.7, and 12.3.1, MariaDB allowed SELECT ... INTO OUTFILE and SELECT ... INTO DUMPFILE without verifying the FILE privilege if the FROM clause contained only subqueries. This issue has been patched in versions 10.6.26, 10.11.17, 11.4.11, 11.8.7, and 12.3.2.

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.27, 10.11.1 to before 10.11.18, 11.4.1 to before 11.4.12, 11.8.1 to before 11.8.8, and 12.3.1, a high-privileged MariaDB user could've used wsrepsstreceiveaddress or wsrepsstdonor global system variables to execute shell commands as the uid of the mariadbd process on the galera joiner node. This issue has been patched in versions 10.6.27, 10.11.18, 11.4.12, 11.8.8, and 12.3.2.

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.26, 10.11.1 to before 10.11.17, 11.4.1 to before 11.4.11, 11.8.1 to before 11.8.7, and 12.3.1, mbstream did not check for /../ in the path when unpacking the archive. A proper backup can never contain such paths, but a specially crafted archive could have caused mbstream to create files outside of the target-dir path. This issue has been patched in versions 10.6.26, 10.11.17, 11.4.11, 11.8.7, and 12.3.2.

Last updated 12 July 2026

Last updated 11 July 2026

Last updated 11 July 2026

Last updated 11 July 2026

Last updated 11 July 2026

Last updated 11 July 2026

Last updated 11 July 2026

MariaDB server is a community developed fork of MySQL server. From versions 10.6.1 to before 10.6.26, 10.11.1 to before 10.11.17, 11.4.1 to before 11.4.11, 11.8.1 to before 11.8.7, and 12.3.1, MariaDB on WIndows with installed CONNECT engine and enabled REST support interpolated table HTTP attribute into the curl command line without proper sanitizing. This allows the user to execute shell commands on the server. This issue has been patched in versions 10.6.26, 10.11.17, 11.4.11, 11.8.7, and 12.3.2.

MariaDB server is a community developed fork of MySQL server. Versions 10.6.1 through 10.6.26, 10.11.1 through 10.11.17, 11.4.1 through 11.4.11, 11.8.1 through 11.8.7, and 12.3.1 with wsrepnotifycmd enabled would execute shell commands embedded in the name of the joiner node. This is fixed in 10.6.27, 10.11.18, 11.4.12, 11.8.8, and 12.3.2. As a workaround, anyone who cannot upgrade now should disable wsrepnotifycmd.

Last updated 11 July 2026

An issue was discovered in MariaDB Server before 11.4.10, 11.5.x through 11.8.x before 11.8.6, and 12.x before 12.2.2. If the cachingsha2password authentication plugin is installed, and some user accounts are configured to use it, a large packet can crash the server because sha256cryptr uses alloca.

MariaDB server is a community developed fork of MySQL server. An authenticated user can crash MariaDB versions 11.4 before 11.4.10 and 11.8 before 11.8.6 via a bug in JSONSCHEMAVALID() function. Under certain conditions it might be possible to turn the crash into a remote code execution. These conditions require tight control over memory layout which is generally only attainable in a lab environment. This issue is fixed in MariaDB 11.4.10, MariaDB 11.8.6, and MariaDB 12.2.2.

In MariaDB server version through 11.8.5, when server audit plugin is enabled with serverauditevents variable configured with QUERYDCL, QUERYDDL, or QUERYDML filtering, if an authenticated database user invokes a SQL statement prefixed with double-hyphen (—) or hash (#) style comments, the statement is not logged.

MariaDB mariadb-dump Utility Directory Traversal Remote Code Execution Vulnerability

This vulnerability allows remote attackers to execute arbitrary code on affected installations of MariaDB. Interaction with the mariadb-dump utility is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the handling of view names. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to execute code in the context of the current user.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of MariaDB. Interaction with the mariadb-dump utility is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the handling of view names. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to execute code in the context of the current user.

An issue was discovered in MariaDB MCP 0.1.0 allowing attackers to gain sensitive information via the SSE service as the SSE service lacks user validation.