CVE-2026-107313 in pgjdbc
Summary
by MITRE • 10/07/2026
pgjdbc, the PostgreSQL JDBC Driver, versions 42.7.4 and 42.7.5 can send the previous contents of the GSS send buffer in place of the first part of a value on a connection with GSS encryption (gssEncMode=prefer or require), and the server stores the value without an error. The buffer is 16320 bytes with MIT Kerberos. The stored value then holds bytes of the messages the driver sent just before it on the same connection, such as the statement's SQL text, its other parameters, and earlier rows of the same batch, instead of the bytes the application supplied. Values at least as long as the buffer are affected when the driver writes them from a byte array: bind parameters set with setString, setBytes, or a ByteStreamWriter, CopyIn.writeToCopy, and LargeObject.write. Most such writes fail with an ArrayIndexOutOfBoundsException instead. The default, gssEncMode=allow, does not start GSS encryption, and connections without GSS encryption are not affected. Versions 42.7.3 and earlier are not affected, and 42.7.6 fixes the problem.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The PostgreSQL JDBC Driver versions 42.7.4 and 42.7.5 contain a critical memory handling flaw within its GSSAPI encryption implementation that leads to data leakage and potential integrity violations during secure database connections. This vulnerability arises from an improper buffer management mechanism when the driver attempts to encrypt outgoing messages using Generic Security Services Application Program Interface (GSS) protocols, specifically under configurations where gssEncMode is set to prefer or require. In these scenarios, instead of correctly initializing the encryption buffer with fresh data derived from the application's input, the driver erroneously reuses the previous contents of the GSS send buffer for the initial segment of a new value. This behavior results in the transmission of stale cryptographic material rather than the intended plaintext payload during the handshake or early stages of message construction.
The technical root cause lies in how the driver handles byte arrays when writing values such as bind parameters, copy data, or large object contents to the database server over an encrypted channel. When a value is at least as long as the internal GSS send buffer, which measures 16320 bytes with MIT Kerberos implementations, the driver fails to clear or overwrite the preceding state of this buffer before writing new data. Consequently, if the application-supplied data does not fully cover the entire buffer length in a single write operation that triggers encryption, the residual bytes from previously sent messages remain embedded within the encrypted stream. The PostgreSQL server accepts these malformed packets without raising an error because they are syntactically valid within the GSS context, leading to the storage of corrupted or incorrect data in the database.
The operational impact of this vulnerability is severe, primarily manifesting as a significant information disclosure risk and potential data integrity compromise. Because the buffer retains bytes from prior operations on the same connection, sensitive information such as SQL statement text, parameter values, and earlier rows from batched queries can be inadvertently written to the database alongside or instead of the intended application data. This creates a scenario where confidential user input or internal system details may persist in storage fields that were not designed to hold them, potentially exposing credentials, personal identifiable information, or proprietary logic depending on what was transmitted immediately prior to the affected write operation. Furthermore, while many such writes fail with an ArrayIndexOutOfBoundsException due to length mismatches, those that succeed silently corrupt data without alerting the application layer, making detection difficult through standard error handling mechanisms.
This flaw aligns with CWE-20 Improper Input Validation and CWE-134 Use of Externally-Controlled Format String in a Security-Critical Context, as it involves mishandling of input buffers leading to unintended data exposure. From an ATT&CK perspective, this vulnerability facilitates Data Staged or Data Collection techniques where attackers could potentially exploit the connection state to leak sensitive query structures and parameters if they can influence the sequence of operations on a persistent GSS-encrypted session. The default configuration setting gssEncMode=allow does not trigger this issue because it permits unencrypted connections, thereby bypassing the vulnerable code path entirely. Connections established without GSS encryption are also unaffected by this specific buffer reuse flaw.
To mitigate this risk, organizations utilizing pgjdbc must immediately upgrade to version 42.7.6 or later, which corrects the buffer initialization logic and ensures that previous state is properly cleared before new data is processed for encryption. For environments where upgrading is not immediately feasible, administrators should consider disabling GSS encryption by setting gssEncMode to allow if security requirements permit unencrypted traffic, though this reduces overall transport security. Additionally, implementing strict input validation at the application layer and monitoring database logs for anomalous data patterns can help detect potential exploitation attempts involving leaked buffer contents. Regular patch management of JDBC drivers is essential to maintain the integrity of secure communication channels between Java applications and PostgreSQL databases.