CVE-2026-119278 in MariaDB Connector
Summary
by MITRE • 10/29/2026
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7 and 3.4.5, during caching_sha2_password authentication, the authentication-more-data response was treated as a length-encoded byte array, memory was allocated from the server-declared length, and authResult[0] was accessed without ensuring a byte existed. A malicious or compromised server, or a machine-in-the-middle attacker, could declare a very large length or send an empty response before any password was transmitted. The malformed packet could cause excessive allocation or an unchecked ArrayIndexOutOfBoundsException escaping from DriverManager.getConnection(). This issue is fixed in versions 3.3.7 and 3.4.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
MariaDB Connector/J serves as a critical JDBC driver enabling Java-based applications to establish connections with MariaDB and MySQL database servers, facilitating data exchange and transaction processing within enterprise architectures. The vulnerability identified affects specific releases of this connector, namely versions ranging from 3.0.0 up through 3.3.7 and version 3.4.5. This security flaw is specifically tied to the authentication process when utilizing the caching_sha2_password plugin, which is a default and widely deployed authentication method in modern MariaDB and MySQL environments due to its support for secure password hashing and caching mechanisms that improve connection performance by reducing repeated full authentications.
The technical root cause of this vulnerability lies in how the connector handles the server's response during the multi-stage authentication handshake. Specifically, when processing the auth_more_data packet sent by the database server, the driver incorrectly interprets the payload as a length-encoded byte array and proceeds to allocate memory based on the length value declared within that packet without performing adequate validation checks. This design assumption creates a critical logic error where the application trusts untrusted input from the network layer regarding buffer sizing. Consequently, if an attacker controls or compromises the database server, or acts as a machine-in-the-middle intercepting traffic between the client and server, they can manipulate this length field to declare an excessively large value or send malformed packets that do not contain sufficient data bytes.
This lack of input validation leads directly to two distinct operational impacts depending on how the malicious packet is constructed. If the declared length is extremely large, the Java Virtual Machine attempts to allocate a massive amount of memory for the byte array, which can rapidly exhaust available heap space and trigger an OutOfMemoryError, resulting in a Denial of Service against the application server hosting the MariaDB Connector/J instance. Alternatively, if the packet declares a non-zero length but fails to provide the corresponding data bytes, or sends an empty response prematurely, the subsequent code attempts to access index zero of the authResult array without verifying that any elements exist. This results in an unchecked ArrayIndexOutOfBoundsException escaping from DriverManager.getConnection(), causing abrupt application crashes and potential service disruption.
From a threat modeling perspective, this vulnerability aligns with CWE-134: Use of Externally-Controlled Format String or CWE-789: Uncontrolled Memory Allocation, as the system allocates resources based on untrusted input without bounds checking. In terms of adversarial tactics, it maps to MITRE ATT&CK technique T1496: Resource Hijacking if exploited for denial-of-service via memory exhaustion, and potentially relates to T1078: Valid Accounts if an attacker uses compromised credentials to trigger the malformed authentication flow against a specific target instance. The vulnerability highlights the risks associated with trusting network-provided metadata during protocol handshakes without rigorous validation of payload integrity relative to declared sizes.
To mitigate this risk, organizations must immediately upgrade their MariaDB Connector/J dependencies to version 3.3.7 or later, where these bounds checks and input validations have been implemented by the maintainers. Until such an update is deployed in production environments, it is advisable to restrict network access to database servers using strict firewall rules that prevent unauthorized hosts from intercepting or injecting traffic into the JDBC connection streams. Additionally, implementing robust monitoring for unexpected exceptions within application logs can help detect attempted exploitation of this flaw, allowing security teams to respond before significant service disruption occurs.