PostgreSQL JDBC Driver CVE-2026-107313

Requires a non-default configuration: gssEncMode must be set to prefer or require so that GSS/Kerberos encryption is actually negotiated - the default gssEncMode=allow does not start GSS encryption and is NOT affected, nor are any non-GSS-encrypted connections. The application must also write a value at least as long as the GSS send buffer (16320 bytes with MIT Kerberos) from a byte array via setString, setBytes, a ByteStreamWriter, CopyIn.writeToCopy, or LargeObject.write. Limiting factors that reduce realistic risk: only versions 42.7.4 and 42.7.5 are affected (fixed in 42.7.6); an authenticated database connection is required (PR:L); most qualifying writes fail outright with an ArrayIndexOutOfBoundsException rather than silently leaking; and the leaked bytes come from earlier messages on the same connection, keeping exposure within that connection's own traffic.

This is a genuine but low-priority defect rather than a high-urgency threat. The provided CVSS 3.1 base score is 4.2 (Medium) with vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, and the signals are internally consistent: network vector but high attack complexity (AC:H) because exploitation requires a non-default GSS encryption mode plus a write of at least the ~16320-byte buffer size, and PR:L because a valid authenticated database connection is needed. Exploitation status: no public exploit identified at time of analysis - there is no CISA KEV listing and no POC referenced. No EPSS score was supplied in the input, so exploitation probability cannot be quantified here; absence of EPSS/KEV/POC should not be read as proof of safety, only as lack of evidence. A key mitigating reality stated in the description itself is that most affected writes abort with an ArrayIndexOutOfBoundsException instead of silently leaking, further lowering real-world impact. The confidentiality exposure (CWE-201) is bounded to fragments of the SAME connection's own earlier traffic (prior SQL text, parameters, earlier batch rows) being stored server-side, so turning it into a cross-trust-boundary disclosure requires an actor who can both trigger the oversized write and later read the stored value. Net: real enough to patch, especially where gssEncMode=prefer/require is in use, but not an emergency given AC:H, PR:L, non-default configuration, and lack of any exploitation evidence.

An application running pgjdbc 42.7.4 or 42.7.5 with gssEncMode=prefer or require writes a bind parameter or large object of at least ~16320 bytes (the MIT Kerberos GSS send-buffer size); instead of the supplied bytes, the driver emits the stale contents of the GSS send buffer, so the server silently persists fragments of that connection's earlier SQL text, parameters, or batched rows. A user able to later read that stored column could recover sensitive data belonging to prior operations on the same connection. No public exploit code exists, and most such oversized writes actually fail with an ArrayIndexOutOfBoundsException rather than leaking.