CVE-2026-107315: pgjdbc pads a value shorter than its declared length with bytes of earlier statements (rather than zeros)
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.
Affected Software
Event History
Frequently Asked Questions
Which applications are exposed in practice?
Applications using pgjdbc 42.7.4 through 42.7.13 are affected only if they declare a value length larger than the data supplied through one of the affected APIs. Applications whose declared lengths always match their data are not affected.
What would an attacker need to do to obtain data?
The attacker must be able to cause the application to store a value with a declared length larger than the supplied data and then read that stored value back. The leaked padding can contain SQL text and parameter values from earlier statements sent on the same database connection.
Does connection pooling increase the impact?
Yes. On pooled connections, earlier traffic in the driver's send buffer can originate from other requests, so the stored padding may expose data associated with other users or operations sharing that connection.
Which APIs should be reviewed for mismatched declared lengths?
Review uses of PreparedStatement.setObject with a ByteStreamWriter, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, and Blob.setBytes. These calls can be accepted without an error when the declared length exceeds the supplied data.
What can be done if an upgrade is not immediately possible?
Ensure every declared length exactly matches the bytes actually supplied to the affected APIs. Versions 42.7.3 and earlier pad with zeros rather than prior send-buffer contents.