MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, SHOW CREATE SERVER, SHOW CREATE USER, and mariadb-dump are affected because each does not consistently quote identifiers and values when serializing SQL. A low-privileged attacker can trigger the issue when an attacker-created object with crafted identifiers or values is included in SHOW output or a dump, then create an object with crafted identifiers or values so generated SQL contains injected statements and execute attacker-injected SQL when the poisoned output is applied. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, STArea reads beyond the allocated buffer when processing invalid WKB for a MultiPolygon because the multi-polygon parser advances past a nested geometry header without first verifying enough input remains. A low-privileged remote attacker can supply malformed spatial data to disclose memory useful for bypassing ASLR as part of a multi-vulnerability chain. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 12.3.1 until 12.3.3 and 13.0.2, SYSREFCURSOR handling is affected because cursor-array reallocation can leave stale references in routine contexts. A low-privileged attacker can open a large number of SYSREFCURSORs and then fetch one to trigger a use-after-free that can enable remote code execution when combined with another vulnerability. This issue is fixed in versions 12.3.3 and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, STAsText can write beyond an allocated output buffer when converting deeply nested GeometryCollections because recursive WKT serialization does not account for bytes consumed or reserve sufficient space. A low-privileged remote attacker can submit a specially crafted GIS object to corrupt memory and potentially achieve code execution when combined with another vulnerability. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the #mysql50# bypass prefix is affected because it allows the #mysql50# prefix to bypass normal table-name filesystem encoding. An attacker can trigger the issue with a table name using the #mysql50# prefix, then use a #mysql50# table name to access files under their legacy unencoded name and cause crashes, data corruption, data exfiltration, or remote code execution. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the GRANT PROXY statement treats an IDENTIFIED clause with an empty password as though authentication were not specified, causing it to check the wrong grantor privileges. A low-privileged attacker who can name another account can exploit this authorization error to set that account's password. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the CONNECT engine plugin file-access UDFs jsonfile(), bsonfile(), jfilemake(), bfilemake(), and jbinfile() are affected because each does not enforce FILE privilege or the securefilepriv setting. A low-privileged attacker can trigger the issue by calling a CONNECT file-access UDF with a filesystem path, then invoke a CONNECT file-access UDF to access a filesystem path and read or write files that the database account is not authorized to access, subject to operating-system permissions. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the MariaDB view FRM parser did not safely encode embedded newline characters in a username. An account with CREATE USER and CREATE VIEW WITH GRANT OPTION could create a crafted username containing additional view metadata, causing the parser to interpret part of the username as security metadata and potentially escalating database privileges. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, MariaDB's ACL cache could generate the same database-privilege cache key for role and localhost user names that matched because both used an empty IP component. An attacker with CREATE USER could create the colliding principal and, when the original principal's database privileges were cached, exercise privileges assigned to the other account. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, MariaDB insufficiently validated counts, offsets, lengths, and field boundaries in FRM metadata while opening binary FRM files. An attacker able to place a crafted FRM file in the data directory could trigger out-of-bounds reads or writes, crash the server, or potentially execute code. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB Connector/C is a C and C++ client library for connecting applications to MariaDB and MySQL databases. From 3.4.1 until 3.4.10, the MariaDB Connector/C libmariadb Zero-Configuration SSL authentication-switch logic checked certificate trust failure but did not reject a TLS hostname verification mismatch before selecting a non-hashing authentication plugin. An active man-in-the-middle attacker with a valid certificate for another hostname could request mysqlclearpassword and obtain the database password inside the attacker-controlled TLS connection. Other MariaDB connectors are not affected. This issue is fixed in version 3.4.10.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the mariadb.service unit used /run/mysqld/wsrep-new-cluster during the next service restart. A database user with FILE privilege and a secure-file-priv configuration permitting writes to /run/mysqld could create that file and inject attacker-controlled environment values into the restarted service. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the mysqljson plugin assumed that imported MySQL tables contained valid MySQL binary JSON data. A specially prepared MySQL table containing invalid JSON data could cause out-of-bounds reads, information disclosure, or a server crash. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the qcinfo plugin could be confused by a query containing embedded null bytes. Reading informationschema.querycacheinfo after such a query was cached could access data beyond the end of a heap-allocated buffer, potentially disclosing adjacent memory or crashing the server. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the CONNECT engine's DOS table type used an incorrect boundary check that permitted a one-byte null write beyond a stack buffer at an attacker-controlled offset. An authenticated user able to use the CONNECT engine could cause a crash and potentially remote code execution. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, MariaDB RPM packages created the dedicated mysql service account with the database data directory as its home directory. A database user with the FILE privilege could write startup dot-files such as .bashprofile into $HOME, and those files could execute when an administrator opened a login shell for the mysql account. Debian packages are not affected because they use /nonexistent as the account home. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.

Description On the zero-configuration TLS path, the connector accepts a self-signed server certificate at the TLS level and then validates the server's identity from the fingerprint hash the server appends to the final OKPacket (Authentication.validateFingerPrint). That validation calls hash() on the authentication plugin in use to obtain the password-derived secret both sides combine with the seed and the certificate fingerprint.

Ed25519PasswordAuth.hash() referenced an identifier seed that was not in scope: it was neither a parameter of the method nor a module-scope binding, existing only as a parameter of the unrelated static encryptPassword(password, seed). Invoking the method therefore threw ReferenceError: seed is not defined.

The throw happens synchronously inside the socket data handler, and no frame between PacketInputStream.onData() and the plugin guards it, so the error escapes as an uncaught exception rather than surfacing as a connection error.

Because the fingerprint hash is what a legitimate MariaDB server sends on this path, ed25519 authentication with zero-configuration TLS never completed successfully — the failure is not limited to a hostile server.

Impact Denial of service against the client process. Under Node's default uncaughtException behaviour the process exits, so a long-running service is terminated rather than seeing a failed connection attempt. No credential is disclosed and no data is altered; the impact is availability only.

An unauthenticated attacker able to intercept the connection (a MitM presenting a self-signed certificate, or a compromised server) can trigger the crash at will, since the self-signed-certificate path is precisely what such an attacker exercises and the rogue server only has to answer the ed25519 challenge with an OKPacket carrying a 0x01-prefixed validation hash.

Exposure requires all of the following: a MariaDB server reached over TCP (not a unix socket), ssl: true or an ssl object without rejectUnauthorized: false, a password set, no ssl.ca provided, and cliented25519 as the negotiated authentication plugin. Other authentication plugins are unaffected, as is any configuration where the server certificate is verified against a provided CA.

Resolution Ed25519PasswordAuth.hash() now returns the Ed25519 public key derived from the password scalar, which is the value the server combines into the fingerprint hash, and the derivation is covered by unit and integration tests.

Fixed in 3.5.4. The 3.3.x and 3.4.x maintenance branches are not patched; upgrade to 3.5.4 or later.

Workarounds Provide the server certificate to the client (ssl: { ca: ... }) so standard certificate validation is used instead of fingerprint validation, or set ssl: { rejectUnauthorized: false } to opt into trust mode, or use an authentication plugin other than cliented25519, until upgraded.

Credit Reported by fg0x0.

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