CVE-2026-107313: pgjdbc stores bytes of earlier messages in place of a large value on GSS-encrypted connections
pgjdbc, the PostgreSQL JDBC Driver, versions 42.7.4 and 42.7.5 can send the previous contents of the GSS send buffer in place of the first part of a value on a connection with GSS encryption (gssEncMode=prefer or require), and the server stores the value without an error. The buffer is 16320 bytes with MIT Kerberos. The stored value then holds bytes of the messages the driver sent just before it on the same connection, such as the statement's SQL text, its other parameters, and earlier rows of the same batch, instead of the bytes the application supplied. Values at least as long as the buffer are affected when the driver writes them from a byte array: bind parameters set with setString, setBytes, or a ByteStreamWriter, CopyIn.writeToCopy, and LargeObject.write. Most such writes fail with an ArrayIndexOutOfBoundsException instead. The default, gssEncMode=allow, does not start GSS encryption, and connections without GSS encryption are not affected. Versions 42.7.3 and earlier are not affected, and 42.7.6 fixes the problem.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pgjdbcto a version that resolves this vulnerability.Fixed in 42.7.6
Event History
Frequently Asked Questions
Which deployments are exposed?
Only pgjdbc 42.7.4 and 42.7.5 connections using GSS encryption are affected. The default gssEncMode=allow does not start GSS encryption, and connections without GSS encryption are not affected.
What application activity can trigger the incorrect stored data?
A value at least as long as the GSS send buffer can be affected when written from a byte array. Affected paths include bind parameters set with setString, setBytes, or a ByteStreamWriter, CopyIn.writeToCopy, and LargeObject.write; with MIT Kerberos, the buffer is 16320 bytes.
What does successful exploitation require?
An attacker needs access to cause or influence a qualifying large value sent over an existing GSS-encrypted connection using an affected driver version. The result is that the server may store bytes from earlier messages on that same connection, including SQL text, other parameters, or earlier batch rows.
How can this be remediated or mitigated?
Upgrade to pgjdbc 42.7.6, which fixes the problem. If an upgrade is not immediately possible, avoid GSS encryption for affected connections; connections without GSS encryption are not affected.
How can teams identify potentially affected records?
Review applications using pgjdbc 42.7.4 or 42.7.5 with gssEncMode=prefer or require, and identify qualifying large writes through the listed parameter, COPY, or large-object paths. Some writes fail with ArrayIndexOutOfBoundsException, but successful affected writes can be stored by the server without an error.