PostgreSQL JDBC Driver CVE-2026-107315

Exploitation requires an affected pgjdbc version (42.7.4 through 42.7.13) and an application that declares a value length larger than the data it actually supplies through one of these specific APIs: PreparedStatement.setObject with a ByteStreamWriter, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, or Blob.setBytes. The attacker must be able to cause the application to store such a value and then read it back. Meaningful cross-tenant leakage additionally requires a pooled/shared connection so that the residual send-buffer bytes contain other requests' SQL text and parameters; GSS encryption raises the leak size from 8192 to 16320 bytes per value. Limiting factors: applications whose declared lengths always match their supplied data are not affected at all, versions 42.7.3 and earlier pad with zeros (not vulnerable), and the attacker needs authenticated access to the application to both store and retrieve the padded value.

This is a moderate, conditional information-disclosure flaw rather than a high-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.3) is internally consistent with the description: network-reachable but High attack complexity because exploitation depends on a specific application coding pattern (declaring a length larger than the data supplied via particular APIs) and on a pooled-connection deployment where another tenant's traffic is still resident in the send buffer. Low privileges (PR:L) reflect that the attacker must be an authenticated user of the affected application able to store and read back a value. There is no EPSS score, no CISA KEV listing, and no POC referenced in the input, so there is no signal of active or probable near-term exploitation - no public exploit identified at time of analysis. The C:H/I:N/A:N shape is appropriate: the only consequence is leakage of up to 8192 bytes (16320 with GSS encryption) of recent SQL text and parameter values, which on a pooled connection may belong to other requests - potentially sensitive, but requiring a vulnerable usage pattern that most applications do not exhibit. Net: real but niche; prioritize patching for Java applications that use the named write APIs with mismatched declared lengths, but this is not a mass-exploitation candidate.

A multi-tenant Java web application uses pgjdbc with a shared connection pool and stores a value (for example via Blob.setBytes or CopyIn.writeToCopy) declaring a length longer than the bytes it actually supplies. An authenticated attacker triggers this store and then reads the value back, receiving the padding - leftover send-buffer bytes containing SQL text and parameter values from other users' recent statements on the same pooled connection. No public exploit code is identified at time of analysis, and exploitation depends on the application's specific use of the affected APIs.