CVE-2026-107819 in Connector
Summary
by MITRE • 10/09/2026
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 mysql_clear_password 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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified within MariaDB Connector/C versions ranging from 3.4.1 to 3.4.10 represents a critical flaw in the library's Zero-Configuration SSL authentication-switch logic, specifically concerning how it handles TLS handshake failures and hostname verification mismatches during connection establishment. This client library serves as the interface for C and C++ applications connecting to MariaDB or MySQL databases, making its security posture paramount for data integrity and confidentiality. The core technical flaw lies in the sequence of validation checks performed when a server presents an SSL certificate that fails trust verification but possesses a valid signature from a recognized Certificate Authority for a different hostname than the one specified by the client application. In this scenario, the connector correctly identifies the certificate as untrusted due to the hostname mismatch but erroneously proceeds to select a non-hashing authentication plugin rather than aborting the connection entirely. This logical error creates a dangerous pathway where the security mechanisms intended to protect against man-in-the-middle attacks are effectively bypassed through a race condition in logic flow, allowing sensitive credentials to be transmitted over an encrypted channel that is not actually secure.
The operational impact of this vulnerability is severe, as it enables active man-in-the-middle attackers who possess valid certificates for alternative hostnames to intercept database authentication traffic. By exploiting the flawed logic, an attacker can force the client library into using the mysql_clear_password authentication plugin, which transmits user credentials in plaintext within the TLS tunnel. Although the data appears encrypted due to the established SSL session, the encryption is based on a certificate that does not match the intended server identity, meaning the attacker controls the private key and can decrypt the traffic at will. Consequently, an adversary positioned between the client and the database server can capture usernames and passwords with high reliability. This compromise undermines the fundamental principle of secure remote authentication, potentially leading to unauthorized access to sensitive databases, data exfiltration, and further lateral movement within a network infrastructure where these credentials are reused or hold elevated privileges.
From a classification perspective, this vulnerability aligns closely with CWE-295 Improper Certificate Validation, as the system fails to properly validate the server's certificate against the expected hostname before proceeding with authentication negotiations. Furthermore, it relates to CWE-319 Cleartext Transmission of Password within an Encrypted Channel, because while TLS is technically active, the lack of proper identity verification renders the encryption ineffective for protecting credentials from a determined attacker who controls the endpoint. In terms of adversarial tactics, this flaw facilitates techniques associated with MITM and Credential Access under the ATT&CK framework, specifically allowing attackers to intercept authentication flows that are assumed to be secure by application developers relying on default SSL configurations without explicit hostname verification settings. The vulnerability highlights the risks inherent in zero-configuration security models where automatic fallback mechanisms may prioritize connectivity over strict identity validation.
Mitigation for this issue is straightforward and primarily involves upgrading the MariaDB Connector/C library to version 3.4.10 or later, which corrects the authentication-switch logic to properly reject connections when hostname verification fails. For organizations unable to immediately upgrade, implementing explicit SSL configuration parameters that enforce strict certificate host matching can serve as a compensating control. Developers should ensure that their application code explicitly sets options such as MYSQL_OPT_SSL_VERIFY_SERVER_CERT and configures appropriate CA certificates to prevent the connector from accepting any validly signed certificate regardless of its subject name. Additionally, monitoring for unusual authentication patterns or failed SSL handshakes in database logs can help detect potential exploitation attempts while patching efforts are underway. It is important to note that this vulnerability is specific to MariaDB Connector/C and does not affect other MariaDB connectors, allowing teams to prioritize remediation based on their technology stack dependencies.