CVE-2026-107315 in pgjdbc
Summary
by MITRE • 10/08/2026
pgjdbc, the PostgreSQL JDBC Driver, versions 42.7.4 through 42.7.13 pads a value that is shorter than its declared length with bytes left in its send buffer instead of zeros, and the server stores those bytes as part of the value. The bytes are messages the driver sent earlier on the same connection: SQL text and parameter values of recent statements, which on a pooled connection can come from other requests. Each padded value can carry up to 8192 bytes of this traffic, or 16320 bytes on a connection with GSS encryption. The padding happens when an application declares a length larger than the data it supplies, through PreparedStatement.setObject with a ByteStreamWriter, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, or Blob.setBytes. The driver accepts these calls without an error. An attacker who can make the application store such a value and read it back can collect earlier traffic. Applications whose declared lengths always match their data are not affected. Versions 42.7.3 and earlier pad with zeros.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability in pgjdbc, specifically within versions 42.7.4 through 42.7.13 of the PostgreSQL JDBC Driver, represents a critical information disclosure flaw rooted in improper memory handling during data transmission to the database server. This issue arises when an application attempts to insert or update a value where the declared length exceeds the actual size of the provided data. In such scenarios, rather than zeroing out the remaining buffer space as intended by secure coding practices and previous driver versions, pgjdbc leaves the existing bytes in the send buffer untouched. These residual bytes are then transmitted to the PostgreSQL server along with the new data value, effectively embedding them into the stored record. This behavior creates a side-channel through which sensitive information from prior operations on the same database connection can be exfiltrated via subsequent reads of the affected column or field.
The technical mechanism behind this flaw involves the internal send buffer management within the driver. When methods such as PreparedStatement.setObject with a ByteStreamWriter, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, or Blob.setBytes are invoked with a length parameter larger than the actual data payload, the driver fails to clear the unused portion of the transmission buffer. Consequently, any SQL text, query parameters, or other sensitive values sent in previous statements on that specific connection remain present in the memory space allocated for the current operation. Upon execution, these stale bytes are appended to the new value before being written to the database. The scope of this leakage is significant, as each affected padded value can carry up to 8192 bytes of prior traffic under standard conditions, or up to 16320 bytes if GSS encryption is enabled on the connection. This magnitude allows an attacker to reconstruct substantial portions of previous application logic and data payloads.
The operational impact of this vulnerability is particularly severe in environments utilizing database connection pooling. In pooled connection architectures, a single physical connection is reused across multiple logical requests from different users or sessions. If one request leaves residual sensitive data in the send buffer due to improper padding, that same connection might be assigned to another user who triggers the vulnerable code path. This cross-session contamination enables an attacker with write access to specific database tables and read access to those same records to harvest credentials, session tokens, personally identifiable information, or other confidential details from unrelated transactions. The risk is mitigated only in applications where developers strictly ensure that declared lengths always match the actual data length, thereby avoiding the padding condition entirely; however, this defensive coding practice cannot be relied upon as a primary security control given its fragility and potential for human error.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation regarding the failure to sanitize or initialize buffer lengths prior to transmission, and more critically CWE-200 Exposure of Sensitive Information to an Unauthorized Actor due to the leakage of historical network traffic data. In terms of adversarial tactics, it maps to ATT&CK technique T1537.001 Data Transfer Size Minimization as a defense evasion vector is not applicable here; rather, it represents a failure in secure memory management leading to information leakage akin to CWE-468 Incorrect Ownership Assignment or general insecure data handling practices found in legacy codebases that do not explicitly clear buffers before reuse. The root cause lies in the driver's assumption that application-level length declarations are always accurate and sufficient for buffer initialization, ignoring the statefulness of TCP connections and pooled resource management patterns common in enterprise Java applications.
To mitigate this vulnerability, organizations must immediately upgrade pgjdbc to version 42.7.14 or later, where the padding behavior has been corrected to zero out unused buffer space before transmission. For environments unable to patch immediately due to dependency constraints, a temporary mitigation involves enforcing strict validation at the application layer to ensure that no calls are made with declared lengths exceeding actual data sizes. Developers should audit codebases for uses of PreparedStatement.setObject, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, and Blob.setBytes to identify potential trigger points. Additionally, implementing database-level access controls can limit the blast radius by restricting which users or service accounts have read permissions on tables susceptible to this leakage, thereby reducing the likelihood that an attacker can successfully retrieve the contaminated records containing exfiltrated data from previous sessions.