CVE-2026-119280 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, the MariaDbPoolConnection.recover() and MariaDbPoolPinnedConnection.recover() implementations trusted the gtrid_length and bqual_length columns returned by XA RECOVER. The methods allocated and split Xid byte arrays without validating the lengths against Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE, or the actual data payload. A malicious or compromised server, or a machine-in-the-middle attacker, could cause large allocations, NegativeArraySizeException, or ArrayIndexOutOfBoundsException during XA recovery. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
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, facilitating robust transactional integrity through support for XA distributed transactions. Within the version range spanning from 3.0.0 up to specific patched releases including 3.3.7, 3.4.5, and 3.5.11, a significant security flaw exists in the implementation of connection recovery mechanisms. Specifically, the recover methods within MariaDbPoolConnection and MariaDbPoolPinnedConnection classes exhibit insufficient input validation when processing data retrieved from XA RECOVER operations. This architectural oversight allows for potential exploitation scenarios that can destabilize application servers or lead to denial-of-service conditions against infrastructure components relying on this connector library.
The technical core of the vulnerability lies in how byte arrays representing transaction identifiers are allocated and processed during recovery procedures. When an XA resource manager returns information about pending transactions, it includes fields such as gtrid_length and bqual_length which indicate the size of global transaction identifiers and branch qualifiers respectively. The vulnerable implementations blindly trust these length values provided by the server or intermediary network elements without verifying them against established constants like Xid.MAXGTRIDSIZE and Xid.MAXBQUALSIZE, nor do they validate that the lengths correspond to the actual payload data available in memory. Consequently, if a malicious actor controls the database server or intercepts traffic via a machine-in-the-middle attack, they can supply artificially inflated length values.
This lack of validation leads directly to severe runtime exceptions and resource exhaustion issues. Depending on the specific value supplied by an attacker, the application may attempt to allocate excessively large byte arrays that exceed available heap memory, resulting in OutOfMemoryError conditions that crash the Java Virtual Machine or degrade performance significantly for other processes sharing the same resources. Alternatively, if the length values are negative due to integer overflow manipulation or malicious input crafting, the system throws a NegativeArraySizeException. In cases where the specified length exceeds the actual buffer size but remains positive, an ArrayIndexOutOfBoundsException occurs during array splitting operations. These exceptions disrupt normal application flow and can cause service outages in production environments that depend on reliable database connectivity for transactional consistency.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow concepts adapted to Java memory management contexts where unchecked allocation sizes lead to instability rather than arbitrary code execution in traditional C/C++ scenarios. It also maps to ATT&CK techniques related to Denial of Service via resource exhaustion and potentially input validation failures that allow for manipulation of system state during recovery phases. The impact extends beyond simple crashes; it undermines the reliability guarantees provided by XA transactions, which are essential for maintaining data integrity across distributed systems.
Mitigation strategies primarily involve upgrading the MariaDB Connector/J library to one of the fixed versions: 3.3.7, 3.4.5, or 3.5.11 and later releases where proper bounds checking has been implemented before array allocation. Organizations should audit their dependency trees for these specific connector versions and apply patches promptly. Additionally, implementing network-level security controls such as TLS encryption between application servers and database instances can mitigate the risk of machine-in-the-middle attacks exploiting this flaw by ensuring that length parameters cannot be tampered with in transit. Regular vulnerability scanning and adherence to secure coding practices emphasizing strict input validation for all external data sources remain essential defenses against similar classes of vulnerabilities.