CVE-2026-119276 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, 3.4.5, and 3.5.11, when CLIENT_SESSION_TRACK was negotiated, the OkPacket.parse() and OkPacket.parseWithInfo() paths allocated byte arrays using server-declared lengths for the OK packet info field and session-state variable names and values before confirming that the bytes remained in the packet. A malicious or compromised server, or a machine-in-the-middle attacker, could send a small OK packet declaring a much larger length and repeatedly force attacker-controlled heap allocations before the subsequent copy failed. This could create garbage-collection pressure or an OutOfMemoryError in the client application. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The MariaDB Connector/J serves as a critical bridge for Java-based applications seeking to interact with MariaDB and MySQL database systems. Within the affected version range spanning from 3.0.0 through specific patches in the 3.3, 3.4, and 3.5 branches, a significant resource management flaw exists within the protocol handling logic. Specifically, when the CLIENT_SESSION_TRACK capability is negotiated during connection establishment, the driver processes OK packets returned by the database server to update session state information. The vulnerability resides in the OkPacket.parse() and OkPacket.parseWithInfo() methods, which are responsible for interpreting these network responses.
The core technical flaw involves an improper validation of input data before resource allocation. Upon receiving an OK packet from the server, the connector extracts length fields associated with the info field and session-state variable names or values. Instead of verifying that the declared lengths do not exceed the actual size of the received byte array, the driver proceeds to allocate Java heap memory based on these untrusted, server-provided length values. This allocation occurs prior to any bounds checking to ensure the data fits within the packet boundaries. Consequently, if a malicious actor controls or compromises the database server, or acts as a man-in-the-middle attacker intercepting traffic, they can craft an OK packet with artificially inflated length fields that are significantly larger than the actual payload size.
This discrepancy triggers repeated and excessive heap allocations on the client side. As the driver attempts to process these malformed packets, it consumes substantial amounts of memory for byte arrays that will ultimately fail validation or copy operations in subsequent steps. This behavior creates severe garbage collection pressure within the Java Virtual Machine environment hosting the application. In sustained attack scenarios, this resource exhaustion leads directly to an OutOfMemoryError, causing the client application to crash or become unresponsive. The impact is effectively a denial of service against the connecting applications and potentially the underlying infrastructure if memory limits are shared across multiple services.
From a classification perspective, this vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value, as it involves allocating resources based on an externally controlled value without proper validation of its magnitude relative to available data. Furthermore, because the attack vector relies on manipulating network protocol responses from a server or intermediary to exhaust client resources, it maps closely to MITRE ATT&CK technique T1498: Network Denial of Service, specifically under sub-techniques involving resource exhaustion via malformed inputs. The vulnerability highlights the risks associated with trusting metadata provided by external systems without rigorous boundary checks before committing system resources.
Mitigation requires immediate upgrading of the MariaDB Connector/J library to patched versions 3.3.7, 3.4.5, or 3.5.11, where the logic has been corrected to validate packet lengths against actual buffer sizes prior to allocation. For organizations unable to patch immediately due to dependency constraints, implementing network-level controls such as intrusion detection systems capable of identifying anomalous packet structures may provide partial mitigation by dropping malformed traffic before it reaches the application layer. Additionally, configuring Java runtime environments with increased heap limits or stricter garbage collection policies can offer temporary resilience against memory exhaustion attacks, though this does not address the root cause and should be viewed only as a compensating control until the software is updated.