Description

MariaDB Connector/R2DBC is a non-blocking MariaDB and MySQL client implemented in Java. Prior to 1.4.1, org.mariadb:r2dbc-mariadb does not gate clear-text password authentication plugins on transport encryption because the AuthenticationPlugin interface has no capability for a plugin to require a secure connection. A hostile or man-in-the-middle MariaDB server can send an AuthSwitchRequest naming mysql_clear_password or dialog (PAM) over a plain-TCP unencrypted connection, and AuthenticationFlow permits ClearPasswordPluginFlow or PamPluginFlow to return the user's password as cleartext bytes on the wire. The disclosed credentials can subsequently be used to authenticate directly to the database server. This issue is fixed in version 1.4.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-28T23:17:09.153Z",
  "pubdate": "2026-08-28T23:17:09.153Z",
  "executiveSummary": "The MariaDB Connector/R2DBC is susceptible to a critical information disclosure vulnerability due to a lack of enforced transport encryption during authentication.\nThe issue stems from an architectural limitation in the AuthenticationPlugin interface, which fails to mandate secure connections when using clear-text password authentication mechanisms.\nAffected versions include all releases of org.mariadb:r2dbc-mariadb prior to 1.4.1.\nA malicious or compromised MariaDB server acting as a man-in-the-middle can force the client to use insecure authentication protocols such as mysql_clear_password or PAM.\nThis results in the transmission of user credentials in cleartext over unencrypted TCP connections.\nSuccessful exploitation allows an attacker to intercept and harvest legitimate database credentials, which can then be used to gain unauthorized access to the database server.\nThis vulnerability represents a significant risk to confidentiality, particularly in environments where connections to database servers are not strictly verified or protected by independent transport-layer security protocols.",
  "technicalDetails": "The root cause of this vulnerability is an inherent design flaw within the AuthenticationPlugin interface in org.mariadb:r2dbc-mariadb. The interface does not provide the necessary hooks or capability flags for authentication plugins to explicitly require a secure connection (TLS/SSL) before executing the authentication handshake.\nDuring the connection initialization, the MariaDB server and the R2DBC client perform an authentication handshake. A hostile server can initiate an AuthSwitchRequest, explicitly requesting the use of the mysql_clear_password or dialog (PAM) authentication plugins. Because the client library fails to validate whether the current connection is encrypted, it proceeds with the requested flow.\nThe AuthenticationFlow component subsequently invokes ClearPasswordPluginFlow or PamPluginFlow. These components are designed to transmit the user's password as raw, cleartext bytes directly across the wire to satisfy the server's authentication request. Since the library does not verify the presence of an encrypted channel prior to this transmission, the credentials remain exposed to any entity capable of sniffing traffic between the client and the server.\nThe attack flow follows these steps: 1) A client attempts to establish a connection to a database server controlled by an attacker or a server that has been compromised. 2) The server responds with an AuthSwitchRequest specifying an insecure authentication method (mysql_clear_password or PAM). 3) The client's AuthenticationFlow accepts the switch request without checking for transport encryption. 4) The client library sends the plaintext password bytes over the unencrypted TCP socket. 5) The attacker captures the cleartext credentials, which are then valid for use against the intended database server or other services relying on the same credentials.\nThis vulnerability persists in all versions of the connector prior to 1.4.1. The lack of gatekeeping on insecure protocols means that even if a user assumes they are operating in a secure environment, the protocol downgrade initiated by the server bypasses security expectations. The impact is total credential compromise for any user connecting to a malicious or compromised database instance."
}