CVE-2026-107315: 
Java vulnerability analysis and mitigation

CVE-2026-107315 is an information disclosure vulnerability in pgjdbc (the PostgreSQL JDBC Driver) where the driver pads values shorter than their declared length with uninitialized bytes from its send buffer — containing SQL text and parameter values of prior statements — rather than zeros, and the server stores those bytes as part of the value. Affected versions are 42.7.4 through 42.7.13; versions 42.7.3 and earlier correctly pad with zeros and are not affected. The vulnerability was published on October 7–8, 2026, and a patch is available in version 42.7.14. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a bug in PgBufferedOutputStream.writeZeros, which is documented to write zero bytes but fails to do so when the buffer is empty on entry (count == 0): Arrays.fill(buf, 0, Math.min(startPos, len), (byte) 0) zeroes nothing because startPos is 0, and the subsequent loop flushes the buffer as-is — containing bytes from earlier protocol messages. This maps to CWE-201 (Insertion of Sensitive Information Into Sent Data), CWE-226 (Sensitive Information in Resource Not Removed Before Reuse), and CWE-908 (Use of Uninitialized Resource). The bug was introduced in commit 6f0d54a (first released in 42.7.4) and is triggered via PreparedStatement.setObject with a ByteStreamWriter, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, or Blob.setBytes when the declared length exceeds the actual data supplied. Each padded value can leak up to 8,192 bytes of prior traffic (or 16,320 bytes on GSS-encrypted connections). A proof-of-concept (PaddingRepro.java) is included in the official advisory (GitHub Advisory).

Successful exploitation allows an authenticated attacker to extract up to 8,192 bytes (or 16,320 bytes with GSS encryption) of earlier connection traffic — including SQL statement text and bound parameter values — from stored database values. On pooled connections, this data can originate from other users' requests, enabling cross-tenant data leakage. Sensitive information such as credentials, PII, or business logic embedded in SQL parameters may be exposed. There is no integrity or availability impact; the vulnerability is purely a confidentiality concern (GitHub Advisory, Red Hat Bugzilla).

No public exploit code beyond the researcher-provided PoC in the official advisory has been observed, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.00124 (low probability of exploitation in the near term). The vulnerability requires the attacker to have low-level authenticated access and the ability to both trigger a padded write and read back the stored value, making exploitation moderately complex. It is not currently listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Identify a vulnerable application: Confirm the target application uses pgjdbc versions 42.7.4–42.7.13 with a connection pool and exposes an endpoint that writes binary data (bytea, large objects, or COPY operations) to the database.
2. Trigger a prior sensitive statement: Cause the application to execute a statement containing sensitive data (e.g., credentials or PII as a bound parameter) on the same pooled connection, so the send buffer retains those bytes.
3. Submit a padded write: Craft an application request that invokes one of the vulnerable entry points (PreparedStatement.setObject with a ByteStreamWriter, CopyIn.writeToCopy, LargeObject.write, or Blob.setBytes) with a declared length larger than the actual data supplied, so the driver pads the remainder with send buffer contents.
4. Read back the stored value: Query the database to retrieve the stored value (e.g., SELECT b FROM table WHERE ...) and inspect the bytes beyond the actual data boundary.
5. Extract sensitive data: Parse the padding bytes to recover SQL text and parameter values from earlier statements on the same connection, potentially including credentials or data from other users' requests (GitHub Advisory).

• Database: Stored bytea, large object, or COPY-ingested values whose length significantly exceeds the expected application data size; non-zero bytes in the padding region (bytes beyond the expected data boundary) that contain recognizable SQL text fragments or parameter patterns.
• Logs: Application or database logs showing repeated writes to binary columns or large objects with declared lengths inconsistent with actual data sizes; unusual patterns of reads immediately following writes to the same binary columns.
• Network: Database protocol traffic showing Bind or CopyData messages with declared field lengths larger than the data payload, followed by queries reading back the same values (GitHub Advisory).

Upgrade pgjdbc to version 42.7.14 or later, which fixes PgBufferedOutputStream.writeZeros to correctly zero the full buffer before flushing. Alternatively, downgrade to version 42.7.3 or earlier, which also pads with zeros. As a code-level workaround (without upgrading), audit all application code to ensure the declared length in PreparedStatement.setObject, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write, and Blob.setBytes always exactly matches the actual data supplied — applications that do this are not affected regardless of driver version. No connection property disables the vulnerable behavior in affected versions (GitHub Advisory, Red Hat Bugzilla).

The vulnerability was assigned by the PostgreSQL project and published via a GitHub Security Advisory by maintainer sehrope. Red Hat opened a Bugzilla tracking entry (Bug 2547744) and classified it as medium severity, with 71 CC'd team members indicating broad internal attention across Red Hat product lines. No significant independent researcher commentary or social media discussion has been observed beyond the official advisory at this time (GitHub Advisory, Red Hat Bugzilla).